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
This archive was generated by hypermail 2.1.3 : Sun Nov 12 2006 - 22:16:36 PST