Weakness In Linux Kernel's Binary Format 281
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.
Re:And? (Score:4, Insightful)
Re:Probably none. (Score:5, Insightful)
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 --
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?
Nice catch! (Score:3, Insightful)
Re:This is so not serious (Score:3, Insightful)
As someone else mentioned, Linspire has not done this in a long time. In fact, I believe they've never actually released a stable version that ran as root. They just (quite retardedly) went around claiming that running as root was secure, in defense of what they did once, in a development version, likely never seen by Average Joe.
If that's the goal, Average Joe can fire up Ubuntu, right now. Ubuntu never tells the user anything about root, but requires the user to enter their own password occasionally, so that sudo can grant privileges to change critical system settings, install software, etc. This is the same model OS X uses, yet Ubuntu is more secure, because installing new apps does not necessarily require downloading and executing unverified executables.
Pointless (Score:5, Insightful)
If someone is loading kernel modules on your machine, you've already been owned.
Do I care? Not really (Score:2, Insightful)
Why "exploit" if you're already in? (Score:3, Insightful)
Nothing to see here, move along! (Score:5, Insightful)
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 (Score:4, Insightful)
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:Nice catch! (Score:1, Insightful)
Windows NT and privilege separation (Score:3, Insightful)
Privilege separation - essentially having different types of "root" - is something NT does better than Linux. NT has the concept of "privileges". Privileges are special flags that "tokens" may have. (A token is a set of security credentials assigned to a process; compare to UID and GID in UNIX.) Each privilege grants its holder the ability to override one feature of the security system.
Some examples of privilege:
- "Backup": Able to read any file on the system regardless of ACLs.
- "Restore": Able to set file ownership to anyone, not just themselves.
- "Take ownership": Able to take ownership of any file, which grants the right to change the ACLs.
- "Debug": Able to do the equivalent of ptrace() on any process regardless of ACLs.
- "Load driver": Able to load kernel driver.
- "Lock pages": Able to lock memory pages (prevent swapping to disk).
- "Create token": Able to create tokens, basically allowing forging of credentials (this is how processes get tokens).
There is an account called "SYSTEM" that is considered to have all privileges. However, in general you want to avoid this for obvious reasons. You create an account for the service with these privileges. Trusted services don't have to always be root when they do special things.
However, there is always the problem that certain privileges are privilege-complete: they can be leveraged to gain all privileges. "Create token" makes it easy to become a SYSTEM process. "Load driver" is obvious. "Debug" lets you inject machine code into privileged processes like winlogon.exe. Thus, this privilege system can become a safety system instead of a security system. Likewise, "limited root" in UNIX is an arcane way of doing the same thing, and has the same issues.
I hope this comparison with another OS helps with understanding the many issues brought up. Limiting root is like making water not wet. Or radium not radioactive, if you want to say that you can make water not wet.
Melissa
Re:And? (Score:3, Insightful)
The title reads "Weakness In Linux Kernel's Binary Format", quite accurate if you ask me.
Re:Windows NT and privilege separation (Score:3, Insightful)
Backup: I can read any file, especially the password DB.
Restore: I can replace any system file with a modified version.
Take ownership: I can replace any system file with a modified version.
Debug: I can read system memory and obtain secure information like cached passwords.
Load driver: I can install a rootkit.
Lock pages: I can run the system out of memory and force swapping security related information to disk from where it is easier to intercept.
Create token: not sure what it does in detail, but sounds scary.
Re:This is so not serious (Score:4, Insightful)
No, it's not, and you're an idiot for suggesting it. I really hope you're joking.
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:
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
Re:Sysrq. (Score:2, Insightful)
Re:Windows NT and privilege separation (Score:3, Insightful)
What about SELinux? was Re:A Non-Exploit (Score:2, Insightful)
Adding a binfmt handler (as described in this document) is one way in which a rootkit may be installed. This registration has no SELinux checks, and thus any root process with the capability to install a module (CAP_SYS_MODULE) can register a hook to redirect exec calls.
However, I don't think fixing this makes much of a difference, as I can think of half a dozen other ways of adding such a hook from a module. (e.g. hooking the exec handler, which is pretty easy even though the address of the syscall table is no longer exported.) I think the main lesson of this paper - which the author does not seem to appreciate - is that CAP_SYS_MODULE is a free pass to do whatever you want, regardless of any other SELinux capabilities, and that there is no way to change this without *major* changes to the linux architecture.
Re:Probably none. (Score:2, Insightful)