Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security

"Month of Kernel Bugs" Project Head Interviewed 42

Posted by CowboyNeal from the getting-to-know dept.
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."
This discussion has been archived. No new comments can be posted.

"Month of Kernel Bugs" Project Head Interviewed More

"Month of Kernel Bugs" Project Head Interviewed

Comments Filter:
  • Who is LMH?
  • 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. (Score:4, Informative)

      by Kadin2048 ( 468275 ) <.ten.yxox. .ta. .nidak.todhsals.> on Saturday November 11, 2006 @02:19PM (#16806592) Homepage Journal
      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: (Score:3, Interesting)

        by gmack ( 197796 )

        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 progra

        • 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, wit

          • Re: (Score:1)

            by k8to ( 9046 )
            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: (Score:1)

        by ctzan ( 908029 )

        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: (Score:2)

        by SnowZero ( 92219 )
        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

    • Re: (Score:2)

      by baadger ( 764884 )
      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.

  • Apple flaw? No. (Score:1, Interesting)

    by Anonymous Coward
    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?
    • 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. (Score:5, Informative)

      by spinja ( 994674 ) on Saturday November 11, 2006 @01:38PM (#16806310) Homepage
      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: (Score:1, Insightful)

        by Anonymous Coward

        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


      • 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.'
      • 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 wr

        • Re: (Score:1)

          by spinja ( 994674 )
          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 turne
          • 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 b

  • Re: (Score:1, Insightful)

    by account_deleted ( 4530225 )
    Comment removed based on user account deletion

    • Re: (Score:2, Informative)

      by spinja ( 994674 )
      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: (Score:2)

      by mspohr ( 589790 )
      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

    • Apple vs Broadcom (Score:5, Insightful)

      by Kadin2048 ( 468275 ) <.ten.yxox. .ta. .nidak.todhsals.> on Saturday November 11, 2006 @02:29PM (#16806656) Homepage Journal
      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.
    • 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.
  • Who's LMH? The article just assumes you know who that is!

  • MOKB (Score:4, Informative)

    by PhunkySchtuff ( 208108 ) <kai@automatic[ ]om.au ['a.c' in gap]> on Saturday November 11, 2006 @05:15PM (#16807920) Homepage
    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...

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close