Weakness In Linux Kernel's Binary Format

Goodfellas writes, "This document aims to demonstrate a design weakness found in the handling of simply linked lists used to register binary formats handled by the Linux kernel. It affects all the kernel families (2.0/2.2/2.4/2.6), allowing the insertion of infection modules in kernel space that can be used by malicious users to create infection tools, for example rootkits. Proof of concept, details, and proposed solution (in PDF form): English, Spanish.

Comments

This is so not serious

[Spikeles]

For those who won't read it..

Basically there is this table that contains a list of handlers for the various exes, if if a handler returns a failure the loop that parses the table will stop iterating. If you insert a kernel module first you can take control of all executable types b4 any other handles get to handle it.

BUT...It requires root access and wont work on SELinux. This is a serious how? I mean if you have root access, then the entire system is compromised already.

Re:What about other ELF systems?

[Tyger]

I'd say this is just a specific case of inserting malicious code into a kernel level linked list. Most kernels have linked lists meant to be accessed by drivers. I've actually done something very similar in Solaris using the SVR4 STREAMS driver model. I created a STREAMS module that inserted itself into the TCP stack in such a way that it was totally invisible, but got all data and control commands passed through it. (Excpet I wasn't writing malicious code. In that case, I was hiding it from any potential hackers, as well as applications that might break if the STREAMS modules aren't loaded like they expect.) There are other places it could be inserted for malicious purposes aside from the network stack, though. (Not that the network stack isn't a bad place to be for someone who wants to do some damage, but it doesn't help with hiding rootkits. It would be more useful as a rootkit payload.)

I'm sure BSD has a linked list that could be similarly exploited. It won't have the same capabilities as the Linux binfmt one, but it will have it's own set of things it could be used for.

However, I agree with other users. In a monolithic kernel, once someone has root and can load kernel drivers, or even access kernel memory, all bets are off. The only possible system I can see not being exploitable in such a way would be a pure microkernel architecture with memory protection, none of which I can think of off the top of my head. Mach still has loadable modules. QNX is closer but even QNX lets you register code to be called as an ISR from the kernel, and at that point you have full access to the kernel memory, and you are even conveniently passed a pointed to some kernel data structures so you don't have to try and figure out kernel symbols.

The point is, once you have root, there are any number of ways to compromise the system and hide your exploits. It's good to have the information about as many different ways as possible out in the open, but it's hardly alarming news that there's yet another discovered.