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

Re:And?

[Vo0k]

still, a stealthy nest for your rootkit is always welcome. A system should remain transparent enough to make the intrusion obvious, this trick allows to install stealthy backdoor.

Re:Probably none.

[SanityInAnarchy]

This argument has been tried over and over again. It is prohibitively difficult to make an attack like this work.

The only way I know of to change the user's password requires the user to type their password.

Yes, you could use a keylogging-type attack, but sudo does make this prohibitively slow unless you really know what you're looking for. Even if you do, you still have to wait for the user to answer a sudo prompt.

You could theoretically crack the user's password from the password hash, but this is both time consuming and impossible -- /etc/shadow is not readable by ordinary users.

Beyond this, you could try a phishing attack -- put up your own sudo-like prompt and hope they bite -- but that's about it.

How would you propose to remedy this situation? Do you switch to another VT or use a magic sysrq key everytime you become root?

Pointless

[ZxCv]

.... but that's much better than the risk of getting owned by some kernel module. ;-)

If someone is loading kernel modules on your machine, you've already been owned.

Nothing to see here, move along!

[Lost Found]

As the first person who replied to this announcement in LKML, I will certify that this "weakness" is pretty silly. Here's what the claim is:

1. You must be root
2. You must be able to load an arbitrary kernel module
3. You write an arbitrary kernel module that calls a kernel function to install yourself as an "binfmt handler"
4. That kernel module is put on the _front_ of the list instead of the _end_
5. Every program that runs now ends up calling your "binfmt handler" first

Their solution:

1. Put it on the _end_ of the list instead of the _front_ when it registers itself, that way it only runs if the binfmt cannot be identified...

This is literally just as stupid as discovering that you can call fork() and exec() with an argv of "/bin/rm", "-rf", "*". Oh no, everyone must patch their systems! Seriously, anyone who can load an arbitrary kernel module could technically do _anything_, including replace the whole kernel image from the inside out!

That's an insightful question

[Beryllium Sphere(tm)]

>How would you propose to remedy this situation? Do you switch to another VT or use a magic sysrq key everytime you become root?

Also known as the "trusted path" problem.

Everyone ridiculed the idea of pressing control-alt-delete to log in (and it is pretty funny), but it addressed a real problem. Once you pressed the "secure attention sequence", you had a theoretical guarantee that a phishing program wouldn't have the keyboard focus. Ctrl-Alt-Del was the "magic sysrq key".

There's another kind of attack, too. A typical sudo configuration only prompts you for a password once then lets you sudo without a password for 5 minutes or so. So imagine a background process that waits for a sudo command to be entered and then issues its own "sudo su" or "sudo sh". Or that skips the waiting and just issues one every five minutes until it gets lucky someday.

Not that I'm *paranoid* or anything.

Re:This is so not serious

[SanityInAnarchy]

But an exploit in the Linux kernel that requires root-access is as serious as any other exploit.

No, it's not, and you're an idiot for suggesting it. I really hope you're joking.

Average Joe: OK!

Average Joe will have already hosed his system, and there isn't a damned thing we can do about it other than send Average Joe to a newbie concentration camp. (Before you say anything, I was raised Jewish. I don't really condone newbie genocide. Think of it more like driver's ed.)

Let me put it this way: If Average Joe will type his password to add a precompiled binary to his kernel, he'll certainly type his password to install a custom kernel to his /boot. He also won't have a problem with rebooting -- Windows makes him do that all the time, whether or not the installed program really needs him to. Thus, even if we completely prevent the kernel from being modified at runtime, the kernel can be replaced wholesale.

That's ignoring the numerous other ways to modify a running kernel. /proc/kmem is one. But this exploit in particular requires a module to be loaded. If you can convince the user to load a module, you don't NEED this exploit -- there is nothing to stop you from rampaging all over the kernel space anyway.

But even with modules disabled, it's far too easy for root to install a rootkit, or do other evil things to users. Hell, a rootkit could be as simple as writing a glibc wrapper. And if Average Joe will go root so easily, Average Joe is probably not a good target for a rootkit. How often is he going to actually look for files that a rootkit might otherwise hide? Couldn't malware simply hide in dot-files and be perfectly safe from Joe?

There simply isn't a way of giving the user enough power to do what they want, without also giving them the ability to screw it all up. The only solution for morons like Joe is to not give them that power. Reserve enough for admins, and Joe is not an admin.

Your statement is like saying a pistol you can shoot yourself in the foot with is just as dangerous as a pistol that explodes in your face. Look, it's simply not possible to make a useful handgun that you can't shoot yourself in the foot with -- by its very definition, a handgun will shoot wherever you point it, and it will always be physically possible to point it at your foot. You have these options to attempt to secure Average Joe:

• Actually teach people about gun safety before you give them a gun. (Teach sane computer use in the store.)
• Don't let people have a gun unless they can use it safely. (Test people's computer sanity in the store.)
• Offer your services as a bodyguard or hitman instead. (Don't let them have the root password. Admin their computer for them, installing software when they ask, updating when they don't.)
• Sell them an armored boot (firewall, online AV). Some will take it off because it's uncomfortable (blocks things they want), or to get a better shot at their foot (willingly let in known malware).
• Sell them health insurance (antivirus) and emergency medical care (recovery tools, Geek Squad).
• Sell them prosthetic feet, which they can blow off and replace at will. (Sell them a new, faster computer, rather than clean up their old one.)

I can't think of any other alternatives. Sure, you could give them a club instead of a pistol (UAC, Knoppix, restrict them to oblivion), but they'll still be able to beat their foot into a pulp (though it'll be harder), and it's a hell of a lot harder to club birds down than to shoot them down (insane restrictions make it harder to use the computer in the first place). The current approach seems to be to try to grab their hand every time they're about to, and say "Are you sure you want to blow your leg off?" But no one pays attention, because we do that anyway when they are shooting in the right direction (UAC being annoying), and sometimes