Fuzzing the Linux Kernel: a student in danger.

Question

I am currently a university student studying a degree related to computing, and my current project is focusing on finding vulnerabilities in the Linux kernel. My goal is to both statically audit and confuse the kernel (targeting version 3.0) in an attempt to find a vulnerability.

My first question, “simple,” is to confuse the Linux kernel? I heard about people scaring a lot of protocols, etc., but not very much about kernel modules. I also understand that in a Linux system everything can be considered as a file, and therefore, of course, entry into the kernel modules should be possible through this interface, right?

My second question is: what kind of fuzzer would you suggest? As mentioned earlier, there are many fuzzers that contain fuzz protocols, but I don’t see many of them useful when attacking a kernel module. Obviously, there are frameworks like Peach fuzzer that allows you to “create” your own fuzzer from scratch and is supposedly fine, but I tried to install Peach several times, but it's hard for me to believe that it works, given the complexity I already experienced just by installing it (if anyone knows of any decent installation tutorials please let me know: P).

I would be grateful for any information that you can provide to me. Given the breadth of the topic that I have chosen, any idea of ​​the direction is always welcome. Equally, I would like to ask people to refrain from telling me to start elsewhere. I understand the size of the task, but I will still try it independently (I am a blue sky thinker: P AKA stubborn like Ox)

Greetings

A. Smith

Answer 1

I think a good starting point would be to extend the Dave Jones Linux kernel fuzzer, Trinity: http://codemonkey.org.uk/2010/12/15/system-call-fuzzing-continued/ and http://codemonkey.org .uk / 2010/11/09 / system-call-abuse /

It seems that Dave finds more mistakes when he expands it a little more. The basic idea is to take a look at the system calls you are confusing, and instead of going into completely random garbage, make your fuzzer choose random garbage that at least misses the basic sanity checks in the actual system call code. In other words, you use the kernel source to allow your fuzzer to penetrate system calls further than random input would normally go.

Answer 2

The "fuzzing" core is a fairly broad way to describe your goals. From a kernel perspective, you can

• try to disconnect system calls
• character and block devices in / dev

Not sure what you want to achieve.

Eliminating system calls would mean checking every Linux system call (http://linux.die.net/man/2/syscalls) and trying, if you can interrupt normal operation with odd parameter values.

Fuzzing character- or block-drivers will mean trying to send data through / dev-interfaces in such a way that it will lead to an odd result.

You should also distinguish between unprivileged user and root attempts.

My proposal narrows your attempts to a subset of your proposal. It's just too damn wide.

Good luck - Alex.

Answer 3

One way to smooth out is by using the fuzzing system call.

Essentially, the idea is to accept a system call, fuzz the input over the entire range of possible values ​​- regardless of whether it remains in the specification defined for the system call, it does not matter.