A survey of recent kernel vulnerabilities

[Posted October 18, 2005 by corbet]

There has been a fairly long list of kernel vulnerabilities over the last few months, but few of them have received much serious attention (outside of the security groups at numerous distributors, who have been duly issuing patches as the issues come up). Here's a selection of recent problems.

CVE	Fixed-in	Description
CAN-2005-2098	2.6.12.5 2.6.13	The session keyring code had an error path which could fail to release the session management semaphore. As a result, any local user could cause processes to hang.
CAN-2005-2099	2.6.12.5 2.6.13	A keyring which failed to instantiate correctly could leave behind a NULL pointer which would subsequently be dereferenced by the kernel, causing an oops.
CAN-2005-1761	2.6.12.1	A `ptrace()` bug on the ia64 architecture enables local denial of service attacks. (Patch)
CAN-2005-1913	2.6.12.1	The subthread exec code did not properly reparent timers, leading to an oops caused by a local user when signals are delivered to the wrong thread. (Patch)
CAN-2005-2456	2.6.13	The XFRM policy parser had an array overflow, enabling denial of service attacks by local users. (Patch)
CAN-2005-2457	2.6.13	Mounting a malicious compressed ISO filesystem could lead to a kernel oops
CAN-2005-2458 CAN-2005-2459	2.6.13	Two zlib vulnerabilities which can be used to oops the kernel and create denial of service attacks.
CAN-2005-2490	2.6.13.1	A race condition with user space allows a local attacker to change the contents of a message passed to the 32-bit version of `sendmsg()` on 64-bit architectures. The result is a locally exploitable buffer overflow. (Patch)
CAN-2005-2492	2.6.13.1	An unchecked user-space dereference in `sendmsg()` can be exploited to oops the system. (Patch)
CAN-2005-2548	2.6.9	A hostile UDP packet could cause the 8021Q VLAN code to oops, leading to remote denial of service attacks.
CAN-2005-2555	2.6.13	The kernel failed to restrict kernel socket policy loading to administrative users. (Patch)
CAN-2005-3044	2.6.13.2	The 32-bit `ioctl()` handler on x86-64 was missing an `fput()` call. This error could be exploited by a local attacker to corrupt kernel data structures. (Patch)
CAN-2005-3053	2.6.13	The `set_mempolicy()` system call, used to tweak memory behavior on NUMA systems, did not properly check the `policy` argument. A local attacker could, by supplying a negative value, could cause a kernel oops. (Patch)
CAN-2005-3106	2.6.11	A race condition between core dumps and `exec()` could enable a local attacker to deadlock the system. (Patch)
CAN-2005-3107	2.6.11	Another local deadlock related to core dumps and `ptrace()`. (Patch)
CAN-2005-3108	2.6.11	The right sort of I/O mapping could create information leaks and kernel oopses on the x86-64 platform. It is hard to see how this one could be exploited by an unprivileged user. (Patch)
CAN-2005-3109	2.6.11	A maliciously created HFS filesystem could oops the kernel, if the system was configured to allow users to mount such filesystems. (Patch)
CAN-2005-3110	2.6.12	A race condition in the netfilter ebtables module can cause a kernel oops on SMP systems. (Patch).
CAN-2005-3119	2.6.13.4	A memory leak in the key request code could be used in denial of service attacks. (Patch)
CAN-2005-3180	2.6.13.4	The orinoco driver can leak information onto the net. (Patch)
CAN-2005-3181	2.6.13.4	A memory leak in the audit code can be used for denial of service attacks. (Patch)

That is a long list of vulnerabilities. The fact that almost all of them are "only" denial of service problems, and that only one of those is truly remotely exploitable, is of limited consolation.

One may well wonder why the kernel is the source of so many security holes, far more than any other package on the system. The complexity of the kernel and the environment in which it runs, the fact that many often-harmless bugs (such as memory leaks) turn into security issues for the kernel, and the high level of auditing which is done on kernel code are all part of the answer to that question. Unfortunately, the flow of security issues in the kernel is unlikely to stop anytime soon.

