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.

1 meg PDF?

[Lehk228]

yes, a pdf linked from slashdot will last a long time...

oh wait it's already gone

Re:

[Kingrames]

Let's hope it didn't contain the malicious code. You know someone thought of it.

And?

[ledow]

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.

And? Hol-e terror.

[Anonymous Coward]

"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.

Re:

[Anonymous Coward]

How many average-Joe-who's-friends convinced-him-to-run-Linux's run as root, though?

Probably none.

[SanityInAnarchy]

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.

Re:

[oKtosiTe]

No, only the initial user account does.

Re:

[bcat24]

Werd. That's why the first thing I do when I set up a Ubuntu box is enable the root account and make sudo use the root password, not the user's password.

sudo - unclear on the concept

[poopie]

hat's why the first thing I do when I set up a Ubuntu box is enable the root account and make sudo use the root password, not the user's password.

lemme guess, you run "sudo -u root su -"?

Re:

[bcat24]

That's why the first thing I do when I set up a Ubuntu box is enable the root account and make sudo use the root password, not the user's password.

lemme guess, you run "sudo -u root su -"?

Heh, not quite. Here's what works for me.

1. sudo passwd # set a root password
2. sudo visudo # add "rootpw" to the "Defaults" line

PS: "sudo -s" is enough to get a root shell.

Re:Probably none.

[smash]

Knowing about how linux works doesn't exclude you from the set of potential ubuntu users.

I've adminned Linux since 1996 (1996-2001 as an ISP sysadmin, 2001-2004 for corporate mail, proxy, IPSec gateway, etc), yet most of the time these days for a desktop I install/use/recommend Kubuntu. Why? Because it just works for the most part. I've been through the rolling my own distro from scratch, building all my stuff from source games and to be honest, I have more important things to do these days :)

Sure I'll muck around with that sort of thing from time to time, but when I just want to get work done, *ubuntu is quick and easy.

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?

Re:

[cortana]

One way to overcome the problem is to not use su or sudo. In a secure system it should never be possible for a process to increase its privilige level.

But remember, secure systems are a pain in the arse to use.

Re:

[SanityInAnarchy]

Why should a secure system never allow a process to increase privileges? I think we just need a secure way to make sure the user knows exactly what's going on every time a process attempts to. For instance -- I think there's a word for this -- create an unbindable key combination, and every time you see a security prompt, press that to make sure it's valid. Or use it to enter your password. Or better -- have a completely separate UI, accessible through said unbindable key combination, so security prompt

Re:Probably none.

[TeraCo]

but this is both time consuming and impossible

Phew, I'm glad it's not just impossible. That might have been risky.

Re:

[SanityInAnarchy]

It used to be risky. Password hashes used to actually be stored in /etc/passwd, where anyone could read your password hash. If there was a weakness in the hash algorithm, or your password was particularly short, they could brute-force it that way -- hence, "time consuming".

On most modern systems, it is also impossible, because the actual password hashes have been moved to /etc/shadow.

If you are root, you can still attempt to brute-force them -- which would be time-consuming and almost never has a point.

Re:

[TeraCo]

Thanks for that, however I already knew all that though, and was just making fun of the fact that he said: "In addition to it being time consuming, it's also impossible."

Re:

[SanityInAnarchy]

This has got to be the most obnoxious thing people do on Slashdot. Yes, I got the joke. It was funny, I laughed. My comment is also actually relevant to the discussion.

Old Navy Joke (I think)

[NotQuiteReal]

Heh, the quote that comes to mind is "The difficult we do today; the impossible takes a little longer."

Attributed to the Seabees - the Navy construction guys - usually civil engineers.

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:

[cortana]

How do you change their password?

Re:

[CastrTroy]

because a user may not give their user account a strong password, because it's just a user account. They may not realize that their user account password is also (effectively) the password for root.

Re:

[IWannaBeAnAC]

I cannot RTFA as it is slashdotted, but if you need to be root then yes, it is over and not much more to be said. Any non-hardened linux kernel will likely have things like /dev/kmem, or even something like insmod will let root insert code into kernel space for goodness sake!

