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.
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.
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.
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
Apparently (according to another poster) it is. So who enables misc binaries in a kernel build and why would they do this? The only people I can think off are mono users but they're fools anyway.
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.
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'.
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)
Snowden and Manning are heroes.
Most CS types would say that SLL is Singly Linked List. The construct allows for references to next, but not to previous.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
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.
Really? '*'? You're quite sure about that?
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.
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.
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.
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
Hint: that is not an a.out file.