Index entries for this article
Kernel	Security/Vulnerabilities

to post comments

A survey of recent kernel vulnerabilities

Posted Oct 20, 2005 10:16 UTC (Thu) by jschrod (subscriber, #1646) [Link] (4 responses)

I don't give too much attention to DoS attacks that need full local accounts.

Just yesterday, I made my system unusable by starting ~300 sa-learn processes in parallel. I was not able to use the console any more, and could not log in from remote to kill those processes. I waited a full hour to check if the system consolidate itself until I pressed the reset button.

As long as simple starts of too many processes can bring down the system, we don't need special means for those local-user DoS attacks. Just a shell is enough. :-(

That's an 2.6.8 SUSE-kernel, by the way. Oh yes, and that's one area where advantages in Linux would be great. On my Solaris box, I can start thousands of processes and then I can still login and kill them if necessary.

Cheers, Joachim

A survey of recent kernel vulnerabilities

Posted Oct 20, 2005 11:41 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

Yeah, but on that Solaris box, can you start thousands of CPU-and-memory-hogs like sa-learn and still log in and kill them? sa-learn is a lot hoggier than, say, sleep(1) :)

A survey of recent kernel vulnerabilities

Posted Oct 20, 2005 12:00 UTC (Thu) by jschrod (subscriber, #1646) [Link] (2 responses)

Yes, sa-learn has 14MB RSS, as I noticed yesterday. And my workstation has only 1GB real and 2GB virtual memory. Solaris 9 handles such situations gracefully, in contrast to my Linux installations. I have had Solaris servers with loads in the 1000s and vast overcommitment of memory and was still able to save them without the need for reboot. With Linux, I never could resolve such situations without hard reboot.

Actually, that's one of the reasons why I still prefer the classic Unix systems on mission-critical installations, and use Linux for business-important and business-foundation stuff. (The main other reason is better hardware than IA32- or IA64/AMD64-based systems, and better accomodation of the proprietary Unices for that kind of hardware to build high-end clusters.)

Cheers, Joachim

PS: To get my opinion into context: I'm using SunOS since 1985 and Linux since 1992 or 1993 (0.99.4, it was) and have my share of good and bad experiences with both of them. I don't want to debase Linux; this situation is IMO just one of the differences that are still there.

A survey of recent kernel vulnerabilities

Posted Oct 20, 2005 20:58 UTC (Thu) by hmh (subscriber, #3838) [Link] (1 responses)

I wonder if a suitably well configured linux box has this problem. We *should* be able to have the system console itself be on the highest priority chains, and locked into memory.

Anyway, ulimit is your friend, use it. If your box is not supposed to reach loads like 1000 or so, then configure it accordingly to kill any task that attempts to do so.

A survey of recent kernel vulnerabilities

Posted Oct 20, 2005 23:56 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Oh, my system is supposed to handle loads in the 1000s. (After all, these processes don't do something interactively and can be handled one after the other.) It shall also handle large memory allocations (over-commitment) gracefully. I can realize that on Solaris servers, why should I drop that requirement for my Linux boxes?

Anyhow, my main point was that the security of Linux kernels is painted more black in the article than it actually is. All those local-user DoS exploits are not a risk addition that is high or relevant in practice. We can and will live with it as we do right now with `normal' ability to spawn too many processes that use too much memory.

A survey of recent kernel vulnerabilities

Posted Oct 20, 2005 23:47 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

"A hostile UDP packet could cause the 8021Q VLAN code to oops" doesn't really match either the longer and more detailed explanation in the linked Debian bug report, or the supplied patch, or the stacktrace recorded.

Those tell another story, which is that a privileged ioctl() was faulty, and this ioctl() was used by an SNMP daemon which answers UDP packets. No SNMP daemon, no exploit.

In this sense the ptrace() bug is also remotely exploitable, you just ssh into the affected machine and execute an exploit.