oss-security - Re: Linux kernel signal spoofing vulnerability (CVE request)

Openwall GNU/*/Linux 3.0 - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Mar 2011 08:42:29 +0800
From: Eugene Teo <eugene@...hat.com>
To: oss-security@...ts.openwall.com
CC: Julien Tinnes <jt@....org>
Subject: Re: Linux kernel signal spoofing vulnerability (CVE
 request)

On 03/23/2011 06:56 AM, Julien Tinnes wrote:
> The libc' sigqueue() function allows to queue a signal, as well as some
> accompanying data to a process.
>
> The kernel's interface that is used to implement this function is known
> as rt_sigqueueinfo(). It has been added in Linux 2.2.
>
> This system call is interesting from a security perspective, because it
> allows userland to compeletely specify the siginfo_t structure. This
> structure is normally typically almost entirely written by the kernel
> when a signal is delivered.
>
> Since at least Linux 2.4.0, most abuses of the kernel interface have
> been prevented with a simple check:
>
> 	/* Not even root can pretend to send signals from the kernel.
> 	   Nor can they impersonate a kill(), which adds source info.  */
> 	if (info.si_code>= 0)
> 		return -EPERM;
>
> This check made sure that rt_sigqueueinfo() could not spoof a signal
> whose SI_CODE would be SI_KERNEL or SI_USER. As the comment indicates, a
> process receiving a signal should be able to trust its source pid or uid
> if its si_code matches SI_USER.
>
> Unfortunately, a couple of years later, when tgkill() and tkill() were
> added, this check was forgotten and was not updated to prevent the
> spoofing of a TGKILL si_code.  Because of this, userland is unable to
> trust the pid and uid information of a TKILL signal.
>
> This is bad, because it is a useful feature in a scenario where a
> process which cannot ptrace you can send you signals. This includes at
> least the startup code of setuid binaries.
>
> Meanwhile, userland and libc writers still assumed that they could trust
> the origin of a SI_TKILL signal. Glibc authors too [1]. Worse: they
> even silently patched SI_TKILL with SI_USER [2], [3]. So even a userland
> application that (righfully so) only trusts SI_USER signals will be
> vulnerable.
>
> A tentative patch for this vulnerability has been committed to Linus'
> kernel tree [4].
>
> In this patch, we prevent rt_sigqueueinfo() from specifying any si_code
> != SI_QUEUE. While we believe it to be very unlikley, this could in
> theory break userland in some older Linux distributions, so we may
> have to revert to a more concervative patch and prevent ( (si_code ==
> SI_TKILL) || (si_code>= SI_QUEUE) ) instead.
>
> Please credit "Julien Tinnes, Google security team" in any related advisory.
>
> Julien
>
> [1]: http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/nptl/init.c&l=175
> [2]: http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/sysdeps/unix/sysv/linux/sigwaitinfo.c&l=63
> [3]: http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/sysdeps/unix/sysv/linux/sigtimedwait.c&l=62
> [4]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=da48524eb20662618854bb3df2db01fc65f3070c

Please use CVE-2011-1182.

Thanks, Eugene
-- 
main(i) { putchar(182623909 >> (i-1) * 5&31|!!(i<7)<<6) && main(++i); }
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.