SecuriTeam Interview: LMH

November has been informally designated 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 Month of Kernel Bugs project (aka MoKB); the text of our interview is below (after the jump).

SecuriTeam: Can you give us an overview of the Month of Kernel Bugs project, for the benefit of those who may not have heard of it?

LMH: The Month of Kernel Bugs aims to demonstrate the current state of kernel code in the different operating systems available today, from a security/quality perspective. Using simple tools and procedures, the strength of the different interfaces in the kernel (ex. Linux) can be tested against common flaws. One of the procedures that has been demonstrated as highly effective is ‘fuzzing’ (basically giving crafted, yet ‘valid’ inputs to software in order to test how well it handles unexpected conditions).

Applied to kernel-land testing this is useful to test filesystem handling code, network stack code, etc. Although, by using these procedures one can find many issues, the difficult process is to isolate the test cases, finding the problem itself and where the flaw is located.

To solve the hassle, tools like ‘fsfuzzer’ have been developed, that can automate the test case creation and isolation process (although there’s no way to automatically ‘flag’ issues alone, you still need to go through the tedious task of debugging the kernel, looking at sources if available, etc).

That’s basically the MoKB: one kernel bug for each day of November.

SecuriTeam: Is there a particular reason why kernel security was chosen as a focus for this project?

LMH: It isn’t as crowded as user-land security, imposes a nice challenge and is actually taken less seriously, and less people are looking on it.

SecuriTeam: Why do you believe it is that the kernel has not seen as much scrutiny as other system components?

Well, I’m not sure on the answer to that question. Kernel-land issues are certainly much more tedious to work with than user-land ones. Typically you only have one chance to fail. No daemon re-spawning at kernel space. You make it page fault, and it’s gone. The end. Leaves less room for faults, it’s more complicated, requires you to be a bit more familiar with the system intrinsic details… Maybe there are a dozen reasons. Actually, it’s interesting as Linux is undergoing some serious auditing efforts (ex. Coverity used by IBM and other parties, DHS agreements with Coverity, etc).

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

SecuriTeam: What do you hope that the Month of Kernel Bugs project is able to accomplish by putting the kernel “under the microscope”?

LMH: It will bring some attention, hopefully. It will educate some people. It will discourage some parties from obscuring potential issues, etc. Actually I’m not a full disclosure fan, but in the end it’s the companies and corporations that deal with FUD who have advantages when security flaws aren’t exposed.

SecuriTeam: There has been some criticism of the project because it publishes details of unpatched bugs, including proof-of-concept code. How do you respond to such criticism?

LMH: Well, I’m doing their job. They get paid for preventing such issues from happening. I suppose they also get paid for writing clean code (or doing their best at keeping it that way). This applies most for commercial software, but also for companies which rely on a so-called open-source model. Those flaws would exist with me publishing them or not. I gave advantage to a specific GNU/Linux vendor a year ago. The ISO9660 issue released yesterday has been sitting on my desk for over 6 months now. I still keep a Python byte-code bug for over a year. I could enumerate dozens of facts and that wouldn’t change the mind of those who criticize the project.

So, basically the answer is: We all make mistakes, but not everyone accepts it. Not everyone likes to be informed about issues in his work. We all like clean records. But if someone gives you privileged access to information and you fail to deal with it responsibly, being trustworthy and honest, then you don’t deserve it anymore. In the worst case you get kicked out, and in the best case someone discloses the bug and expects you to fix it. If you still want to play the FUD and politics, well then go fix your code. ;-)

SecuriTeam: Can researchers submit bugs for publication during the Month of Kernel Bugs?

LMH: Sure, and those will be properly credited. MoKB is open for contributions. There are enough bugs to run it for over another month, but some issues aren’t as interesting as others. This week some really nice issues may be released.

I’m finding not less than 4-5 new issues per week, thus availability isn’t a problem right now. I’m trying to focus on releasing the most nice ones first and releasing a moderately nice one between each ‘hot spot’.

Some people suggested to have a week for each platform: ex. the Mac OS X/XNU week, the Linux week, etc. But well, it’s too late for that. Maybe for the next year’s MoKB ‘edition’. :-)

SecuriTeam: The Month of Kernel Bugs started off in a rather dramatic fashion with the publication of an Apple AirPort driver flaw. Are there more bugs of that magnitude to come?

LMH: Someone has used the word ‘vitriolic’ to describe the reactions of a certain group of users. I would say ‘masochistic’ instead.

Definitely, there will be more wireless and, in particular, Apple drama to come. If there’s time left for it, I may work on smart phones and other technology which can be abused (as they have a wide range of possibilities when it comes to rf-based connectivity).

SecuriTeam: Where can people go to find out more about the project and to read about the latest vulnerabilities?

The Kernel Fun blog is the discussion and official announcement place, located at

The issues, proof of concepts, FAQ and other technical information is available at

SecuriTeam: Anything else our readers should know about the project?

LMH: I would like to note that, while there’s no interest nor intention to make money with this, hardware and donations for testing equipment (ex. wireless cards, smart phones, etc) are welcome. Hardware could be returned, it doesn’t need to be permanently ‘donated’ (while this is preferred as deadlines are a potential disadvantage). Anyway, I don’t think it’s an issue right now. Even if for testing wireless devices there’s an evident need of dedicated hardware for such purposes.

SecuriTeam: Thanks for your time today.

LMH: You’re welcome. Thanks for your time as well.

  • Pingback: Alessandro "jekil" Tanasi blog

  • Telekistani Miner

    I wish I were an oscar meyer kernel security vulnerability, for if I were I’d be an awesome sight.

  • noroot

    Cool interview!

  • trasz

    Wait, is this the guy who discovered, that the FreeBSD mount(8) man page, which explicitly says that “It is possible for a corrupted file system to cause a crash”, is, in fact, right, and then published an advisory about something that is already known, documented and not related to security ( Wow. Impressive.

  • LMH

    If you don’t consider integer overflows a security issue (you’re prolly not the only one, hence why such bugs exist), well, you’ve missed the whole picture. BTW, “something that is already known, documented”, how comes that a kernel bug is both documented and unpatched same time? That just doesn’t make sense. Maybe that man page should be fixed some time soon (read: driving a car without motor oil may burn out the engine as well, that’s documented and already known).

    Anyway, I think your problem is that you feel like I’m somehow trying to attack FreeBSD or it’s developers. In such a case, don’t read security issues that deeply. No offense meant, just a matter of facts.

  • Pingback: InfoWorld Tech Watch

  • Pingback: Gerhard´s Marktbeobachtungen

  • trasz

    How comes that a kernel bug is both documented and unpatched same time? It’s very simple, actually – because it’s not related to security (to exploit it you need root priviledges) and very unlikely to occur, so it’s considered low priority.

    It’s not related to the security, because to exploit it you need to have root priviledges – thus there is no ‘priviledge elevation’ happening.