A hardened kernel would most likely not allow runtime binary formats anyway (I'm pretty sure you can restrict it to just elf if you want). So it is a complete non-event. I'm not sure the kernel developers would even bother fixing i

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.

Re:

[Tyger]

It wouldn't be just "changing a couple bits here in /dev/kmem", but from the summary (Still waiting on the article) it sounds like it is pretty close. It could potentially be "fixed" by changing how things are handled (Again, still waiting on the article) but there are so many ways a system can be compromised if someone has kernel level access.

Re:

[SanityInAnarchy]

My copy of TFA won't be done downloading for another 15 mins, so I'll take your word for it. Just checking, though: Does this exploit require you to be able to insert a custom module? Or does it simply require binfmt_misc?

If it's an "exploit" resulting from inserting a custom module, then I doubt anyone will change anything, because this is not a vulnerability.

Re:

[Chrax]

Yes. It requires module insertion. It's nothing terribly special.

It took me over an hour to download, so for the next day or so (or if the writers insist I take it down), I'll be hosting this file at: http://effigies.ath.cx:85/~chris/binfmt-en.pdf [effigies.ath.cx]

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:

[dubbreak]

Any rootkit is going to be stealthy. It hooks to kernel calls, so say you search for the binary on the hardrive, hmm well that involves a kernel call which you grabbed so you respond by saying all files but yours is there. What about running processes? Oh yeah, have to make a kernel call for that, which was intercepted again by the rootkit, and guess what, it doesn't show that it is running!

The original poster was correct, this isn't news. It is trivial to install a rootkit with root access. Do this in us

And, Who do You Trust?

[twitter]

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

Re:

[Cheapy]

Good thing this headline wasn't a "Massive Hole Found in Linux" panic headline!

Re:

[Yvanhoe]

but it's hardly worth the shock-factor of "Massive Hole Found In Linux" panic headlines.

The title reads "Weakness In Linux Kernel's Binary Format", quite accurate if you ask me.

Re:What about other ELF systems?

[IWannaBeAnAC]

With the caveat that I cannot RTFA as it is slashdotted, if the summary is in any way accurate then it will not affect the BSD's or Solaris. SCO I don't care about, especially as it would only affect them if they stole the relevant code from Linux in the first place.

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.

Re:What about other ELF systems?

[Tyger]

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.

Too bad you have to be root.

[czehp]

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 ^_^

Re:

[networkBoy]

deltree

I think they removed it from the normal windows distro back in win2K though.
-nB

Re:

[PitaBred]

Yeah. Del now deletes directories and all files under it :)

Re:Too bad you have to be root.

[Lehk228]

that is more due to limitations on NTFS and FAT* than self protection

unix filesystems can delete an in-use file and only physically remove it when it is no longer in use, windows cannot do that. hence having to reboot for so many updates and some configuration changes (such as changing host name)

Re:Too bad you have to be root.

[Tony Hoyle]

You misunderstand what FILE_SHARE_DELETE does.

That just allows other processes to open a file that is opened with delete access. It does not allow you to delete a file that is in use - that is still impossible in Windows.

Re:

[Tanktalus]

