CVE-2011-1182: Low severity linux kernel vulnerability
kernel/signal.c in the Linux kernel before 2.6.39 allows local users to spoof the uid and pid of a signal sender via a sigqueueinfo system call.
Other sources
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 rtsigqueueinfo(). 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 siginfot 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.sicode >= 0) return -EPERM;
This check made sure that rtsigqueueinfo() could not spoof a signal whose SICODE would be SIKERNEL or SIUSER. As the comment indicates, a process receiving a signal should be able to trust its source pid or uid if its sicode matches SIUSER.
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 sicode. 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 SITKILL signal. Glibc authors too [1]. Worse: they even silently patched SITKILL with SIUSER [2], [3]. So even a userland application that (righfully so) only trusts SIUSER signals will be vulnerable.
A tentative patch for this vulnerability has been committed to Linus' kernel tree [4].
In this patch, we prevent rtsigqueueinfo() from specifying any sicode != SIQUEUE. 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 ( (sicode == SITKILL) || (sicode >= SIQUEUE) ) 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
— Red Hat
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2011-1182?
CVE-2011-1182 is classified with a moderate severity level due to its potential impact on user privilege escalation.
How do I fix CVE-2011-1182?
To fix CVE-2011-1182, it is recommended to upgrade to the Linux kernel version 2.6.39 or later.
What versions of the Linux kernel are affected by CVE-2011-1182?
CVE-2011-1182 affects all Linux kernel versions prior to 2.6.39.
Can CVE-2011-1182 be exploited by remote attackers?
CVE-2011-1182 is primarily a local vulnerability, meaning it requires local access to exploit.
What does CVE-2011-1182 involve in terms of system calls?
CVE-2011-1182 involves the sigqueueinfo system call which can be manipulated to spoof the sender's uid and pid.