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
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.
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.
... 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
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
Well, if you are running machines that are designed to be enterprise class, it isn't a problem. Remote console is standard on enterprise class hardware.
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
[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.
Do you care about the security of your wireless mouse?
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.
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.
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
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.
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.
perhaps it isn't normal procedure for you, but it is for me. you obviously don't know how to configure LILO to boot the test kernel in the next boot only, or to configure the kernel for reboot on panic. but I have done it on servers on satellite links, hundreds of kilometers away, and it has worked for me, thanks.
Or just configure the kernel and reboot tomorrow when you get there.
Or use a decent server with lights-out management
In my current job all new hardware is being deployed with IPMI, meaning I can do remote reboots, remote consoles etc. via ethernet remotely from any machine in our environment we choose to give access to with no extra cabling.
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.
Feh, remote reboots are nothing on enterprise class hardware -- they have management consoles or RILO cards for that.
Remote installs are a bit more of a challenge, just because a virtual DVD drive is a bit slower than a local drive. (Virtual as in - the DVD is in my laptop, the system I'm booting off of it is on the other end of an internet connection.)
-- Alastair
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.
I'm not that sure, his actor was born in Prague. :-) But I appreciate that you know about us. ;-)
Ezekiel 23:20
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.
Oh, sorry... I should've posted yet another joke about MSWindows and go like - "it's OSS, no problem, tomorrow the patch will be out and I will have no problem updating kernel on all my servers and rebooting them", right?
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...
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.
That's cool and great. You rock, seriously! I don't agree with your assertion that "most people" would have terminal servers and remote power control units, but rock on.
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
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!
Thankfully, nobody runs Linux on enterprise-class hardware.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I better switch back to windows.
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.
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 |
+--------------+
| |
A true enterprise class machine doesn't have extra stuff installed that can be used against it. For example, a compiler.
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."
I moderated your post Funny but then realized it had become overrated, since you posted your demoderating comment as AC. So that's why I've posted this reply.
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.
"Enterprise Class" means easy to manage - it doesn't specifically mean more secure.
But even if it did, if someone can get the source code on to a machine to use a compiler, then they can use a compiler on another machine and copy the resultant binary. Removing the compiler is sacrificing convenience for no actual gain in security.
In any case - there's nothing about the post you're replying to that necessarily implies a compiler was on the machine. Most likely you'd compile the new kernel once, on a machine running your SOE, create and operating system package for it, then deploy it to all the affected machines.
If one doesn't reboot after the update, then the remote management interface the grandparent was referring to will allow you to interact with the machine's console without the OS running.
Advanced users are users too!
lol, yeah, cause finding another machine to compile (or cross-compile) on is SUCH an inconvenience... </sarcasm>
No compilers on a server just make it harder to fix, harder to maintain, etc.
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).
"Most People" running systems important enough to require an emergency kernel recompile on a Sunday, and who would do it over SSH rather than driving in to the office probably have all the aforementioned equipment.
Advanced users are users too!
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
I don't really see the point. While I'm all for taking things you don't need off of a server facing the internet, you often need a compiler, and if someone has broken into your server and is at the point where they could compile some code, you're already pretty screwed.
I hate to tell you, but if someone has your machine hacked enough that they could compile and run new nasty code on it if a compiler were present, uploading a compiler to it will be very easy for them and doesn't really present a hurdle at all.
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.
What was that saying again? "It is better to keep silent and appear wise..."?
In the meantime, you can take your strawman and stick it with your BSD superiority complex.
Mart"I know I will be modded down for this": where's the option '-1, Asking for it'?
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.
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
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
Uh, no.
Given the ease of getting a ready-compiled compiler anyway, there's not a lot of point in not leaving a compiler on a machine where you might occasionally have to compile something. It's just cutting off your balls to annoy your dick. If someone has got into your machine, you're already shafted. Not having a compiler around is really only delaying the inevitable.
What would be a bit more interesting would be if you had a special hacked kernel/GCC combo, so that your kernel would only run binaries that had been created with your special GCC. And even then, it's probably enough to keep the "occasional use only" stuff on a partition that is usually kept unmounted. (Especially if you had a specially-hacked fdisk binary that would not report the existence of this partition and kept the real fdisk in your "occasional use only" space.)
Je fume. Tu fumes. Nous fûmes!
Don't the staff in your co-lo already know the procedure for dealing with LI inside-out? Boot from nearest available CD with a kernel on it, make a mountpoint, mount usual / partition there, chroot into it, run lilo (which doesn't actually alter boot block yet, just makes record in cache), exit chroot environment (to force decaching, now boot block gets written: if you reboot from while you are still within the chroot, the boot block may not be changed and you will have to repeat the procedure) and reboot.
We've all forgotten to run lilo -- anyone who says they haven't probably hasn't compiled and installed a kernel. And that's why decent co-location facilities have people on hand, 24*7*52.
Je fume. Tu fumes. Nous fûmes!
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.
Yeah but it doesn't handle dual booting too well...
;)
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
Stop Computers/Cars Analogies on S
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.
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.
1. Reboot syncs all devices.
2. No one uses lilo for at least five years now.
Contrary to the popular belief, there indeed is no God.
Strictly speaking, the foregoing should be in the past tense, because I haven't had it happen to me for awhile. And maybe that behaviour was confined to the versions of kernel, lilo and chroot we were using then. At any rate, one extra press of ctrl+D and the forced sync that follows (and which would have had to be done anyway, just as part of the "main" sync due to rebooting rather than separately) is a small price to pay for having it work everytime. Unless they were already using lilo before grub became popular, and decided to stick with something that wasn't broken and didn't need fixing
Je fume. Tu fumes. Nous fûmes!
...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?
Contrary to the popular belief, there indeed is no God.
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.
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?What are you talking about? Of course it does.
I can boot off a virtual CD a thousand miles away if I want. Remote console is like being there. Hell it's even useful to use it in the same building so you don't have to stand up in front of a KVM in a cold, loud room. IP KVM's are similar, but a poor second to the RILO that is in HP servers for example. They do a LOT.
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