Weakness In Linux Kernel's Binary Format 281
Goodfellas writes, "This document aims to demonstrate a design weakness found in the handling of simply linked lists used to register binary formats handled by the Linux kernel. It affects all the kernel families (2.0/2.2/2.4/2.6), allowing the insertion of infection modules in kernel space that can be used by malicious users to create infection tools, for example rootkits. Proof of concept, details, and proposed solution (in PDF form): English, Spanish.
And? (Score:5, Informative)
This is so not serious (Score:5, Informative)
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:And? (Score:2, Informative)
Probably none. (Score:5, Informative)
Most Windows/IE attacks don't require you to even have local access, let alone root.
Mirror (Score:5, Informative)
Re:Criptic summary (Score:1, Informative)
Re:What about other ELF systems? (Score:5, Informative)
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:Probably none. (Score:2, Informative)
Re:What about other ELF systems? (Score:5, Informative)
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.
Re:Problem: Sometimes you want to limit root. (Score:3, Informative)
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'.
Re:Too bad you have to be root. (Score:5, Informative)
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:simply (Score:5, Informative)
Re:Probably none. (Score:3, Informative)
Re:Probably none. (Score:3, Informative)
On most modern systems, it is also impossible, because the actual password hashes have been moved to
If you are root, you can still attempt to brute-force them -- which would be time-consuming and almost never has a point. If you're hoping they use the same password elsewhere, you can simply install a keylogger -- which is assuming you weren't smart enough to do that when they first set their password. If you simply need access to their account, you can su in. If you need to reset their password, you can do that as root without knowing the original password.
Which means that this whole system is about as exploitable as an "exploit" which gives you root access, but which only works if you're already root.
Have modpoints, can't find an intelligent comment (Score:3, Informative)
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.
Re:Nothing to see here, move along! (Score:3, Informative)
Re:Probably none. (Score:5, Informative)
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. (Score:3, Informative)
This is completely bogus! (Score:2, Informative)
There's no bug here.
Re:This is so not serious (Score:3, Informative)
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)
* Modify the system config to automatically load an additional shared library to perform the task you want
* Modify the user's config to automatically load an additional shared library to perform the task you want
* Add a module to the kernel that intercepts the system calls the program wants and performs the task you want
* Add a module to the kernel that allows an additional process to snoop on the program's memory and perform the task you want
etc.
There are plenty of ways of using the operating system's features to do just about anything you want to, even to other programs. This is intentional. It allows flexibility. There is a reason why new binfmt handlers are added to the front of the list, rather than the back, and that is to allow a new handler to override specific cases that would usually be handled by an old one. You add generic handlers first (typically just the ELF loader these days) and then specific ones afterwards (perhaps a handler for broken ELF files produced by a strange compiler). You don't want to have to load the specific ones first, because specific stuff is less likely to be actually needed, so you really want it to be a module.
Re:Windows NT and privilege separation (Score:4, Informative)
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:Too bad you have to be root. (Score:4, Informative)
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:How come... (Score:3, Informative)
Because people don't know the correct tags. It should be:
> fud, !fud
Quoth the FAQ [slashdot.org]:
Re:Criptic summary (Score:1, Informative)