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.

Problem: Sometimes you want to limit root.

[SanityInAnarchy]

For instance, lock it away in a chroot jail.

Solution: Don't give your chroot jail access to the binfmt filesystem. I'm not sure how this can be done, though, as root is allowed to mount pretty much whatever it wants.

Real solution: Don't bother to compile in binfmt support. The only reason for the kernel to recognize any format other than elf or a.out is to call an interpreter to run that file with elf or a.out. Every shell I know of recognizes the shebang at the beginning of most scripts (perl/python/ruby/bash), and you generally launch programs through the shell. Most people will be running programs from the GUI, where this is even less of a problem -- for the most part, they'll be clicking on icons which contain a command like "perl /usr/bin/foo.pl" or whatever.

However, I'd like to actually read the PDF and find out if I'm right about this. Damn Slashdotting.

Not the only one today

[Aqua_boy17]

This was forwarded by our Sec Admin tonight in case you haven't seen it: http://www.securityfocus.com/bid/20249 [securityfocus.com]

They'll fix it.

[SanityInAnarchy]

They'll fix it out of pride, and because it's the right way to do it. That's assuming this is actually a flaw -- a buffer overrun or something. For instance, if it's some retard saying "Oh cool, I can install a rootkit by changing a couple of bits here in /dev/kmem", then no, they won't fix it. But if it only requires access to, say, the binfmt_misc filesystem, then it is a bug.

And it's important to remember things like this when you see Symantec, Microsoft, and others trying to spread FUD about Linux security. If anyone cares about this bug at all, even just as a matter of keeping the code neat, it will be fixed -- but it will also drive up the numbers of "Linux exploits patched recently". Always, always, always look at the relative severity of the exploits.

Disable modules

[DeathAndTaxes]

Yeah, a good while back, there was discussion about the possibility of inserting malicious kernel modules to take over a system. About that time I decided that all my linux servers would have modules disabled. I'm already an advocate of simply compiling support for hardware directly into the kernel (instead of as modules), but I just started taking it to another level. Sure, it means sometimes that you have to restart a system to gain new functionality, but that's much better than the risk of getting owned by some kernel module. ;-)

Re:Compile Options

[Tyger]

It wouldn't require a reboot any more than Windows viruses require a reboot to start their infection. Just because the kernel is fully monolithic and does not have loadable kernel modules does not mean you can't change it. If you have access to /dev/kmem, you can still open it up and modify kernel data structures and insert code into kernel memory yourself. (In fact, IIRC, that's exactly how the original implementation of LKM for Linux worked.)

Re:This is so not serious

[SanityInAnarchy]

If you assume Average Joe doesn't get even the least suspicious when something asks him for a password, then Average Joe is doomed.

Think about it. Average Joe will demand admin access in order to change settings and install software. So we have to choose between removing that access entirely (so there's no password for Joe to type), or praying that Joe is smart enough to realize he's giving something admin access.

Really, can you possibly think of a solution to this kind of stupidity? Hell, I could simply craft a website -- maybe a Flash page -- that looks just like the Ubuntu password prompt. That way, I don't even need local user access.

I say this solution is reasonably secure because we don't really have anything more secure. Kind of like how Democracy sucks, but it's also the best we've got.

Securing a System from "Root". . .

[WhiteWolf666]

. . . .is like securing a system from "real-life" hardware access.

It makes little to no sense.

Root-level "hacks" are an oxymoron. Once you're root, the skies the limit. Why bother just tinkering with kernel modules when you can just replace the whole kit-n-kaboodle?

Re:Windows NT and privilege separation

[LinuxIsRetarded]

Create token is the 'meta' privilege - it lets you create a system level token with *any* privilege and then switch to that context... essentially anyone/thing with that privilige has all rights to the system and you cannot stop them (takes a little work.. it's not got a GUI or anything, but anyone with access to MSDN online could work it out).

You still need the user name and password to be able to create a token to execute code as another user (look at the documentation for LogonUser). To state that anyone with this privilege "has all rights to the system and you cannot stop them" is incorrect.