By Matthew Murphy
November 11, 2006
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 Apples 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
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
To solve the hassle, tools like fsfuzzer have been developed, that can
automate the test case creation and isolation process (although theres
no way to automatically flag issues alone, you still need to go through
the tedious task of debugging the kernel, looking at sources if
Thats 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 isnt 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, Im 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 its gone. The end. Leaves less room for
faults, its more complicated, requires you to be a bit more familiar
with the system intrinsic details Maybe there are a dozen reasons.
Actually, its interesting as Linux is undergoing some serious auditing
efforts (ex. Coverity used by IBM and other parties, DHS agreements with
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 dont 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 Im not a full disclosure fan, but in the end its the
companies and corporations that deal with FUD who have advantages when
security flaws arent 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, Im 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 wouldnt 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 dont 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 arent as interesting as others. This week some really
nice issues may be released.
Im finding not less than 4-5 new issues per week, thus availability isnt
a problem right now. Im 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, its too late for that. Maybe
for the next years 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 theres 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 http://kernelfun.blogspot.com
The issues, proof of concepts, FAQ and other technical information is
available at http://projects.info-pull.com/mokb/
SecuriTeam: Anything else our readers should know about the project?
LMH: I would like to note that, while theres 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 doesnt need to be permanently donated (while this is
preferred as deadlines are a potential disadvantage). Anyway, I dont
think its an issue right now. Even if for testing wireless devices
theres an evident need of dedicated hardware for such purposes.
SecuriTeam: Thanks for your time today.
LMH: Youre welcome. Thanks for your time as well.
Subscribe to InfoSec News