Slashdot Mirror
Linux Kernel 2.6 Local Root Exploit
aquatix writes "This local root exploit (Debian, Ubuntu) seems to work everywhere I try it, as long as it's a Linux kernel version 2.6.17 to 2.6.24.1. If you don't trust your users (which you shouldn't), better compile a new kernel without vmsplice." Here is millw0rm's proof-of-concept code.
I don't think I'm the first of us to say "Ah shit".
On the other hand though this is the beauty of open source. The problem is now known so I'm sure a fix is already on the way.
I never get used to these constant resurrections
And the next sound you shall hear are millions of nerds rushing into their offices to compile a new kernel on a sunday afternoon... along with the millions of cell phones ringing as the bosses read this...
Karma Whoring for Fun and Profit.
I strongly suspect this code doesn't do what it says on the tin.
Phew, lucky I run MS Windows then !!
This is not an universal problem. It only occurs for those kernels with a specific function compiled in that most installations won't need, and which halfway decent sysadmins won't have as part of the kernel anyhow when they don't need it.
Yet another good example of why you shouldn't hire the sysadmins who blindly use what the vendors ship, but security and performance minded sysadmins who reduce installations to what's actually needed.
"But see, Linux sucks! It has holes just like Windows does!"
The difference is that we know about this hole, and can now fix it - I'm just going to bed, and it will no doubt be fixed by the time I wake up. How many Windows security issues are known that haven't been fixed?
"Oh man, this is why Linux is great! We can find holes, and fix them, like, immediately!"
Yes, that's a strength of Linux. What I want to know is, what steps will be taken to ensure that bugs of this type - whatever they might be - don't crop up again? One advantage that a large paid organization can have is strict testing requirements - I'm honestly not sure if I believe the Linux kernel is held to the strong standards that a commercial kernel theoretically could be.
The existence of this bug is a failure on Linux's part. There's no way to get around that. Many mistakes were made, from the original code or design decision that caused this bug all the way up to it not being found until now. The bug will be fixed rapidly - but the process that let this bug be released needs to be looked at, casually at the very least, to figure out if there's a way to stop this class of error from ever happening again. (Whatever class of error it ends up being - I don't pretend to know.)
Breaking Into the Industry - A development log about starting a game studio.
Or even a few hours. The few significant holes in OSS operating systems and programs are always patched so quickly. However, Microsoft takes months, even years to patch the thousands of holes in Windows...
:) Is my kernel version effected?
*checks kernel version* 2.6.23.8-34... wow I'm out of date
I compiled the code without problem. But when I rebooted, the splash screen said 'Vista Home Premium'.
Just tested on Suse x86_64 10.3, ran as local user and it dropped me into root.
Linux opteron 2.6.22.16-0.2-default #1 SMP 2008/02/01 19:36:55 UTC x86_64 x86_64 x86_64 GNU/Linux
I can log into the Server that all the students use at my school. People write code there, they have projects, and personal files saved. I now potentially have access to everything. Local does not mean safe if you have many regular users logging in all the time.
-EL
Nope, all you need is remote access to a local user account via ssh or something. Many users use weak passwords. Now you won't have to guess the root password.
Yes, I just verified the exploit on Linux 2.6.17.13 (Slackware 11.0) and Linux 2.6.21.5 (Slackware 12.0) and it works as advertised.
Well if you have a shared hosting account that allows ssh logins, anyone can now become root and start messing around.
uh, I opened an ssh window instead.
Just an account will do, it works over ssh etc.
Not actually, think of those gazillions of PHP scripts vulnerable to file inclusions or any other issues that let you run code or execute any commands from remote.
Can't get a rootshell on a Vserver + a Grsec/PAX kernel ("Illegal instruction"), however the non virtualized "root system" itself can be rooted from anyone.
My desktop system here (2.6.23.14) naturally has no chance.
Every other day bugs get detected in web applications, allowing an intruder to run arbitrary code under the webserver UID. This exploit means each of these bugs gives way to root privileges.
The proof-of-concept code only supports x86 and x86_64. Does that mean other architectures are immune?
Inaccurate. It does require shell access, but it does not require it to be physically local.
A 'local root exploit' only means that you have to have a shell of some kind first. This can include an SSH shell account. This can also include any kind of non-root shell exploit.
Say that you can exploit some webapp to get a shell as wwwrun/apache/www. That combined with a local root exploit to get root. It doesn't even need to be a DIRECT shell exploit. Perhaps your hack/program opens up a port with telnet listening.
Thus all 'local root exploits' are potential remote exploits, if we allow for chaining. Chaining can be used by anyone who isn't just a script kiddie. Hell, you could probably make an auto-rooter that will chain the exploits.
The exploit works, but the suggested file name does not, at least for me. Any guy here succeeding?
/* ;)
* jessica_biel_naked_in_my_bed.c
*
* Dovalim z knajpy a cumim ze Wojta zas nema co robit, kura.
* Gizdi, tutaj mate cosyk na hrani, kym aj totok vykeca.
* Stejnak je to stare jak cyp a aj jakesyk rozbite.
*
* Linux vmsplice Local Root Exploit
* By qaaz
*
* Linux 2.6.17 - 2.6.24.1
*
* This is quite old code and I had to rewrite it to even compile.
* It should work well, but I don't remeber original intent of all
* the code, so I'm not 100% sure about it. You've been warned
*
* -static -Wno-format
*/
... I compiled it and ran it.
And I'm not vulnerable. Assuming vmsplice is for the new KVM code, I use vmware and qemu for virtulization. (I have no need for xen or kvm until I get a svm/vmx flag in my cpu).
So my vanilla-hand-compiled-with-only-certain-static-options 2.6.24 kernel on a highly customized slack 10.2 is safe.
FLR
There are some pretty funny comments in the source code, regrettably, most people won't understand them. Hell, as a Czech, I *am* probably supposed to understand them, if it were not for the obscure north-eastern dialect of Czech that all the rest of our country finds hilarious (and incomprehensible at the same time).
..." [last for four words utterly incomprehensible :)]
:)) makes me think that had drunk quite a bit before he wrote these gems. Pity that I don't have a good dictionary of spicy English. I'm just rolling on the floor and seriously laughing. :) Oh, and the exploit works, which is not that *funny*.
"Dovalim z knajpy a cumim ze Wojta zas nema co robit, kura." == something like "Just returned from the pub and saw that Wojta [a machine? Or a person? Unclear...] has nothing to do." [The last word might be a Czech expletive with a typo...?]
"Gizdi, tutaj mate cosyk na hrani, kym aj totok vykeca." == something like "Here's something for you to play with, boys,
"Stejnak je to stare jak cyp a aj jakesyk rozbite." == "Anyway, it's old as hell and somehow broken anyway"
The style (no way am I able to render *this* in English
Ezekiel 23:20
Do you know Oyashiro-sama?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953
The workaround posted in a follow-up in that thread works. I had a few vulnerable (tested) machines that I cannot reboot even if a patched kernel is released in the near future. I tried that fix, then tried the exploit again. The exploit no longer worked after using the fix (workaround).
Those machines were debian x64.
Ubuntu kernels do not appear to have vmsplice enabled by default.
There are hundreds of thousands, perhaps millions, of people with a local account and shell on a $5/month linux webhosting plan. Many of those people don't know what they're doing (the users and the admins), use guesable passwords, etc. Add in the phpbb, etc. exploits and every script kiddy in the world has shell access to a linux machine.
Do you even lift?
These aren't the 'roids you're looking for.
Managed to get it to run on my machine (Debian). Gave me root access just as promised. Funny though that I still can't run administrative functions (like ifconfig) without running them with an absolute path (little comfort though).
using the 2.6.22.15-laptop-1.uc1mdv Mandriva-supplied kernel.
creation science book
Upstream patch for the vulnerability tickled by that specific exploit is here
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44
Red Hat tracking bug (Enterprise Linux 5 is affected, but 4,3, and 2.1 are not)
https://bugzilla.redhat.com/show_bug.cgi?id=432251
Fedora tracking bug
https://bugzilla.redhat.com/show_bug.cgi?id=432229
FYI, there's a live patch available as a link[1] in the Debian bug tracker which modifies the exploit to patch the vmsplice() call with a RET as the first instruction. Run it at boot and you'll be fine, unless an attacker can jump to the next instruction instead...
[1] http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c
Doesn't require shell access, it only requires the ability to run arbitrary code. If you're able to upload a program or CGI script that will run on the box, then you can upload this exploit code in its place.
There's nothing special about "/bin/bash" exploitation can just as easily be another program you upload that is run instead of a shell.
is vmsplice part of virtualization found in Device Drivers > Virtualization (and the submenu within the said location)?
if so then mine is ok as i dont build that in my kernel, if this is something else where can it be found in menuconfig?
Politics is Treachery, Religion is Brainwashing
So could it be run on computers with public shell access (connected via SSH)?
Yeah, so you have a fantastic sysadmin who compiles everything and tweeks it just so... and then (s)he goes away... and you are left with an unmaintainable mess that has to be completely figured out by the next person. Sounds like something I want... NOT.
Scott Dowdle
www.MontanaLinux.Org
Linus's VM games strike again. Crap. Can we please have some stable kernels again? Any hope?
In the mean time I only use FreeBSD for my servers.
[hity@localhost ~]$ kwrite expl.c ./expl .. 0x1000 .. 0x5000 .. 0x2000 .. 0xb7fca000 :(
[hity@localhost ~]$ gcc -o expl -O expl.c
[hity@localhost ~]$
[+] mmap: 0x0
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000
[+] page: 0x1000
[+] mmap: 0xb7f98000
[+] root
[root@localhost ~]# damn what a nasty hole
Mm. Nonsense-generalising makes the world go round. Be sure to check for virusses installed while you wrote your message.
Y'know - Windows is bad not only because it has "defects" but primarily, IMO, because it's so weak, it's basically defective by design with no hopes of fixing. For example - when it's gonna have a real filesystem with name/file (or inode if you like) separation? So I can do updates of things without reboots? So I can rename/replace/delete the file even if it's (gasp) opened or if some other process has CWD in the directory I want moved/deleted?
Or ulimits? Will Windows ever have those? How do you even run any real server without ulimits?
Etc...
Maybe Dr. Zelenka knows what this says...
NTFS has had that for a while now.
Suggest you check out Windows System Resource Manager
The real problem here seems to be not Windows, but your ignorance about Windows.
Do you care about the security of your wireless mouse?
My server which has a vanilla 2.6.23.15 is vulnerable. But I don't worry because everyone else's home except mine is on a noexec volume. tmp and var are too. Another win for noexec :)
:(
But I subscribe to a webhost service that is vulnerable. Hackers are probably reading my e-mail as we speak.
Well, I can tell you that SELinux (enforcing, targeted) on Fedora 8 was no help in preventing this exploit. Does "strict" make a difference?
the growth in cynicism and rebellion has not been without cause
How many Ubuntu-ites recompile stripped kernels? Ubuntu is supposed to be this touchy-feely Linux where you don't have to have a pet kernel hacker, just install the CDs. If you're arguing that Ubuntu-ites should rebuild kernels then you're missing the point of Ubuntu.
The healthy thing to do here is what most people are doing: accept that there has been a screw-up, fix it and learn from the experience.
Engineering is the art of compromise.
You mean like how Linux zealots are constantly bashing Windows for "being bad"?
So which `make menuconfig' option needs to be disabled to effectively eliminate this vulnerability? In `Device Drivers->Virtualization', I have nothinng selected in my running kernel's config, yet it's still vulnerable when I run the exploit. From what I gathered by googling, you want to disable the CONFIG_MMU kernel option, but instead of doing it via editing the .config file, I'd rather do it in `make menuconfig' so that takes care of anything that may be depending on that option as well.
Some of these bugs have extremely esoteric escape sequences that leave me wondering how they determine those to exploit faults in various programs (especially in something like the Linux kernel).
because of needing the user password I wonder how different it is from attacking people who run ssh and sudo (as home users, it might be more effective against servers though). Last time I looked you could get root access on an Ubuntu box doing:
sudo su -
That's pretty serious too and I don't know if it has been closed, but assuming it hasn't then this problem just seems like a fancier way of doing the same thing... If anyone could test this out now I'd really be interested to see if it still gives root access without asking for a password (or if it does if the user password is enough).
Although just thinking about it maybe removing the user from the sudo list might fix this, but that wouldn't work for ubuntu home boxes becaused they need access to sudo anyway
*''I can't believe it's not a hyperlink.''
Just tried it on a box with 2.6.18 with XEN and VServer patches; It did not succeed, however it did broadcast a general protection fault over all consoles - the addresses probably differ from the default due to the included patches.
Life is just nature's way of keeping meat fresh.
Pardon me for the rookie question - but can anyone tell us which kernel config option enables this so-called vmsplice? I'm no even clear on what its for... if its something I don't need can I disable it through menuconfig or is it something that I'll need a patch to disable?
The given exploit prints pointers using "%lx". That's wrong, and on x86-64 it will break (pointers are 8 bytes, longs are 4 bytes).
Every instance of "0x%lx" needs to be replaced by "%p".
The moral of this story is: Always use gcc -Wall and fraggin' pay attention to the warnings.
Ooh, moderator points! Five more idjits go to Minus One Hell!
Delendae sunt RIAA, MPAA et Windoze
I'm hoping for your sake this was a troll, because the alternative is you're retarded.
Slashdot - where whining about luck is the new way to make the world you want.
yea its a "local root exploit" as opposed to a "remote root exploit" which means it has to be run locally either by a user or somehow fed to a process capable of being tricked into running arbitrary code locally. as i understand it this is less of a concern for desktop installs because most hardware accelerated 3d graphics drivers for X are shot full of these types of exploits anyway due to the nature of the way they use the hardware, however the linux kernel itself is typically more secure than that.
Person who wants to exploit this hole, needs to get into to the system first and then that person can use the hole to get root access.
So in general there is no danger to home users. Only servers that allow untrusted people to login are in danger. So most people have nothing to worry about. And those who need to worry, are most likely professionals or atleast they should be. And they can handle this, if they already hadn't.
Try certificate authentication - a bit harder to crack.
Stop trolling and flamebaiting.
You can't carefully compare Linux with proprietary products because they won't let you see the source, especially if you tell them you're going to carefully scrutinize it.
A fool and his lamb are worth two in the bush.
No it doesn't.
You know, there is a difference between trolling and pointing out the flaws in your reasoning. Just saying.
It seems to me that slashdot's system for filtering submissions is doing a very poor job these days with stories about security bugs.
Within the last day or two, we've had the following:
This is really getting to be a Boy Who Cried Wolf thing.
Find free books.
That's why I use an open-source OS. I can fix it when it breaks.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
What's the difference between that and sudo -i? I tried it but couldn't verify much because my user password is the same as my root password. From what I saw it's the intended usage and not a bug as far as I could tell. su is deprecated in Ubuntu though.
A fool and his lamb are worth two in the bush.
Well, until someone exploits the weak permissions on your webserver to execute a binary, get root, and pwn your system completely.
Local root exploits are serious if you run any kind of server - and lots of home users run things like apache these days.
The poster who said that Ubuntu kernels are not affected was incorrect, at least partially. The exploit code works as advertised on my Ubuntu machines, both of which are running 7.10 with the latest generic kernel image.
I have tested the exploit on a Linux VPS box within a VPS as a standard user, and it didn't work. Not sure if this is luck, kernel config, or good VPS design (Hello Bertl!), but either way I am happy.
/me will start using GRSec again. It might not stop/have stopped this (I have no idea), but it's just an extra layer of difficulty.
Get your own free personal location tracker
Use the fix-sploit that's been posted here when you log on next.
Your documents are then safe.
Yes.
If you can execute code on it you can run the exploit. That's why it's so serious and why any admin worth their pay is either fixing it right now or will have it fixed by 9.05am Monday Morning.
And who cares if we bash Windows, anyway? Are you honestly defending it? I presume that you simply find it annoying. Well... I find anti-windows-bashers extremely annoying. Almost as annoying as trolls...
A fool and his lamb are worth two in the bush.
Long is indeed 8 bytes. Int is still 4. Thanx.
Ooh, moderator points! Five more idjits go to Minus One Hell!
Delendae sunt RIAA, MPAA et Windoze
Shit.. This is some creepy stuff... Tried it on my VMWare machine.. worked just fine.. wich isn't that fine... murmel@server:~$ uname -r 2.6.24-custom murmel@server:~$ ./exp
--
Linux vmsplice Local Root Exploit
By qaaz
--
[+] addr: 0xc011834b
[+] root
root@server:~#
I hope this will get corrected soon...
LOL I think the legal term for that is "entrapment". You really just baited him to say exactly what you needed to make him look dumb...
A fool and his lamb are worth two in the bush.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44
Expect a 2.6.24.2 real soon....
I just tried this with Opensuse 10.3 with kernel patch=kernel-default-2.6.22.16-0.2
the exploit worked.
So it definitely works on Ubuntu.
I just came home from the student computer society where Morten Hustveit wrote the quick workaround.
Linux 2.6.24.1
commit cece280a46c9b5c0adb4d5251f42c082a578e1ad
Author: Jens Axboe
Date: Fri Feb 8 08:49:14 2008 -0800
splice: missing user pointer access verification (CVE-2008-0009/10)
patch 8811930dc74a503415b35c4a79d14fb0b408a361 in mainline.
vmsplice_to_user() must always check the user pointer and length
with access_ok() before copying. Likewise, for the slow path of
copy_from_user_mmap_sem() we need to check that we may read from
the user region.
Signed-off-by: Jens Axboe
Cc: Wojciech Purczynski
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Linus Torvalds
It looks like the fix for this exploit have been released 3 days ago.
Nothing to see here, move along.
1. As long as I have tested, both exploits #5093 and #5092 DOES NOT affect Feisty
2. They both DO affect Hardy
3. They DO NOT affect Dapper
So it is not fully 2.6 exploit, but there is issues with concrete versions of kernel.
user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
I, for one, trust myself and am the sole user of my heavily-password-protected computer. Looks like I'm fine, and it sounds like the easiest solution in a private setting to me.
Vmsplice is part of the core kernel, it is not a configuration option. It is used all over the place.
Interested in open source engine management for your Subaru?
Do you care about the security of your wireless mouse?
Linux hack 2.6.14.3-sjg_20051202 #1 Fri Dec 2 20:24:15 PST 2005 i686 GNU/Linux
"[-] vmsplice: Function not implemented"
Linux localhost.localdomain 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 21:18:02 EST 2007 i686 i686 i386 GNU/Linux
"[+] root"
Linux mythtv 2.6.20-16-generic #2 SMP Sun Sep 23 19:50:39 UTC 2007 i686 GNU/Linux
"Segmentation fault (core dumped)"
Linux hosmer 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
"[+] root"
script kiddie found a hole... oh no the authors just committed seppuku
destiny, chance, fate, fortune; they're all ways of claiming your fortunes, without claiming your failures. -gerrard
Most likely this will not be needed by most here, but those who do not know how to re-compile (the kernel), here a solution:
1) See that gcc is installed
2) Download http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c
3) run `gcc disable-vmsplice-if-exploitable.c -o disable-vmsplice-if-exploitable`
4) run `./disable-vmsplice-if-exploitable`
Don't fight for your country, if your country does not fight for you.
Now I'll go back to waiting for KDE to compile.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Only servers that allow untrusted people to login are in danger. So most people have nothing to worry about. Trust is exploitable, too. Don't give away too much of it.
Actually, by default, the exploit patch only works if run as NOT root. To fix this, comment out the lines:
// if (!uid || !gid)
// die("!@#$", 0);
Then it will run as root as well, and can be easily placed in your startup scripts. (Make sure you at least place it before the launch of sshd.)
Five days is a target for something like a kernel exploit (in terms of the fix appearing in mirrors for various distros, and update tools telling you to reboot).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
...to clean teeth.
Netboot, biiiatch! Set up a TFTP, toss in a syslinux config, and point it at a loopback mounted ISO of whatever distro you're installing. I know at least Debian and Fedora/Redhat are capable of this. Solaris too (although its been awhile I remember doing it ages ago).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Just ran this on a OpenVZ host, running a vps, and the whole host crashed. Sorry there's no specfics but its down. Love virtualization.
Take the kernel-source. Modify the kernel config file and remove what you know isn't necessary. Create a diff between the new and old and place it in the SOURCES from the rpmbuild environment. Add the patch to the spec file for the kernel in the patches section; also change the release name to match your company to distinguish it from a stock kernel release. rpmbuild the kernel using your new patched config and new spec file and it'll do the rest of the work automagically.
Now you have a fresh, customized kernel RPM you can use on all of the hardware of the same class. Distribute via internal package mirror (you need one of these too, its a godsend).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I'm running a server install of Ubuntu 7.04.
body massage!
I better switch back to windows.
It doesnt works on Archlinux default kernel.
.. 0x2abb11e43000
# testhack
[...]
[+] mmap: 0x2abb11e11000
Illegal instruction
There is a really really big webhost with shell access in the US with which I just tested the exploit and it worked. Thousands of GB of user data are now at risk....
That's because during installation, the initial user account is made a member of the admin group. Presumably, you wouldn't give everyone on the machine that kind of access (and yes, you have to do so explicitly).
/etc/sudoers:
Check out
%admin ALL=(ALL) ALL
It means that folks in the admin group can do anything using sudo.
I always mod up spelling trolls.
(I'm posting this because I accidentally moderated a comment and I can't find a way to revert it.)
You'll not be running anything under Xen or VMWare without extra modules (RHEL 5.1 ships with a Xen upstream kernel now). As for Samba, I hope you don't want ACL support; you'll need a kernel compile for that - Extended Attributes aren't enabled by default. If you need the newest e1000 driver on your integrated NICs, you can add it in yourself or wait for your provider to support it.
I'm just saying there are legit reasons for hand compiling a kernel. Sorry, I've had this discussion before and it's a bit of a sore point for me. Binary kernels are all well and good for a good majority of cases, but some times you need specific kernel operations or abilities that are not going to be supplied and supported by your upstream provider. Then again, I'm used to being my own upstream provider from running Slackware... maybe I'm just not looking at it from the right perspective.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
selinux shipped in a fashion where it only protects services. As such most policies are set to allow a service access to its usual files/sockets and needed syscalls .
/tmp directory or call exec on the binary). Assuming you could get it to run under such an selinux protected service you might then struggle to provide a shell or gain root privileges etc.
A service that was protected with selinux would probably not "stop" this exploit unless it did very little (a cursory glance suggests it is uses mmap and vmsplice to do perform the deed which could well be things a webserver needs to do). However what might happen is mitigation - a service protected by selinux might struggle in running the exploit in the first place (e.g. by blocking the ability to make an HTTP connection to a server or write to the
However selinux will NOT (at least at present) protect you from yourself. Unless you have a very tough policy it won't stop you compiling code and using a shell as a user logged in over ssh. It also doesn't protect common programs like Firefox - currently it only targets services that are ideally running as their own user.
+--------------+
.\|.||/..
| PLEASE |
| DO NOT |
| FEED THE |
| TROLLS |
+--------------+
| |
I'm sure my Ubuntu systems will automatically get a patch soon so I don't have to bother recompiling a kernel anyway.
A remote "nobody" Apache exploit that web admins fail to patch because, hey, it only gets you "nobody" access right?
How we know is more important than what we know.
So far it's come up with "function not implemented" on all my Ubuntu Dapper LTS servers, which means most of my machines, but it did come up "Exploit gone!" on my 7.10 X64 and a couple of Debian 4.0 boxes.
Note that if you compile disable-vmsplice-if-exploitable.c on an X86 box you'll need to compile it again for any X86-64 boxes you have.
"Ain't no right way to do a wrong thing."
What tires me about these REVELATIONS and DISCUSSIONS is the lack of any real
...
risk assesment.
Note: The bug is already fixed: see,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff; \
h=712a30e63c8066ed84385b12edbfb804f49cbc44
as "Bastian Blank [Sun, 10 Feb 2008 14:47:57 +0000 (16:47 +0200)]", a 1 line fix
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1234,7 +1234,7 @@ static int get_iovec_page_array(const struct iovec __user *iov,
if (unlikely(!len))
break;
error = -EFAULT;
- if (unlikely(!base))
+ if (!access_ok(VERIFY_READ, base, len))
break;
which any of you can retrofit to your old(er) kernels ie edit, make, install.
Now the exploit is complicated, that does not excuse the BUG, Linus and Andrew
have been working up a storm for months about the balance between innovation
and quality but as the commercial distributions have been pushing features and
back on maturity testing this was bound to happen.
The truth here is that without the machine readable exploit code it would be
hard to exploit, and anyone can apply such a simple fix without waiting for
Greg K-H and the stable team.
FINALLY, I am very suspicious about the release timing of this and the OBSD PRNG
stories which I suspect a FUD, pure and simple, which is not to say you shouldn't
fix your systems and press your commercial distributions to _prefer_ quality.
this release fixes the vulnerability.
Are the FreeBSD/Mach developers still incompetent now? http://kerneltrap.org/node/6506
I logged into some friends' machines (where I don't have root access) and used that program to fix it. I love code that uses an exploit to fix said exploit.
See, the exploit is a feature, it allows friends to patch your system... yeah..
XML is like violence. If it doesn't solve the problem, use more.
Both failed to work. I tried it on my Debian system with Kernel 2.6.22-K7 and it worked. I used the hotfix in that Debian link and its hole was secured.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
2.6.23.9-85.fc8 x86_64. Compiled and works as advertised.
I won't argue about how much fun it isn't, but when my NAT'd laptop is VPN'd in to a secure cell and then two or three jumpboxes, options are limited. Yeah, if I have a chance ahead of time and there's another server on the VLAN I can access, I'll just set it up to get the images off the local net and do a kickstart/autoyast install.
But having the fallback beats having to have somebody drag their ass to the datacenter to swap media.
-- Alastair
strace....
...
mmap(0x100000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
write(1, "[-] mmap: Cannot allocate memory"..., 33[-] mmap: Cannot allocate memory
) = 33
Didnt work as advertized
It is Here
This was going to be the year of Linux on the Desktop!! Now what do we do??
-Lod
I just ran the code on my Fedora 8 machine. Root access.
.
Sa souvraya niende misain ye.
This exploit came in handy because I had forgotten my root password. Thanks!
Exactly who has local users on a box that's doing anything important?
I'd rather have hemorrhoids than local users. At least when they're on your ass you know where they are and what they're doing.
Um, you *do* realize that this has nothing to do with any kernel option containing the word "splice", right? You need to patch the fs/splice.c file under your kernel source tree, then compile a new kernel.
From what this looks like (given the "old code" comments, and timing of the release of exploit code), I'd say that someone realised that their pet root exploit was being patched in the current kernel (2.6.24.1), and wanted to have a final go at increasing the impact of the exploit before it was snubbed out. I find it hard to believe that, coincidentally, they just happened to post this exploit on milw0rm the day after the change appeared in the kernel.
Poor form, but I guess it has at least made a few more people aware of the severity of the issue.
Ask me about repetitive DNA
I had been running 2.6.19 for over a year now, waiting for unionfs to make it into mainline so I wouldn't have to manually apply the patch. Turns out that doing so is pretty easy. And then the diff (for the actually exploit patch) on my distro's bug site had the line offsets just a little wrong for my kernel version, so I edited splice.c by hand.
:-(
So now I'm running Linux with a hand-patched kernel and lamenting what a gigantic nerd I've become.
2.6.22-hardened-r3
/proc/kallsyms, which the hardened kernel disables.
Neither exploit works. I know, the second is for 2.6.23-24, but it depends on
I don't have KVM installed on any of them (KVM on a production server? are you serious?) so that might help.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
The shellcode is all that's x86 specific; if you want to h4x0rz a different architecture you'll need to write your own shellcode.
All's true that is mistrusted
vmsplice exploit fix
Have you got your LWN subscription yet?
> doesn't affect a default install of Ubuntu
I don't know whether my Ubuntu 7.10 counts as a default install (what's that, anyways?), but it is vulnerable. I don't compile my kernel myself.
...I have a question for you. I 100% agree this is an advantage of open-source than closed-source software will never have, ever. You've got me on that one, but my immediate thought was "ok, how much would I like to change my own kernel in production systems? About 0% thank-you-very-much".
I mean, hacking stuff in and out of a production system kernel; surely that's a process that would require months of intensive regression testing, etc, etc? I mean, I doubt there are people that know the kernel well enough to do such changes for their own systems, but really, what percentage of you guys honestly and confidently can say "Yeah, let me just fix that for us" knowing your job is on the line if your systems crash around you.
This isn't a troll, this is an honest question.
throw new NoSignatureException();
This has nothing to do with the Linux kernel, distribution is up to the individual distros. They are all their own entities. However, most current distros I've seen have some sort of automatic system or system to easily make updates automatic. The only one I can think of which doesn't do that would be Slackware, and I doubt some newbie or "couldn't be bothered to update" user would even touch that distro...
There is a quick and dirty fix via a module. https://bugzilla.redhat.com/show_bug.cgi?id=432251#c10 The actual patch is listed here: http://home.powertech.no/oystein/ptpatch2008/ -Rob
Nope, all you need is remote access to a local user account via ssh or something. Many users use weak passwords. Now you won't have to guess the root password.
/etc/passwrd - Oh Shit), than for security.
He won't anyway. My login has sudo access without a password anyway. My own login is the secure one, if someone gets access to that, he can get to all my important stuff (documents, code, jpgs) anyway. For a single user machine, root is more for a protection against oneself (rm
Now, the httpd user on the other hand...
right on peeps. unfortunate that the exploit existed for so long, but a patch was available for my gentoo distro within four hours of the article being posted on slashdot.
compare this to the weeks or months for some kind of response from m$ when root access is obtainable, again...
Because I use openSUSE, I get a new kernel every time they give me one, and the sources to match.
.config options disables this "vmslice" routine without the use of a patch, which will be overwritten by the new kernel-source-point.update.RPM.
I would really like to know which of the
Which part of "menuconfig" or "xconfig" should I be dropping?
(not specifically to you, but can't find this answer lower down the tree)
Do not meddle in the affairs of geeks for they are subtle and quick to anger
It's bigger than that really.
If you've got a webserver that happens to be running a remotely exploitable bit of code (e.g. CGI script, PHP/Perl application, etc) then you could simply download, compile and run this exploit as you would anything else. Instead of the script kiddies running bots & pingflooders on your system, they will be rooting it and taking it over.
This problem is compounded further by the fact that on virtual servers customers can usually install whatever they like on their websites, sometimes without even informing the sysadmin. All it would take is one old exploitable copy of awstats, for example.
The severity of a "local account escalation to root privileges" exploit shouldn't be underestimated.
the exploit worked on my gentoo i686 install. i had to change the exploit somewhat to get it to compile, but the result was the same, root access.
after patching my kernel using this patch and re-compiling my kernel, everything is OK. just like many others have related.
> The real problem here seems to be not Windows, but your ignorance about Windows.
Ever tried to delete some program's current directory?
Or renaming it?
It's not ignorance.
Hi, I've adapted a patch for 2.6.24.1 to correct the bug completly by following the instruccions of this mail of the lkml, you can found it here, but now the official kernel 2.6.24.2 solves the bug too. Cheers
Apparently Microsoft are Linux zealots, then. http://www.microsoft.com/canada/midsizebusiness/businessvalue/local/desktopupgrade.mspx Please to stop nonsense generalising kthx.
There is a new version of the kernel, 2.6.24.2 at kernel.org.
...about 90% belong to clueless users who won't bother to use the automatic update service. Ummm.... "who won't bother to use the ***automatic*** update service"? The whole point of an automatic update service that's on by default (which it has been since SP2) is that clueless users don't have to "bother" to do anything, since it's done for them, automatically. Hence the "automatic" part of "automatic update service"...What's purple and commutes? An Abelian grape.
I just compiled and successfully executed the exploit on my Debian Etch i686 laptop. I attempted it on unixclan.no-ip.org's free shell - it runs Debian Etch on a PA-RISC? machine. The exploit would not compile there, nor would it execute. This could be a security feature, or it could be that this does not affect RISC machines.
Who's willing to test the www.testdrive.hp.com shell servers?
Thanks for explaining what's obvious to anybody a step above the level of "retarded macaque." Although that does imply that you might have given a few kiddiez a lightbulb moment.
Forgive me if I am missing something, but wouldn't the average home user mentioned previously have root access via sudo anyway? An intruder would still need only to obtain the user's password to compromise the system. For someone like that, this issue is completely irrelevant.
You cannot separately disable the part of the kernel that contains the hole using a config option, you need the latest stable or development kernel, or a patched kernel which you can patch yourself or get from your distributor (the patch just adds a check that was missing, two lines).
Have you got your LWN subscription yet?
Works very fast. This is right before I patched my system with the latest kernel ( you can see the ubuntu updater in the background ). http://www.cs.lmu.edu/~j/files/rootExploit.png
This local root exploit is very likely to be the one used to infect servers reference in previous Slashdot article Mystery Malware Affecting Linux/Apache Web Servers.
It seems pretty clear that people are using other remote vulnerabilities to gain local user access and then using this local root exploit to install their "malware".
Get those boxes updated as quickly as possible, folks!
gonna upload Virtual Machines (drivers) into her firmware? Recompile the matrix? Blow away Sector Zero? Perform Trans-Regression AnalAsys on the Boundary Layers? Plug-in away...
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
For those with short memories: http://it.slashdot.org/article.pl?sid=08/01/24/1930207&from=rss http://www.channelregister.co.uk/2008/01/16/mysterious_web_infection_continues/
In other words, the attack goes something like this:
- Attacker finds exploitable PHP/Perl script and gains a shell as the Apache user (or the local user if Suexec is enabled)
- Attacker uploads an exploit based on this to get a root shell
- Up goes the "dynamic Javascript" Apache module and the hacked execs.
Plausible or not?Why does that patch differ from the following patch (which also, supposedly, fixes the exploit) ?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44
Which is the right/better fix?
So why isn't the desktop market penetration in double figure percentages
To busy apt-penetrating your mums ass
Windows Server eating into Linux server market share?
Because windows is a dirty whore that trys to gain favor with a bit of carpet munching
You need to shut the fuck up kid. Your other comment about the real world was clueless enough, but now you are giving bad advice that is going to potentially destroy people's data. Do not run that "fix-sploit" on any machine that you actually care about folks. It absolutely will not make your documents "safe" if you do.
As per Synaptic...
---
Commit Log for Tue Feb 12 15:03:30 2008
Upgraded the following packages:
linux-headers-2.6.22-14 (2.6.22-14.51) to 2.6.22-14.52
linux-headers-2.6.22-14-generic (2.6.22-14.51) to 2.6.22-14.52
linux-image-2.6.22-14-generic (2.6.22-14.51) to 2.6.22-14.52
linux-libc-dev (2.6.22-14.51) to 2.6.22-14.52
---
linux-source-2.6.22 (2.6.22-14.52) gutsy-security; urgency=low
[Tim Gardner]
* splice: fix user pointer access in get_iovec_page_array()
(CVE-2008-0600)
- LP: #190587
-- Tim Gardner Mon, 11 Feb 2008 10:01:17 -0700
---
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0600
what does unlikely() do??? Thanks!
Read and Comment at my BLOG
!!!