Slashdot Mirror
"Month of Kernel Bugs" Project Head Interviewed
An anonymous reader writes "November has been labelled the 'Month of Kernel Bugs' in security circles. The Month of Kernel Bugs began on November 1, with the publication of a vulnerability in Apple's AirPort drivers. SecuriTeam blogs did an interview with LMH, who hosts the project."
Who is LMH?
Doh, wrong button :-)
A remote exploit for a widely-deployed wireless driver from Broadcom was published today. This is the first remote public exploit that abuses a driver flaw to execute arbitrary shellcode :-)
The bug I found is not due to the card "complying with a standard", its because the first-generation Airport driver (the latest one available at that), has a bug that allows someone to run code in your kernel from a distance. Maybe I missed the "ieee80211b-pwned" spec, but this doesn't seem like good behavior.
Why is that Apple supporters are in such denial about their favorite products having security flaws? This bug was one of many in the Airport drivers and one an even bigger set of wireless exploits that we plan on releasing. A Broadcom bug was released today which likely affects more systems than Apple has ever shipped.
This particular one was only in the first-generation Airport drivers. It may affect Windows users of the Proxim/Orinoco/Lucent chips as well, but we didn't have any hardware to test on.
I have never been involved, even peripherally, in kernel development, so I thought some of LMH's comments on how security concerns are addressed there were interesting.
In particular, he remarks: "Another point, is actually that silent patches are much more popular in kernel development. Remote denial of service issues may be patched under rather fun terms like 'this may dereference a null pointer', 'foo is signed when it should be unsigned', etc. And some kernel interfaces are literally a royal pain to work with. Filesystem code itself is a rather complex part of the kernel as it deals in low-level with things we typically know 'abstracted' (ex. you copy files, you don't deal with inodes, blocks, etc)."
This seems rather contrary to the OSS development model in general, and if it's something that's happening a lot, it seems as though something's wrong, procedurally. Why is all this buggy code getting in, in the first place? While I'm aware that a lot of Linux people don't like BSD or its development methods, maybe there needs to be some sort of stricter review process for contributions.
If there was one place where transparency and accountability were most important, it seems like it would be in the Linux kernel, it being arguably one of the most important projects, or at least most visible, that the F/OSS movement has produced.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I'm not sure this is true. I don't think vulnerability was in all wireless drivers; that would just be too weird. There are hundreds of different WL chipsets and driver stacks; not all of them are written that crappily. A good many may be, but not all.
/. article for), they weren't even using Apple's wireless card or drivers, they were using a third-party one, and then just implicated Apple later.
There was apparently a problem in Apple's drivers, as well as in a lot of other closed-source drivers. In fact, when those two guys did the "Hack a MacBook's Wireless in 30 Seconds" demo (of which I am a bit ashamed to admit I submitted the
If you read a few posts up in the thread you'll see that they have now found a pretty big hole in Broadcom's (assumedly Windows) drivers for wireless cards, where transmitting a specifically crafted SSID can result in kernel-mode code execution.
I think Apple got hit because it was a big target; since Microsoft doesn't specifically (to my knowledge) make WL drivers, and Apple being bigger than any single third-party WL-card vendor, when people found a vulnerability affecting many drivers and chipsets, they went for the one that would get them the most press coverage. While I can't condone this (since I think it involves fear-mongering and pandering to the knee-jerk Apple-haters), it's not hard to understand.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Current drivers for the first-generation cards (the non-extreme) ones. This limited the bug to Mac hardware shipped between 1999 and 2003. We have some reproducable crashes in the latest Atheros-based cards as well (all new Intel Macs), but need to finish the research before we talk about it.
If you're after more info on the Month of Kernel Bugs, check out the blog
No, this isn't my blog, and I've got nothing to do with it, it's just that it's not linked to or mentioned in the main story...
Specialist Mac support for creative pros, Melbourne
I probably should have been more clear -- I wasn't implying that OpenBSD or any other kernel has less bugs than Linux; I haven't reviewed the code so I can't say that. However, regardless of which OS or kernel we're talking about, if people are recognizing and fixing bugs silently, and disguising or obscuring their patches, then it makes it very hard to get an idea of how many bugs are actually there, and at what rate they're being fixed.
It was more the practice of silently or clandestinely fixing bugs, without pointing out that the bug was there even after it's fixed, that seems like it's a problem. It means that contributions are going into the kernel tree that aren't well understood except by the person who's submitting them, or at least that's the impression that I get.
It's really that -- not-well-understood patches being submitted and accepted -- which I think is an issue. The relative merits of Linux vs OpenBSD isn't a can of worms I wanted to open up, except in how their processes for reviewing and accepting code differ.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."