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.
> of simply linked lists used to register binary formats handled by the Linux kernel.
Is the fact that I only allow elf and a.out via my kernel config enough to mitigate this, or do I have to RTFA?
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!
While this may not be a security risk on Linux, I need to ask, how does this affect other UNIX systems that use the ELF executable format?
FreeBSD, OpenBSD, and NetBSD all use ELF. Solaris, SCO UnixWare, and SCO OpenServer also support ELF on the x86. Can similar attacks be launched against such systems?
Is a system like NetBSD, which does not use dynamically loadable kernel modules, susceptible?
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!
simply linked list
As opposed to difficultly linked lists?
Do they mean "singly" instead of "simply"?
Isnt there an option to prevent the loading of modules ?
Would this not remove the list from the kernel.
Oh wait if i am root i can just recompile the kernel with the option on again !
Perhaps it is surprising for more than one to know than kernel is the one in charge to recognize the different binary types exiting in the system, identifying them with the first 4 (four) bytes of the file.
WTF? Who proof reads these things?
the french version.
Mod -1 offtopic +1 funny -BIGNUM gross
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.
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.
This will make you think twice before installing non free software on your nice free system. You should already think twice about it because of all the advantages free software has, but every now and then you run into a device driver or game you want. If the computer is just a toy anyway, it does not matter, but it the computer is what you use for email, records keeping and research you should be careful. Anything you have to install as root that you or a package maintainer can't inspect should be assumed bad for security. Yeah, I know, you were in trouble before this little "exploit" but it's good to reamember why you should worry in the first place.
To get around the device problem, I do a little research up front and take it back if things don't work out. I refuse to torture myself with things like ndis wrappers to run a network card when there lots of others that work out of the box. Few non free programs besides accelerated graphics drivers have given me anything worth while.
Friends don't help friends install M$ junk.
Basically loadable modules are an obvious "back door" and hardly a security flaw if managed properly. If you're going to hand out module loading access you're going to get it where you deserve!
Engineering is the art of compromise.
There are patches to limit root powers. RSBAC is the most up to date i think, one of its security moduels can set root privledges for users and programs, if you set it on root itself, it has the effect of limiting roots powers. Its mostly good for desktop systems that might require some programs (nmap, say) to have root abilities, but only requires some abilities, better then running sudo i would think
1) You cannot chroot root and get the expected result, for the exact reason you specified.
2) The shell doesn't interpret shebang, the kernel does.
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.
There are numerious ways for root to break out of chroot jail. It's simply not good enough.
So trying to limit root by chroot is a fools errand.
What would be more interesting is how does this 'vunerability' apply to 'container' style things?
If I get root in OpenVZ or Linux Vservers can I use this to attack the host system?
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. ;-)
Find bug, patch it and write 16 page article about weakness in Linux Kernel...
lemme guess, you run "sudo -u root su -"?
.... 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;
How come every story that I find interesting gets tagged fud, notfud?
Does this sig remind you of Agatha Christie?
. . . .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.
Also, /dev/kmem
Attributed to the Seabees - the Navy construction guys - usually civil engineers.
This issue is a bit more complicated than you think.
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.
I long for the days of yore when 1.2 was the kernel of choice. It was an easier time, I could actually understand most of the kernel config options back then...
Kirby
I blame the twos.
"You saved 1968." - Ms. Valerie Pringle to the crew of Apollo 8
Linked Lists have been touted as bad for years by Main Frame types. They (Main Frame techy types) have insisted for YEARS that linked lists not be used for the exact same reasons. Just so you know, I am not really a main frame type techy person, I just have worked with alot of them getting software installed on the big iron, and when I first tryed to implement a piece of software using linked lists, they smashed me like the "Small Computer" person I am :o)
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
I remember back at Defcon 9, a blue haired guy named 0ptyx was presenting something he called "Kernel Intrustion System" (KIS). It was a ridiculously cool rootkit.
During his talk he mentioned a topic that hasn't really been jumped all over by a lot of people since then: signing kernel modules. If nothing else illustrates that
it's a good idea, I hope this does.
The (sub?)title of the article is "Polluting sys_execve() in kernel space without depending on the sys_call_table[]". The idea is that if you're auditing Linux, this is a problem, because it introduces another way to hook into sys_execve() without modifying the syscall table. If you put the kernel into ROM, then you might otherwise be able to assert that execve() can't be messed with, given certain conditions. This bug renders that assertion invalid.
But yeah, it's not exactly something that sysadmins need to get up at 1AM to patch their systems for.
http://outcampaign.org/
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!
As part of my sales pitch when convincing our company to start developing for unix, I explained that ordinary users can't remove system files. To demonstrate, I logged in to the newly installed SCO Xenix console, and logged in as a user. Then I did "rm -r /". I confidently explained that only that users files would get borked, and that was why all the "permission denied" errors were appearing. "What errors?" the boss asked. To my consternation, there were no errors, and after a few minutes, the shell prompt came back. But the filesystem was empty. How could that be? Several hours later, after reinstalling from diskette, I found the answer. SCO distributed their system with all files and directories set to rw/rwx. Everything.
The only valid reason I can think of for wanting to read the kernel memory is to debug or otherwise inspect the state of the running kernel. Write access might be useful for some testing purposes, e.g. to create a particularly complex scenario and see what happens when it is allowed to run.
That is really of interest only to kernel hackers; it's certainly not something that Joe User needs to ever do. I assume that people doing work on the kernel have ways of debugging it and monitoring its memoryspace that gets around it's built in protections, or can just run the whole thing inside a VM where they can monitor all of its inputs and outputs directly.
Other than that I agree with you, there's no good reason even for root to be meddling about in there. However, I do understand that people who are used the "UNIX way" may balk at that philosophically; if you're used to the theory that root is God and root can do anything they want to any part of the system, it's a little off-putting to be told that anything is off-limits, even if it is "for your own good."
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
>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.
That vulnerability is purely theoretical.
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
There actually is something called sysrq, which might concievably be used to create this functionality. Ctrl+alt+backspace isn't it. You may be thinking of ctrl+alt+fn, where n is a number from 1-12. That would actually be useful, but that isn't quite the password prompt I was looking for. I'd rather have it not be a password prompt, simply a dialog box that truthfully represents which app it is and what it's trying to do.
And no, this can't simply be done with another X server. Another X server may be a useful component -- emphasis on "may", since it would flicker the screen annoyingly, but fast user switching on Linux does that too -- but we need programs to be able to send requests to some sort of sudo server, which then prompts the user (on the other terminal) with exactly what was requested and which app requested it, and allow the user to set policies.
It would be more useful if the window manager (being the first X client started, thus sort of an X version of init) could guarantee that a particular keystroke will never be caught by another app.
Actually, Vista seems closer to being able to do this, but I don't think they require a keystroke.
Don't thank God, thank a doctor!
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.
If this type of responses are posted about some MS weakness, the whole ./ crowd will cry bad engineering, bla bla bla...
But of course, being able to backdoor a Linux kernel is not important....
Bah...zeaots....
... the door's open, and your climbing through the window.
Although there's the good point of a stealthy backdoor, as mentioned above...
But since you're root there always ways to do that, so, the "bug" is not really a vulnerability.
Zapotek
Pavlov. Does this name ring a bell?
Wow, a linked list containing binary format handlers allows to insert a new one as root, as it is designed to do. The linked list indeed must have a serious bug.
This has got to be the most ridiculous "security problem" since the non-existant firefox bug. I hope the poster is ashamed of himself.
The "Shellcode \"Security \\\"Research\\\"\" team" (double-quotes intentional) seems to fall for the same crap as most other security "researchers", doing PR instead of doing something useful. Even if they actually find a real bug (which is not the case here), instead of fixing it, which would actually be doing something productive, they produce lame "papers" detailing the obvious for even bigger idiots.
Guys, get a life and do something useful, like _fixing_ _real_ bugs. Noone is going to pay you for this crap, no matter how much you want it.
The problem is that you need to be root to do this. If you already have this access, the system is already "yours". One may do with it whatever you wish where simply leveraging the way the kernel loads binaries is yet another trival thing. There might be some "tightening up" but this is no more of a security risk than say "compiling source code for a kernel module that is of a dubious source".
You got a nvidia card. You need to download a kernel module in order to see the cube in XGL. You visit nvidia to download the modules. A malicious hacker has spoofed DNS and with a man-in-the-middle attack, instead of going to nvidia's ftp server you download "the module" from ftp.b0t.net. Then you install the nvidia module every time you boot.
Scenario 3. You have a card from intel. They don't allow redistribution of firmware, so you must download it from mirror.nigeria.intel.com. However, the server has been compromised with bribery and sabotage attack and the web server sends malicious modules to selected hosts.
ps- nice site!
I've always wanted to be able to say that myself :-)
They claim (at the end of the pdf) to be security experts. Yet all they have discovered is that if you have gained root access, you can exploit the system. That's not new news, that's not even news to begin with. Once your attacker gains root, the game's over.
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.
A little note on Gentoo: if you do the CLI-based install, yes, it doesn't prompt you to set a root password, and you're right, it does prompt it via documentation; however, with the livecds now available (as of 2006.0 release), you can use a console-based installer or gtk-based installer, both which do prompt to set the root password (gives a clear option to).
Use ptrace() to take over the shell already running on that tty. Optionally insert code which does a fork, so that the shell keeps working and nobody notices. Go to town.
How to make a fool of himself - Lesson 1
Every few months, yet another news story appears which earns Linux their true slogan:
"Linux: got r00t?"
Not an autoconf expert and just speculating:
.pdf or image file with badnasty code in it)? Then the usual "./configure; make; sudo make install" that we casually run so often could execute the evil file as root, as part of the 'make install' sequence.
I wonder about hacks that installing software as root could allow. What if an autoconf based install package included a temporary or permanent 'data' file (perhaps a phony
The data file could even be clean on disk, and the badnasty code inserted only in the in-memory copy that is either run in memory or saved to a temporary file and run, then wiped. In cases where a file format has some extra leftover space at the end, the banasty code could be put there, and only a few bytes inserted into the front of the file in memory could be enough to cause execution to jump into it.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
I'm no security expert, but I'm not convinced that such attacks are necessarily difficult for those who have the motivation to do so.
..." The operator dove for the Big Red Switch, instantly cutting power. The entire computing facility was down for days as they had to repair hardware problems that resulted from the sudden loss of power and reconstruct the disk state from backups. This exploit didn't require root (admin) access, but he could easily have written a program that asked for confirmation from the operator and required entering the password.
Every Unix sysadmin, programmer and maybe computer user would be advised to read "Reflections on Trusting Trust", the lecture given by Ken Thompson when accepting the 1983 Turing Award with Dennis Ritchie. These two together created the original C and Unix.
In his lecture, Ken demonstrates how (with the appropriate access) one can introduce multiple trojans into the compiler, so that every time either gcc or login are compiled a back door is compiled in. In another comment, I speculated on the possibility that the common practice of installing an autoconf-generated package, using the sequence "./configure; make; sudo make install" might make it possible for a carefully constructed autoconf build to take advantage of this root access to do evil; Dr. Thompson's lecture provides an excellent example of how this might be exploited.
The lesson is that social engineering can often provide the security breach necessary to become root, regardless of the system. Just as the only way to absolutely prevent network attacks is to disconnect, the only way to absolutely prevent local attacks is to never turn the machine on.
In my own experience, someone at the school I attended some years ago discovered he could print to the timesharing system's console terminal, and wrote a program that duplicated the output headers of the OS control program (called VULCAN). His program 'informed' the operator that it was erasing every program on the main hard drive, one after another: "deleting FORTRAN; deleting BASIC; deleting VULCAN;
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
No. X is still broken. However I understand there is a seperate project Nitpicker (part of TUD-OS)to solve that.
But it doesn't seem like it's on as deep a level as I'd like. It's better, but it still means that once I send a document to Firefox, I have no idea what Firefox will do with it. Still, that is a lot better.
I am not sure what you mean. It was the goal of the EROS-OS project to break software into tiny chunks and apply least priviledge to each. One could get even finer grain protection if writing with a safe language. Even so, if Firefox as a whole is malicious there is no way of stoping it misusing whatever rights you give it.