Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

"Month of Kernel Bugs" Project Head Interviewed

CowboyNeal posted more than 7 years ago | from the getting-to-know dept.

Security 42

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

cancel ×

42 comments

Sorry! There are no comments related to the filter you selected.

A question I wish was answered (2, Insightful)

BadAnalogyGuy (945258) | more than 7 years ago | (#16805900)

Who is LMH?

Re:A question I wish was answered (3, Informative)

bcat24 (914105) | more than 7 years ago | (#16805994)

The Month of Kernel Bugs is the brainchild of a security researcher and contributor to the Metasploit Project who uses the moniker "L.M.H."
(cite) [securityfocus.com]

phirst (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#16805902)

phirst

Re:phirst (0, Offtopic)

Anonymous Coward | more than 7 years ago | (#16806036)

phailed ;)

Re:phirst (1)

JoshJ (1009085) | more than 7 years ago | (#16806570)

...who modded this funny?
*smack*
Bad mod! No cookie! (except the one from XXX-hawt-slutty-shemales-dot-com that's hacking your wireless, obv)

Re:phirst (1)

hotdiggitydawg (881316) | more than 7 years ago | (#16807882)

It was the nearest they could get to +1 Phunny, I'm guessing...

Sounds interesting (1)

MrDrBob (851356) | more than 7 years ago | (#16806016)

This sounds useful, and it'll be interesting to see how different kernel developers respond to flaws in their kernels being published on a regular basis. I suppose some of them would prefer to just keep a private communication line with MoKB open, and some would prefer otherwise.

Shifty business in the kernel. (3, Informative)

Kadin2048 (468275) | more than 7 years ago | (#16806592)

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.

Re:Shifty business in the kernel. (2, Interesting)

gmack (197796) | more than 7 years ago | (#16807618)

Well for starters Linux isn't the only kernel with bugs [theaimsgroup.com] . I'm not slamming OpenBSD but it was a very quick example.

The kernel of any OS is a very complicated piece of code and bugs can be very subtle and hard to spot. You have a wider range of inputs than other pieces of software and at the same time you have a large array of hardware and BIOS to interface and they all have potential bugs of their own.

I've gone through bug reports to try and understand what goes wrong and how it's fixed. Those programmers are very good at what they do and I've seen even the best and most secure coders introduce bugs.

Problem is more the secret fixing. (2, Interesting)

Kadin2048 (468275) | more than 7 years ago | (#16808804)

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.

Re:Problem is more the secret fixing. (1)

k8to (9046) | more than 7 years ago | (#16810188)

Well if you propose to adopt the processes of another project in whole or in part, you should probably check that their processes demonstratably produce better results than the processes you propose to replace.

That the patches are understood by multiple people is important. I'm not sure why you feel this practice of weak descriptions implies this is the case, or why this practice is considered to apply specifically to linux. My understanding of TFA did not conveey that to me.

Re:Shifty business in the kernel. (1)

ctzan (908029) | more than 7 years ago | (#16811160)

From my experience with open source, some developpers are just dishonest. Of course they don't like to admit the mistakes they have made. They even try to blame them on others (counting on most people not bothering - or not having the time - to go through ChangeLogs, commits, etc).

There's no procedure to fix that. Just make noise and expose them. If there's some 'influential' one who's the guilty part, so much better :)

Re:Shifty business in the kernel. (1)

SnowZero (92219) | more than 7 years ago | (#16816052)

Well, so far, all the Linux/BSD bugs have been from mounting corrupt filesystems. Not to say that these aren't bugs, but how many people would mount an untrusted ext3 volume? To exploit any of these, even locally, requires root access. The only one remotely alarming is the Linux CD-R filesystem DoS. At that level though, there are DVDs which cause my physical drive to hang -- not much the OS can do about that. I guess the main lesson would be to educate people not to mount untrusted filesystems, unless that filesystem has been thoroughly audited for that use (FAT on usb drives should be tested, CDs, DVDs, etc). The rest I would consider pretty normal bugs, and the overwhelming complexity of filesystems means we won't ever get rid of all of them (I wonder how Sun's ZFS fares in fuzzing tests).

Re:Sounds interesting (1)

baadger (764884) | more than 7 years ago | (#16807524)

Linux seems to be responding OK. A patch [gmane.org] for yesterday's ext3 denial of service bug [info-pull.com] is on the mailing list and in -mm.

Broadcom wireless driver exploit published today! (0)

spinja (994674) | more than 7 years ago | (#16806104)

A <a href="http://metasploit.com/svn/framework3/trunk/m odules/exploits/windows/driver/broadcom_wifi_ssid. rb">remote exploit</a> for a <a href="http://www.google.com/search?q=BCMWL5.SYS">w idely-deployed wireless driver</a> from Broadcom was <a href="http://projects.info-pull.com/mokb/MOKB-11-1 1-2006.html">published today</a>. This is the first remote published, public exploit that abuses a driver flaw to execute arbitrary shellcode :-)

Re:Broadcom wireless driver exploit published toda (2)

spinja (994674) | more than 7 years ago | (#16806130)

Doh, wrong button :-) A remote exploit [metasploit.com] for a widely-deployed wireless driver [google.com] from Broadcom was published today [info-pull.com] . This is the first remote public exploit that abuses a driver flaw to execute arbitrary shellcode :-)

Original announcement (1)

Kadin2048 (468275) | more than 7 years ago | (#16806266)

The official announcement summary for that exploit:
The Broadcom BCMWL5.SYS wireless device driver is vulnerable to a stack-based buffer overflow that can lead to arbitrary kernel-mode code execution. This particular vulnerability is caused by improper handling of 802.11 probe responses containing a long SSID field. The BCMWL5.SYS driver is bundled with new PCs from HP, Dell, Gateway, eMachines, and other computer manufacturers.
Emphasis was in the original. Source was Kernelfun [blogspot.com] .

Apple flaw? No. (1, Interesting)

Anonymous Coward | more than 7 years ago | (#16806120)

What they found was actually a general flaw in wireless drivers that comply with the Wi-Fi standard. Why do self-appointed security experts always seem to have to find something wrong with Apple (and incorrectly) to prove their mettle?

Re:Apple flaw? No. (1)

billsoxs (637329) | more than 7 years ago | (#16806208)

What they found was actually a general flaw in wireless drivers that comply with the Wi-Fi standard. Why do self-appointed security experts always seem to have to find something wrong with Apple (and incorrectly) to prove their mettle?

Maybe because it gets more press?

Re:Apple flaw? No. (5, Informative)

spinja (994674) | more than 7 years ago | (#16806310)

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.

Re:Apple flaw? No. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16807878)

Why is that Apple supporters are in such denial about their favorite products having security flaws?

umm maybe because it is not just an 'APPLE' flaw. It is the attempt to hide this that is the problem. Look at it this way.

THE BATTERIES IN APPLE COMPUTERS ARE ALL GOING TO BURN (and all other computers using batteries from the same plant in china will do the same thing.)

Yes, apple products have their 'issues' - but FUD is FUD. Good you found a bug. Next time do your homework and figure out where the bug is really from.

Go ahead and mod this as flamebait - it is - but it is also the truth.

Apple Apologists (0)

Anonymous Coward | more than 7 years ago | (#16809892)

I believe your answer is that Apple apologists thrive on the perfection of their system in comparison to others. Within their circle, they bitch about things like how the Finder sucks, but comparison to outsiders is a united front. Things like rooting their box remotely are a sore spot, because that's their best argument against Windows. These kinds of bugs give the Windows people a chance to respond, whereas the Apple apologists would prefer them in stunned silence.

-A faithful, but realistic Apple user/developer

Re:Apple flaw? No. (1)

sHADOW20044 (786373) | more than 7 years ago | (#16812236)


Why is that Apple supporters are in such denial about their favorite products having security flaws?

Maybe it has something doing with this quote: 'One rotten (or bad) apple spoils the barrel.'

Re:Apple flaw? No. (1)

ManxStef (469602) | more than 7 years ago | (#16815392)

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.

I don't think they are; in fact, I think most, myself included, are pleased that there are people working to improve the security of Apple's systems and who call them out when they get it wrong.

The entire problem with the Ellch & Maynor Black Hat affair is that there's been *absolutely no proof* presented of an exploit to Apple's Airport Express drivers, for whatever reason. To do a demo with an Apple laptop, 3rd party card and drivers AND only provide a videotape? That's not the recipe for a great presentation, by a long way. Still, I must admit to being conflicted about the whole thing. I've read the Daring Fireball/Jon Gruber coverage, which provides the more popular angle that Ellch and Maynor are full shit and did the whole thing purely for the publicity of hacking Apple hardware, and generally have a lot of respect for Gruber's journalism: he usually "hits the nail on the head", so to speak, providing an insightful angle more often than not. On the other hand, I broadly understand how buffer overflows work (thanks to the seminal Phrack article "Smashing the Stack for Fun and Profit" by Aleph One), have read some of Ellch's papers (such as the SecurityFocus article on Wireless fuzzing and his discussion of a Centrino Wi-Fi bug/race condition) and he does seem to know what he's talking about. But why no proof? That's the central issue. As a responsible security professional he/they may be withholding information until a fix is provided, but there should be -- in my opinion, HAS to be -- limits to this. I've read many discussions on the issue of disclosure and think it's perfectly reasonable to put a timeframe on such information i.e. you've got, say, 50 days to fix this bug before I go public, otherwise companies may well do nothing to fix the problem. Pressure from Apple's legal department? I don't buy it, surely they'd have a decent lawyer who would be able to back up their side of things and allow them to release details with confidence? After all, similar situations have happened before with other companies and the researchers haven't been pressured into silence. I'm also not convinced that Apple's subsequent fix/update of the drivers was due to information provided by Ellch/Maynor because if it was, how come they've not published the exploit? But still, I'm not sure either way. Does the proof exist? I don't know. Like I said, I'm fairly conflicted about the entire thing! :)

The other problem I have is that, following on from the above media frenzy, the Airport exploit (your one? Presumably found by fuzzying?) is for the older generation of Apple hardware. It's NOT for *Airport Express* (802.11G) drivers, it's for the older 802.11B-only class of hardware. Apple haven't shipped these machines in what, two years? Frankly I find it hard to swallow all the hype of the media reports when it's for a previous generation of hardware, and find the whole media coverage disingenuous at best and deliberately misleading sensationalism at worst. Please don't take this as a criticism of your work, I find the exploit and the issues it raises interesting -- it proves that Apple's driver code wasn't (and therefore, may still not be) flawless, for one -- my problem is with the quality of the reporting, not the exploit itself. This type of journalism doesn't help anyone, it merely polarises both camps into "Apple is invulnerable" vs. "Mac users have their heads firmly in the sand", neither of which is particularly true.

What we need is more informed, insightful commentary... preferably along with some proof-of-concept Metasploit shellcode ;)

Re:Apple flaw? No. (1)

spinja (994674) | more than 7 years ago | (#16815862)

Try putting a fresh 10.4.8 install on an Intel Mac and running the new Broadcom exploit [info-pull.com] against it. Now try it with the patch Apple released a month after the Black Hat presentation. Is this the same bug? Did they reverse engineer Apple's patches to find this? Why are they NOT claiming that this is the infamous bug? Why would they bother faking an exploit in the first place? Why isn't Apple listed as a vulnerable vendor in the MoKB advisory? My opinion is that the rabid response the Gruber's fans have turned them off from ever "addressing" the Mac community with any "proof" they have to offer. Regarding the old Airport bug I found -- its the hardware I happened to have. If you want to send me a shiny new Intel Mac, I would be more than happy to start dumping wireless driver bugs for that platform as well. Hardware hacking is expensive dammit :-)

Re:Apple flaw? No. (1)

ManxStef (469602) | more than 7 years ago | (#16817884)

Thanks for the reply. Those are some interesting questions, indeed; I would love to try that out -- for instance, does this (on OS X) cause a kernel panic or can arbitrary code be executed? -- if I could afford an Intel Mac myself ;) (It'd also be handy to do an Intel build of MPlayer for OS X as the official site's Mac binaries are still out of date, I've done a PPC build which I'll distribute unofficially once I'm back home and off the slow-as-molasses GPRS.)

Speaking of which, while I definitely can't buy you an Intel Mac outright I certainly would donate some money. If you set up an official Metasploit-sponsored "get us an Intel Mac so we can fuzz it" site with a Paypal account and aim for a common model, say, a current Intel Mac Mini or entry MacBook, then I'd gladly throw you $20USD and I'm sure plenty of other people would, too. After all, I want as secure a machine as possible and would be happy for more security researchers to target the platform. (Though I do suspect that the Airport Express drivers may now be a significantly harder target than they were a few months ago. Perhaps focussing in a different direction would be more successful, e.g. the Bluetooth drivers?)

It'd be a real shame that Ellch and Maynor, if they truly did find a kernel exploit in the Apple Wi-Fi drivers as you imply, left the situation as it currently stands, their reputations to many have been severely tarnished. The handling of events on both sides has been poor and the truth, whatever it is, hidden under a big pile of spin. I'd like some straight answers, specifically to my previous questions and to the points and inferences you raise in your post, devoid of anger or resentment towards any particular party, and if the above donation would help me get that then it'd be money well spent.

/sigh stupid FUD (1, Insightful)

falcon5768 (629591) | more than 7 years ago | (#16806296)

with the publication of a vulnerability in Apple's AirPort drivers.
It's a vulnerability in EVERYONES WiFi drivers. Why does it continue to get reported as if only Apple products will be effected when its anyone who uses those drivers, of which there are a lot more than JUST Apple products.

Worse why does it get reported like its the only vulnerability? We have known the 802.11 standard was very insecure for years at this point.

Re:/sigh stupid FUD (2, Informative)

spinja (994674) | more than 7 years ago | (#16806370)

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.

Re:/sigh stupid FUD (0)

Anonymous Coward | more than 7 years ago | (#16806490)

This particular one was only in the first-generation Airport drivers.

By first-generation Airport drivers, do you mean the first generation of drivers for Airport wireless cards, or do you mean the current drivers for the first-generation Airport wireless cards (cards that Apple no longer manufactures or sells)?

Re:/sigh stupid FUD (2, Informative)

spinja (994674) | more than 7 years ago | (#16806870)

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.

Re:/sigh stupid FUD (1)

mspohr (589790) | more than 7 years ago | (#16806626)

Yes, this is stupid. I think the reason that it gets reported as an "Apple" bug is that it was first demonstrated on Apple hardware... yes, it's not fair... but, it's not a plot to destroy Apple.

The press in general is stupid since they don't understand technology. Most of the press coverage of virus, trojan, etc. problems fails to mention that these are almost exclusively the problems of Windows PCs and that Apple and Linux computers are almost free of such problems.

It's not a plot, it's just sloppy reporting.

Apple vs Broadcom (4, Insightful)

Kadin2048 (468275) | more than 7 years ago | (#16806656)

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.

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

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.

Re:Apple vs Broadcom (0)

Anonymous Coward | more than 7 years ago | (#16807478)

so how could there "There was apparently a problem in Apple's drivers..." be at all a supportable statement if, as you say "they weren't even using Apple's wireless card or drivers"?

Re:/sigh stupid FUD (1)

NemosomeN (670035) | more than 7 years ago | (#16808446)

Nowhere in the spec does it say not to check the length of the SSID. It's a bad implementation of the spec. It is NOT IN EVERYONE'S IMPLEMENTATION.

Interview with who? (1)

loftwyr (36717) | more than 7 years ago | (#16807250)

Who's LMH? The article just assumes you know who that is!

Re:Interview with who? (0)

Anonymous Coward | more than 7 years ago | (#16807510)

Who's LMH? The article just assumes you know who that is!

Gee I thought that everyone knew him.

LMH = Lawrence Michael Harrison. He lives in Portland Maine. Would you like his phone number as well?

Re:Interview with who? (0)

Anonymous Coward | more than 7 years ago | (#16807756)

Never heard of him. What kind of credibility does he have?

Re:Interview with who? (0)

Anonymous Coward | more than 7 years ago | (#16810198)

You bought into that? wow

MOKB (3, Informative)

PhunkySchtuff (208108) | more than 7 years ago | (#16807920)

If you're after more info on the Month of Kernel Bugs, check out the blog [blogspot.com]

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

this is 60atsex (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#16809538)

so there are pEople

Dup (0)

Anonymous Coward | more than 6 years ago | (#16936992)

2006-11-01 20:15:43 Month of Kernel Bugs (IT,Security) (rejected)

oh wait
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>