Slashdot Mirror
Local Root Exploit in Linux 2.4 and 2.6
Anonymous Coattails writes "Summary from the advisory: 'Locally exploitable flaws have been found in the Linux binary format loaders' uselib() functions that allow local users to gain root privileges.'"
← Back to Stories (view on slashdot.org)
I compiled included code at the end of the advisiory, this was the output on RHEL 2.4.21-20
./test
%
[+] SLAB cleanup
child 1 VMAs 65525
child 2 VMAs 65392
[+] moved stack bfff8000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xdf400000 - 0xfe5f2000
Wait... -
[-] FAILED: try again (Cannot allocate memory)
Killed
Well, it's only a local exploit for one thing, so good like getting rampant Blaster style viruses based on it..
Second, it'll probably be patched rather quickly.
Third, it's one of a few holes, compared to the one of many holes found in windows...
The linux kernel does very little interpretation of remotely-provided data. There are occasionally remote exploits (e.g. the Ping of Death in '97 or so), but that code has now been pretty thoroughly checked at this point. Most of the code which cares at all about the validity of data is interfaces only accessible locally.
Because 'Linux' exploits are kernel exploits, because Linux is a kernel, as people are so fond of pointing out, which actually has very little to do with remote entities other than the well looked at TCP/IP stack. Windows on the other hand is an Operating System, which includes things other than the kernel, including system daemons/services, user interface code, web browsers, and a whole host of other things.
Long story short, while it may be shoddy, MS Windows is a LOT bigger than Linux, and thus theres more to exploit. If you look at something like Redhat, which is a distribution, you have more of a comparison, and you will find remote exploits.
Summary for the lazy ones: These are four of the probably uncounted bugs which are known for months (if not years), reported to the maintainers but are still unfixed. Yes, we're speaking about the Linux kernel.
In this context, that's what "local" means: That you have a local account, even if you are accessing it with telnet or ssh.
A "remote" exploit is one that can be used by someone who has a network connection to the machine, but no account on it.
"Did I violate you buy hitting ctrl-c and ctrl-v?"
Not copyright. Because you copied a mere part of the work, and you did so for the purposes of criticism, and you aren't making any money off it. Almost anybody would classify that as "fair use". Copyright has limits. It does not give the author absolute control in all circumstances and forms.
And when some third-party developers write buggy code, they really write buggy code. Remember "Return to the Pool of Radience: Ruins of Myth Drannor". Now that was a buggy game!
Zagreus sits inside your head, Zagreus lives among the dead, Zagreus sees you in your bed and eats you in your sleep.
raw diffs to for those brave souls who want them
Time flies like an arrow, fruit flies like a banana.
What's interesting is the preface that shows up on several lists:
Followed by:
meh, it just means I get to bitchslap anyone who tries this out of the university :)
Viva La Revolucion! Buy a Mac!
Atmel, amongst others, produce encrypted RAM. If you don't have the key, you can't read the memory. That's pretty secure, if you ask me.
Any OS with B1 (or better) security has comprehensive mandatory access controls, so that if you DO find an exploit somewhere, it is still not possible to access other parts of the system. (B-class and A-class OS' do not "need" a system admin account, since you can define specialised pseudo users that can do exactly what is needed for a given task and no more.)
Then, there are systems like OpenBSD which have been audited to hell and back. OpenBSD has had one provably-usable exploit in living memory.
Then, you've various security software that's out there. eg: Using OTPs w/ S/Key or OPIE for passwords, enforcement of strong passwords, IPSec w/ strong host authentication on all network connections, etc.
In theory, there is nothing to prevent someone from combining all of these elements to produce a hardened OS that is impervious to both physical and logical attacks, both locally and remotely.
In practice, nobody would spend the time and/or money on that level of security for normal use. Ok, the NSA might, but that's not strictly "normal use". It's also unlikely they'd make such an OS readily available. (They've done wonders with SE-Linux, and the declassifying of Skipjack and SHA has made a world of difference in cryptography, but that's not quite the same as Open Sourcing a bullet-proof system.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
No this was just a dumb locking bug. You could reasonably argue that some of the kernel API's for do_brk were less than well designed but thats more historical accident.
Its fixed by 2.6.10-ac6 along with the setsid crash and some other corner case bugs Coverity found.
* When you copy newlen into len, this could cause len to be negative if newlen truly is an unsigned int.
* It all depends what copy_from_user does. Does it check to make sure that len is sane? Is it an unsigned int, or a signed int. If it's signed, then a negative value is obviously not sane and should be rejected.
Where did this code come from? What file please?
Don't count your messages before they ACK.
Shatter attack
It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
A creates a window on the interactive desktop (a big no-no) with a textbox in it.
B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.
First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job.
MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.
I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version.
And given his description of how he found these problems, plus his frustration about getting Linus and akpm to reply, his tone is even somewhat understandable.
getuid() and geteuid() get the "user ID" and "effective User ID". This scripts makes a library that makes these functions return 0 -- signifying that you are the superuser. It doesn't actually make you the superuser, but it implements functions that pretend you are.
Anyway, then it compiles these functions into a library and tells the loader to link that library first. So when you start up a shell, it will call getuid() to figure out your userid, and your new library will tell it that you are userid 0. The shell prints out the root prompt instead of the regular one.
But this in no way actually gives you root privs, if you go to edit /etc/passwd you will not be able to.
Pretty funny joke, though, kind of like telling everyone that they can ftp to 127.0.0.1 using their own regular userid and password and find all the porn they could ever want...
-- Erich
Slashdot reader since 1997
While I can't justify the difference, I'll tell you that there is one if we don't see any regularly recurring network born auto-root that's so bad it threatens the top level domain servers. It's not like someone cracked kernel.org and owned it for three months injecting whatever they pleased into the codebase. One good explanation of the difference is that Marketing dorks who do little more than buy other's code can't maintain it properly.
Friends don't help friends install M$ junk.
> Is there ever a time when you can consider your systems secure against
> an attacker with physical access?
In the phrase "local root exploit", the word "local" doesn't mean local in
the sense of physically present, but in the sense of needing to already have
user-level access. If you combine it with a non-root remote exploit, the
two together add up to the equivalent of a remote root exploit.
In other words, this is definitely something we want to fix.
As far as securing a system against physical access, that's a whole nother
kind of hard. At bare minimum you need an encrypted filesystem with a key
that isn't stored and so has to be entered by an authorized user every time
the filesystem is mounted, and then on top of that if you make sure that the
machine, if left unattended, suspends running processes to disk and then
unmounts the filesystem, and if you're both paranoid, obsessive, and tireless
when it comes to bughunting, you potentially could develop a system that has
a reasonable degree of security against an attacker with physical access --
but "a reasonable degree" does not mean "impenetrable" -- there are still
hidden cameras, keyboard logging devices, and the like, to say nothing of
rubber hose cryptanalysis.
Cut that out, or I will ship you to Norilsk in a box.
yes, local normally means user-space software running on the system can exploit it. That means any program you type in, compile, and run from a physically attached keyboard, or through ssh, or even any code that a local daemon or client program is tricked into using. That means possibly one of those old libpng buffer overflows can be used to insert code into mozilla and eventually get root - you have patched those seemingly unimportant security announcements haven't you?
To be limited to a physical access exploit, it would need to be a bug in the keyboard driver, the input layer, or possibly a user-space program that uses raw keyboard entry. I don't think screwdriver level access counts, since you can lock your machine up. Filesystem bugs could be exploitable via usb drives, floppy disks, cf drives, etc... Those are physical exploits rather than local.
I got it to compile and run on Debian Sarge with gcc version 3.3.5, kernel 2.4.25-1-386, and it says it succeeded, but I'm still my normal UID, just drops me into a bourne shell:
Second, it'll probably be patched rather quickly.
There is a preliminary patch in testing for the 2.4 series.
Look here.
The file is patch-2.4.29-rc1.bz2
Note that it's in TESTING, because it probably needs testing yet. But if you're desperate to patch it up quickly at your own risk, then there you go.