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.
This argument has been tried over and over again. It is prohibitively difficult to make an attack like this work.
/etc/shadow is not readable by ordinary users.
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 --
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?
Don't thank God, thank a doctor!
.... 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;
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!