Weekly Edition
Return to the Security page
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A survey of recent kernel vulnerabilities
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.
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. (Log in to post comments)
A survey of recent kernel vulnerabilities Posted Oct 20, 2005 10:16 UTC (Thu) by jschrod (subscriber, #1646) [Link] 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] 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] 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] 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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||