This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 690028 - (CVE-2011-1182) CVE-2011-1182 kernel signal spoofing issue
CVE-2011-1182 kernel signal spoofing issue
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
public=20110323,reported=20110323,sou...
: Security
Depends On: 690030 690031 690032 690033 690034 715521
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-23 00:40 EDT by Eugene Teo (Security Response)
Modified: 2015-08-19 05:09 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-29 10:18:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2011-03-23 00:40:22 EDT
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.

[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

Acknowledgements:

Red Hat would like to thank Julien Tinnes of Google Security Team for reporting this issue.

Upstream commit:

http://git.kernel.org/linus/da48524eb20662618854bb3df2db01fc65f3070c
http://git.kernel.org/linus/243b422af9ea9af4ead07a8ad54c90d4f9b6081a
Comment 3 Eugene Teo (Security Response) 2011-03-23 02:46:28 EDT
Statement:

Red Hat Enterprise Linux 4 is now in Production 3 of the maintenance life-cycle, https://access.redhat.com/support/policy/updates/errata/, therefore the fix for this issue is not currently planned to be included in the future updates. This was addressed in Red Hat Enterprise Linux 5 and 6 via https://rhn.redhat.com/errata/RHSA-2011-0927.html and https://rhn.redhat.com/errata/RHSA-2011-1189.html. A future kernel update in Red Hat Enterprise MRG may address this flaw.
Comment 4 Petr Matousek 2011-03-30 08:03:28 EDT
From the reporter:

"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."

Reference:
http://seclists.org/oss-sec/2011/q1/625
Comment 5 errata-xmlrpc 2011-06-21 19:53:27 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6.0.Z - Server Only

Via RHSA-2011:0883 https://rhn.redhat.com/errata/RHSA-2011-0883.html
Comment 9 errata-xmlrpc 2011-07-15 02:08:57 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2011:0927 https://rhn.redhat.com/errata/RHSA-2011-0927.html
Comment 10 errata-xmlrpc 2011-08-23 10:42:16 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:1189 https://rhn.redhat.com/errata/RHSA-2011-1189.html

Note You need to log in before you can comment on or make changes to this bug.