[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTimqPRory7mcj=y0BC4JZhhC+ujst5Btb+b5cuoE@mail.gmail.com>
Date: Tue, 29 Mar 2011 15:32:55 -0700
From: Julien Tinnes <jt@....org>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel signal spoofing vulnerability (CVE request)
If you have integrated this patch (which you should!), you should also
integrate that one:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=243b422af9ea9af4ead07a8ad54c90d4f9b6081a
This relaxes the check, since it turns out that glibc does rely on
changing the signal code for async IO.
Julien
On Tue, Mar 22, 2011 at 3:56 PM, Julien Tinnes <jt@....org> 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
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
