Slashdot Mirror
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.
yes, a pdf linked from slashdot will last a long time...
oh wait it's already gone
Snowden and Manning are heroes.
Although any auditing is welcome and they may be a problem here, the fact is that it's hardly news and not exploitable. The reports says itself that you have to be root to exploit it. It's already game-over. Yes, look for these sorts of things and find them but it's hardly worth the shock-factor of "Massive Hole Found In Linux" panic headlines.
OMFG! I have a security flaw... but you have to be _root_ to execute it! AHHHHH It's the end of the world!
I discovered a new one too... if you run rm -rf / as root you'll bork your system!
We should all go back to windows, where rm doesn't exist ^_^
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.
I don't need to test my programs.. I have an error correcting modem.
"Yes, look for these sorts of things and find them but it's hardly worth the shock-factor of "Massive Hole Found In Linux" panic headlines."
If I found Goatse.cx in Linux? I'd panic too.
For instance, lock it away in a chroot jail.
/usr/bin/foo.pl" or whatever.
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
However, I'd like to actually read the PDF and find out if I'm right about this. Damn Slashdotting.
Don't thank God, thank a doctor!
This was forwarded by our Sec Admin tonight in case you haven't seen it: http://www.securityfocus.com/bid/20249
What if the Hokey Pokey really is what it's all about?
Depends on the friends and the distro, but let's see. Debian prompts you to set up an ordinary user/password, as well as a root password. Gentoo does the same, only via documentation, not an installer. And Ubuntu, the distro most friends would send noob-friends to, does not set up a root password at all -- all root access on Ubuntu has to go through sudo.
Most Windows/IE attacks don't require you to even have local access, let alone root.
Don't thank God, thank a doctor!
I've mirrored the English PDF.
|/usr/games/fortune
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.
Don't thank God, thank a doctor!
Linux has a feature that allows you to register a new binary format loader. Of the traditional formats, ELF is the most common, a.out is ancient, I don't think I've ever seen an a.out executable on a Linux machine). But on Linux, for example, if you wanted java programs to run automatically when you execute them then you could install a loader for java files that runs them through the interpreter/jvm.
I don't know which other unixes have this capability, but IIRC Linux was the first so it follows that any other implementation is architecturally independent, so shouldn't share the same implementation flaws.
simply linked list
As opposed to difficultly linked lists?
Do they mean "singly" instead of "simply"?
A weakness in the binary format? OK, who's to blame here, the ones or the zeroes?
You'd have thought they'd have caught this sooner. It's not like it's that long of a list to exhaustively test.
Whether this is a show-stopper or not, it's a great example of what can happen with tons of eyeballs on a project. This is the type of bug that proprietary vendors would suffer to discover with such limited resources on a single project. It makes me wonder how often proprietary kernels are retooled *after* a flaw has been found in a similar OSS product.
If you're half as beautiful naked, you'd be 4 times as beautiful with twice as many clothes on.
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.
FYI, I believe it is the kernel itself that interprets the #!(interpreter)\n at the start of a file, not the shell.
But anyway... I don't think you can constrain root with chroot(2) anyway. root can mknod(2) himself a device file and access your filesystems directly if he wants. Or he can do the same for one of the mem(4) devices. Or call ioperm(2) and talk to hardware devices with iopl(2). There are probably dozens of other methods to escape from such a 'jail'.
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. ;-)
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.)
.... 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.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
. . . .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?
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
Who cares? Frankly, 2.0 has been around for about 10 years. Which, in tech years, is a freakin long time. This is easy to remember because an MKLinux server on the network runs 2.0, which was built in 1997. I don't recall any major rootkit problems in the past decade. So, if nothing major has happened in the last ten years targeting this particular flaw, then why do we lose sleep over it now? I'm not gonna worry about it. What I am gonna worry about is the new call structure in 2.6.17 that's messed everyone up.
Because it's damn hard! Nobody here seems to realise that the point of this paper is (I'm guessing) that there's yet another neat way to code up an exploit "without depending on the sys_call_table[]" - it's in the damn title.
If you know anything about the topic, which I guess most people who've commented don't, then it's near trivial for an attacker to write code to do unauthorised stuff if they have the address of the symbol sys_call_table, but that's been removed to make life harded for shellcoders.
And "having root" doesn't mean an attacker sits down at an xterm with a root account, it might mean that he can remotely trick some system service into running 24 bytes of instructions as root or something. So stop being so dismissive of this sort of research.
If this requires inserting a kernel module, a kernel module has as much privledge as the kernel itself so why would anyone bother with "exploiting" some kind of flaw. This seems like opening a door with a key and then kicking it down from the inside.
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!
>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.
I dislike Microsoft, but I like Windows NT much more than Linux. Win32 is crap, but the NT kernel is great. NT's security model is much better than Linux's. Note that this is the model; NT being insecure is not because of its model.
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
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
If you get to the point where you can load code into the kernel (as in; load a module), then you can replace *anything* in the kernel and you effectively own the box.
There's no bug here.
Because people don't know the correct tags. It should be:
> fud, !fud
Quoth the FAQ:
If all you have is a grenade, pretty soon every problem looks like a foxhole -- MightyYar
It was a joke, dork. Try it and you will indeed see that it does exactly what I said it does... just not in the way you expect it to.
rootkit: "a set of software tools intended to conceal running processes, files or system data, thereby helping an intruder to _maintain_ access to a system while avoiding detection." (Wikipedia)
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.