Pretty serious signal race condition in tallow, remote root

[K2]

Since we have multiple vectors being handled by the same function, it can be re-entered multiple times at an attackers discretion since they may have control over various signals that can be sent by terminal sequences, packet flags and so forth. As the signal handler here is managing heap data, it can be groomed and exploited to facilitate remote command execution, for instance as the various free() calls are made with pointers that have already been free'd by another signal that jumped in while processing.

• Do not have multiple vectors calling the same handler.

	memset(&s, 0, sizeof(struct sigaction));
	s.sa_handler = sig;
	sigaction(SIGHUP, &s, NULL);
	sigaction(SIGTERM, &s, NULL);
	sigaction(SIGINT, &s, NULL);

• Be very careful with state, there's no locking here and lots of heap interactions that are remotely controllable by attackers.

tallow/tallow.c

Lines 287 to 302 in 36946de

	static void sig(int u __attribute__ ((unused)))
	{
	fprintf(stderr, "Exiting on request.\n");
	sd_journal_close(j);
	struct tallow_struct *s = head;
	while (s) {
	struct tallow_struct *n = NULL;
	free(s->ip);
	n = s;
	s = s->next;
	free(n);
	}
	exit(EXIT_SUCCESS);
	}

OWASP has an excerpt, pretty much see every UNIX daemon from 2006 (ssh, sendmail, etc...).

https://www.owasp.org/index.php/Race_condition_in_signal_handler

[K2]

you can easily test it with sending various signals from the command line or in a tight loop.
Something like this

ssh -l (`echo -n -e "\x04\x03..."`) 127.0.0.1 -p 10022 &
-rw-------   1 root root 434176 Mar 18 08:18 core.tallow.31311
-rw-------   1 root root 487424 Mar 18 08:19 core.tallow.316

Program terminated with signal SIGQUIT, Quit.
#0  0x00007fa4c9575a1a in ?? ()
(gdb) bt
#0  0x00007fa4c9575a1a in ?? ()
#1  0x0000000000000000 in ?? ()

Core was generated by `/usr/sbin/tallow'.
Program terminated with signal SIGQUIT, Quit.
#0  0x00007f5ab2319008 in ?? ()
(gdb) bt
#0  0x00007f5ab2319008 in ?? ()
#1  0x00007ffd4e8ab180 in ?? ()
#2  0x0000000000e90780 in ?? ()
#3  0xffffffffffffff80 in ?? ()
#4  0x0000000000000000 in ?? ()

[ahkok]

8655223

[ahkok]

BTW, thanks for looking at this, I ended up taking out all the sighandlers entirely and putting the USR1 handler in #DEBUG. While theoretically this is a possible "remote root" it would require collaboration of a person that is local root, as far as I can see, which makes the exploit complexity extremely high.

[K2]

Not necessarily for requiring local root as you can deliver signals remotely, lcamtuf's seminal paper on the subject; http://lcamtuf.coredump.cx/signals.txt

A working PoC for a vulnerable sendmail: https://www.exploit-db.com/exploits/2051/

Thanks for getting to it I appreciate how well clear run's + perf is great.