http://blogs.securiteam.com/index.php/archives/730 

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 
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 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 
available, etc).

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 
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 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
http://www.infosecnews.org/mailman/listinfo/isn