Actually, there is a reason for this. And it's not just limitations of the filesystem. It's that it actually was not uncommon for Windows users to "accidentally" delete their Windows directory (sometimes thinking they're clever for freeing up space for other things). Since there is no filesystem security on Windows by default, you ended up deleting many (but not all) DLLs ... and next time you tried to load something, crash. (Had that happen to my dad with Win3.1. Luckily, Win 3.1 was easy enough to re

Re:

[tomstdenis]

yeah no shit. As root you can just pwn things running ring-0 [or equiv] on the processor. You don't need to exploit a bad API to do this.

Now if you could insert modules as a non uid=0 user then that'd be something...

Tom

Re:

[Foofoobar]

MOD PARENT UP. I nearly puked I laughed so hard.

Re:

[Duhavid]

On AIX, I think it was a last 3.x version, a friend of mine
found that a "simple" chown -R from the root was quite
sufficient to bork a system.

Re:

[The_Wilschon]

if you run rm -rf / as root you'll bork your system!

Not if you use the immutable attribute. `chattr +i files' It protects the files so they cannot be changed at all (hence the name) even by root. Of course, root can remove the attribute, so it is not a security measure, but a protection against typos and stupidity.

Re:

[SanityInAnarchy]

From what I understand, without reading TFA (currently slashdotted), all you have to do to prevent this attack is to disable binfmt_misc. I believe the attack is works even if module loading is disabled, so long as binfmt_misc is loaded or compiled in.

Re:

[The_Wilschon]

If you can get to kernel mem in any unauthorized way, even from root account - it is a big problem.

If root does not constitute authorized access, then what does? Is there some kind of supersuperuser that only the pentagon knows about? This doesn't make sense. I suppose you could have a separate account from root which could access kernel memory, but root can su to any account it likes, so that doesn't really help.

Re:

[meowsqueak]

I agree totally. 'root' doesn't mean unrestricted access to the machine's resources. If it did, you wouldn't want to run *anything* as root without risking total disaster.

(Formatting /dev/hda is not the same as overwriting part of a process's address space and causing it to spew random garbage all over the disk sectors).

This is so not serious

[Spikeles]

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.

Re:

[cp.tar]

This is akin to an acquaitance of mine who claims that Linux is insecure because if you have physical access, it's usually easily crackable.

Well, duh.

Re:

[windex]

That's crap. It dosen't work on SELinux, but may if any bypass-type holes in SELinux show up.

Any complete memory protection/RBAC system can prevent stuff like this (e.g. http://www.grsecurity.org/ [grsecurity.org]), but it shouldn't. For example, you can make it impossible to insert kernel modules after startup in grsecurity, but for a long time a 'root only' bug in the kernel allowed you to insert a module and execute it anyway (this may be the same bug, who knows). Good RBAC setups assume root is untrusted.

Re:

[Feyr]

you can remove the privilege to insert kernel modules in the standard kernel too, even by root. no need for a fancy patch. look up linux "capabilities"

Re:

[fimbulvetr]

It seems to me that having root access != having easy backdoor access to exes.

For instance, if I can load a wrapper around your financial program, without modifying your financial program (So AIDE would find it), I could more easily grab your data.

For the record, SELinux is nice, but should not be considered your first defense against attackers. Even if it's considered a good secondary defense, the primary defense should certainly be fixed ASAP.

Re:

[julesh]

It seems to me that having root access != having easy backdoor access to exes.

For instance, if I can load a wrapper around your financial program, without modifying your financial program (So AIDE would find it), I could more easily grab your data.

Yes, but there are already so many ways that modification could be made:

* Modify libc.so to perform the task you want (applicable to all modern unix systems)
* Modify ld-linux.so or equivalent to perform the task you want (applicable to all ELF-based systems)
* Modi

Re:

[jesdynf]

I got aggravated as soon as I saw the summary -- hey, big news guys, install ssl/omgpwned.o into the kernel as root and you're in ~o trou-ble o~ !!!

'Tards.

This is not limited to executable handlers.

[EmbeddedJanitor]

You could do just about anything you want via modules, including installing all kind of nasties via the reported mechanism, or by installing a nasty file system, driver, whatever. For example, you could write a "file system" or "device driver" that allows tou to write in other modules etc from user space.

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!

Re:

[SanityInAnarchy]

... because some "user friendly" distros make the default user root

Name one.

and not everyone uses SELinux?

I can name a user friendly distro that has SELinux enabled by default: Fedora.

Re:

[cortana]

AFAIK, Linspire hasn't done that since before it changed its name from Lindows.

Re:

[SanityInAnarchy]

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.

It should be secure for Average Joe. He might not be running Linux now, but it should be the goal.

If that's the goal, Average Joe can fire up Ubuntu, right now. Ubuntu never t

Re:

[bogado]

There is only so much you can do for your clueless users. If the user is willing to type a password to see "dancing pigs" then you might as well ask for his bank acount and password. :-)

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.

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

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.

Re:

[cortana]

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'.

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]

Mirror

[paulproteus]

I've mirrored the English PDF [jhu.edu].

simply

[Anonymous Coward]

simply linked list

As opposed to difficultly linked lists?

Re:simply

[Penguinoflight]

Most CS types would say that SLL is Singly Linked List. The construct allows for references to next, but not to previous.

Simply?

[hey]

Do they mean "singly" instead of "simply"?

Weakness In Linux Kernel's Binary Format

[nick_davison]

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.

Re:

[Nahor]

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.

I found a weakness in your brain. Who is to blame, the As, Cs, Gs or Ts?

You'd have thought your parents would have caught this sooner. It's not like it's that long of a list to exhaustively test.

Sorry, I couldn't resist :)

Re:

[a.d.trick]

It's not the individual 1's and 0's. It's when they get together that you start to see problems. You wouldn't believe the horrible things that can happen when you get a horde of 1's and 0's together.

Re:

[eggoeater]

Binary! BAH!!

I've always said if you want a secure kernal, you code it in analog format.

Re:

[Ruie]

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.

Actually it is a binary flood attack: when one issues a command su followed by a stream of ones and zeroes (different for each system, but usually about 64 bit long) one can get root access.

Re:

[jZnat]

I don't know about you, but I tend to use passwords larger than 8 characters for root... ;p

Re:

[cryptoluddite]

Remember this is linux, so it's either the GNU/ones or the GNU/zeroes that are at fault.

I think I even saw a...

[Mateorabi]

I blame the twos.

Nice catch!

[shrapnull]

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.

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 own

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.

How come...

[linguizic]

How come every story that I find interesting gets tagged fud, notfud?

Re:

[level_headed_midwest]

How come every story that I find interesting gets tagged fud, notfud?

It's political season. Whatever one person says another has to say the opposite just because.

Re:

[BertieBaggio]

Because people don't know the correct tags. It should be:

> fud, !fud

Quoth the FAQ [slashdot.org]:

For the opposite of a tag, prefix it with "!", e.g. "!funny" means unfunny.

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?

Have modpoints, can't find an intelligent comment

[mr_tenor]

Why bother just tinkering with kernel modules when you can just replace the whole kit-n-kaboodle?

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

Do I care? Not really

[Ice Wewe]

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

Why "exploit" if you're already in?

[KidSock]

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.

All kernels?

[ComputerSlicer23]

What you mean those of use still running the last of the 1.2 series aren't running Linux... I knew there was a reason not to trust that new fangled stuff they've been adding to my perfectly fine kernel... *grin*.

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

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!

Re:

[Dogun]

Really? '*'? You're quite sure about that?

Windows NT and privilege separation

[Myria]

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

Re:

[oglueck]

How is this a security model? All a "privilege" does is open a special hole in an otherwise secure model. Almost any of these holes can be used to execute arbitrary code as the superuser. So instead of giving a token any of these privileges you could simply run the token as the superuser - it's not less secure.

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 ca

Re:Windows NT and privilege separation

[Tony Hoyle]

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).

The NT system is ass backwards because it lets you *add* privileges. The Linux capabilities system does it right - process 1 starts with all privileges, then it removes them. It is *impossible* to add a new privilege - you have to ask a more privileged process to do your work for you.

Re:

[argoff]

It is called SELinux [nsa.gov] and has been built into Linux for a long time. But unless you need it for a specific situation, privilege separation is a pain in the ass which is why many people turn it off. I would be glad to sacrifice some usability if it made windows more secure, but ironically a Linux box with privilege separation turned off is still more secure.

Re:

[EmbeddedJanitor]

You can turn off module support and build static kernel. The list is for for managing the exe handlers. Removing the module support would just prevent the list from being hijacked, not remove the list itself.

Re:

[Tyger]

Technically, if someone could get the kernel symbol table, they could still locate the list and hijack it, creating their own module loader.

Re:

[EmbeddedJanitor]

That would require being able to reboot etc.... May as well just be lazy and build a new kernel from scratch.

Re:

[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:

[EmbeddedJanitor]

Right, but that assumes you leave /dev/kmem open which would be a dumb thing to do.

Re:

[Tyger]

If by "open" you mean world accessible, hardly. The whole point is about root being able to do this, not normal users.

If kmem isn't even available, there are other ways to get to kernel memory, they just aren't as easy.

Re:

[bcat24]

Well, whatever you think about mono (why do some people hate anything even remotely connected with MS?), I think most users and distros will have miscellaneous binary support enabled. How were they supposed to know that such a simple feature was insecure?