×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

586 comments

Beauty of OSS (4, Insightful)

bigtomrodney (993427) | more than 6 years ago | (#22372452)

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.

Re:Beauty of OSS (4, Interesting)

IBBoard (1128019) | more than 6 years ago | (#22372536)

And even if it isn't on its way (and while it isn't here) you can still get the source and remove the problematic part if you don't need it. Try recompiling Flash or some other commercial software without the section that has the exploit in ;)

.

Note: The above assumes that the kernel compiles, which may not always go as smoothly or be as you'd like. That doesn't change the fact that it is theoretically possible, though.

Re:Beauty of OSS (2, Funny)

dotancohen (1015143) | more than 6 years ago | (#22372626)

And even if it isn't on its way (and while it isn't here) you can still get the source and remove the problematic part if you don't need it. Try recompiling Flash or some other commercial software without the section that has the exploit in ;)
Well, you could always just enter a blank CDR in the drive. I'd say that's about as close as you are going to get to "remove the problematic part" from Windows.

Re:Beauty of OSS (0, Insightful)

Anonymous Coward | more than 6 years ago | (#22372758)

Wow... 3 posts before some twat turned it into a platform for bashing Windows.

Pretty good. That's 2 more posts than I expected when I read the headline...

Re:Beauty of OSS (2, Funny)

Anonymous Coward | more than 6 years ago | (#22372878)

The smugness of these OSS fanboys just makes me want to use Windows ME so badly.

And smack them in the face.

Re:Beauty of OSS (0)

Anonymous Coward | more than 6 years ago | (#22372982)

In all fairness the thread started off toward that bias.

Re:Beauty of OSS (4, Insightful)

nacturation (646836) | more than 6 years ago | (#22372640)

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.
Of course, the problem may also have been known six months ago. Not that that differs from closed source, but I don't see the openness of the code as a particular benefit in this case. The real benefit seems to be that when someone releases something as open source and they put their name on it, they're more inclined to be responsive to problems and provide quick fixes than when it's just some company's product and the developer's reputation is shielded by the company.
 

Re:Beauty of OSS (4, Interesting)

RonnyJ (651856) | more than 6 years ago | (#22372698)

Looking at the comments at the top of the code, it's described as "quite old code" (assuming you believe the author).

Re:Beauty of OSS (1)

pizzach (1011925) | more than 6 years ago | (#22372930)

There is a VERY real benefit of open source code in this case. People compiling the kernel is not uncommon. With the tools accompanying the kernel you can skip compiling the offensive parts with out touching any code. You can't do that with something closed source.

Re:Beauty of OSS (1)

neomunk (913773) | more than 6 years ago | (#22372656)

"Ah, shit" is correct. I would like to add a gracious 'Thank You nenolod' for not being a tool and keeping this little nugget to yourself.

Re:Beauty of OSS (1)

arivanov (12034) | more than 6 years ago | (#22372708)

I said it when I saw the description of vmsplice() for the first time. I guess I was right.

Re:Beauty of OSS (5, Informative)

Anonymous Coward | more than 6 years ago | (#22372790)

The problem is now known so I'm sure a fix is already on the way.
Holy shit, no kidding - the form of an exploit which fixes the bug live in the kernel mem.
nobody$ ./exploit
[..]
[+] mmap: 0xb7f29000 .. 0xb7f5b000
[+] root
root# ^D

nobody$ ./disable-vmsplice-if-exploitable
[..]
Exploit gone!
nobody$ ./exploit
[+] mmap: 0xb7f34000 .. 0xb7f66000
[-] vmsplice
nobody$ no root for me anymore!


By Morten Hustveit:
"a modification of the exploit that finds the address of sys_vmsplice in the
kernel (using /proc/kallsyms) and replaces the first byte with a RET instruction
(using mmap of /dev/kmem)" from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953#14 [debian.org]

HA HA (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22372454)

Linux sucks!

The sound you hear... (5, Funny)

downix (84795) | more than 6 years ago | (#22372460)

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...

Re:The sound you hear... (1)

MPAB (1074440) | more than 6 years ago | (#22372546)

kernel on a sunday afternoon... along with the millions of cell phones ringing as the bosses read this...

Yeah right! As if the bosses would spend a Sunday afternoon (or any day at all) reading Slashdot...

ssh (0)

Anonymous Coward | more than 6 years ago | (#22372630)

uh, I opened an ssh window instead.

Re:ssh (0, Flamebait)

Unoti (731964) | more than 6 years ago | (#22372686)

Oh sure, you're recompiling the kernel of your production environments from home. Hopefully, everything will go really well! Better hope it boots properly the first time! Or perhaps this is a normal procedure for you, and you can change kernels remotely easily when the system won't boot.

Re:ssh (3, Insightful)

walt-sjc (145127) | more than 6 years ago | (#22372902)

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.

Re:ssh (1)

kasperd (592156) | more than 6 years ago | (#22372984)

Oh sure, you're recompiling the kernel of your production environments from home.
I have had to upgrade kernels on production systems located on a different continent. In such a case it doesn't really matter if I do it from home or from the office.

jessica_biel_naked_in_my_bed.c ? (5, Funny)

Anonymous Coward | more than 6 years ago | (#22372480)

I strongly suspect this code doesn't do what it says on the tin.

Re:jessica_biel_naked_in_my_bed.c ? (1, Funny)

Anonymous Coward | more than 6 years ago | (#22372676)

I strongly suspect this code doesn't do what it says on the tin.
Well, it's OSS, you could always fix it with a patch...

Re:jessica_biel_naked_in_my_bed.c ? (5, Funny)

BJH (11355) | more than 6 years ago | (#22372810)

realdoll_and_a_tube_of_lube_on_my_inflatable_mattress.c ?

Re:jessica_biel_naked_in_my_bed.c ? (5, Funny)

LiquidCoooled (634315) | more than 6 years ago | (#22372738)

Thats because you are compiling it with the wrong target.

You need to include justin_timberlake.h and link it with the millionaires library.

Naturally (-1, Troll)

SilverEyes (822768) | more than 6 years ago | (#22372484)

Of course this doesn't affect the security of Linux. It's just an oversight. Linux, still 100% bug free!

Thank God (5, Funny)

Zoxed (676559) | more than 6 years ago | (#22372504)

Phew, lucky I run MS Windows then !!

Re:Thank God (5, Funny)

Anonymous Coward | more than 6 years ago | (#22372566)

That's like finding out there's a new 24-hour flu going around, and thanking God the AIDS will kill you first.

Re:Thank God (1, Funny)

Sique (173459) | more than 6 years ago | (#22372746)

AIDS doesn't kill you. It's the inability, that comes with AIDS, to combat the virus of the 24-h-flu, that kills you.

Re:Thank God (0)

Anonymous Coward | more than 6 years ago | (#22372966)

AIDS doesn't kill you. It's the inability, that comes with AIDS, to combat the virus of the 24-h-flu, that kills you.
Hmm. Is that like the blood's inability to coagulate around the knife sticking in your chest?

Re:Thank God (5, Funny)

monkeySauce (562927) | more than 6 years ago | (#22372604)

Phew, lucky I run MS Windows then !!

I know what you mean. It's nice not having to freak out periodically like this since you live in a constant state of panic anyway.

Re:Thank God (2, Funny)

Anonymous Coward | more than 6 years ago | (#22372946)

You'll get used to it.

Misleading (3, Interesting)

arth1 (260657) | more than 6 years ago | (#22372518)

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.

Re:Misleading (5, Informative)

shadow42 (996367) | more than 6 years ago | (#22372584)

I just successfully used this exploit on a Fedora 7 box running 2.6.22.4. A bit out of date, yes, but a great deal of "home users" who are running Fedora, Debian, Ubuntu (especially Ubuntu), etc., either don't know how to compile their own kernel, or don't care enough to try. Not everyone who uses Linux is going to bother compiling a custom kernel in order to fix a problem like this, especially if they don't have the skills of a sysadmin.

Re:Misleading (5, Insightful)

Anonymous Coward | more than 6 years ago | (#22372674)

The average home user that's not willing to put in the effort to compile a new kernel is the home user that doesn't have anyone but either themselves, or people with physical access to the machine using it.

If the only people that have accounts on the machine have physical access to it, this exploit is a lot more work than just opening the box...

Re:Misleading (1)

arth1 (260657) | more than 6 years ago | (#22372774)

The average home user that's not willing to put in the effort to compile a new kernel is the home user that doesn't have anyone but either themselves, or people with physical access to the machine using it.

True, but then the severity is less because they're unlikely to be affected anyhow, right?

It should mainly be a concern for those who do have other users or business operations on their boxen, and those should not have the affected kernel module in the first place unless they really need it. If they do, and they don't need it, this is a useful warning that perhaps they should start culling their systems down to what they actually need.

Regards,
--
*Art

Re:Misleading (1)

neumayr (819083) | more than 6 years ago | (#22372888)

I imagine it'd be pretty easy to talk one them linnics noobs looking for help on IRC to give you ssh access, so you can "help them".

Re:Misleading (1)

dotancohen (1015143) | more than 6 years ago | (#22372712)

I just successfully used this exploit on a Fedora 7 box running 2.6.22.4. A bit out of date, yes...
Fedora 7 is not out of date yet. It's got at least another two months of official support if I'm not mistaken, and it will get a whole lot more than that. I'm still running FC6 on one box.

Re:Misleading (2)

MikeUW (999162) | more than 6 years ago | (#22372834)

If I end up with a locally installed root kit on my laptop, I'll only have myself to blame. For some reason, though, I lack the motivation to recompile the kernel to protect myself from myself.

Re:Misleading (5, Insightful)

kitgerrits (1034262) | more than 6 years ago | (#22372962)


You know, I haven't built my own kernel since 'make menuconfig' was the most advanced method around.
I got rather tired of picking and choosing what I need, just to get faster boot times.

That, and any time you need (professional) support for a third-party application, the first thing they ask you is wether you are running a stock kernel.
I -want- to be able to tell MySQL and RedHat to fight it out amongst themselves if my database does not live up to expectations.
I have better things to do with my time than to set-up and analyse endless system profiles, straces and stack dumps.

Grow up, get a real job and see what the real world is like.
You'll find that you no longer have the time to check SANS and packetstorm every day, just to see if your system is secure, spend days just to get that library to compile and then see the entire system go out the window, because it cannot be maintained (because you have be re-assigned to another project).

Re:Misleading (4, Insightful)

Unoti (731964) | more than 6 years ago | (#22372636)

Yet another good example of why you shouldn't hire the sysadmins who blindly use what the vendors ship
I suppose. But honestly, not everybody really needs a sysadmin that's going to diddle around for weeks and compile kernels just to set up a mail server and samba, for example. For most things, I'd rather have someone who just gets the work done rather than goofing off compiling kernels, installing ReiserFS and doing god knows what else other than things that really matter. Sure, there's a place for all that, but honestly most environments don't require it.

Re:Misleading (1)

lakeland (218447) | more than 6 years ago | (#22372696)

I agree. It is the job of the vendor to know what about this sort of thing and turn off the features that I won't ever want so that the sysadmin doesn't have to concern himself with such details.

Saying 'it is the user's problem' just isn't good enough. It is everyone's problem, and if everybody tries to fix it then maybe it will go away.

Re:Misleading (2, Informative)

pak9rabid (1011935) | more than 6 years ago | (#22372730)

Agreed. I'm a sysadmin who "blindly uses what the vendors [RHEL and CentOS] ship", not because I don't know how to recompile a kernel, but because sitting around and compiling a customized kernel for every server we have would be a complete waste of time.

Re:Misleading (1)

Unoti (731964) | more than 6 years ago | (#22372782)

I would like to acknowledge, however, that these words ring a little more hollow than normal today.

Re:Misleading (1)

Vectronic (1221470) | more than 6 years ago | (#22372836)

"I'd rather have someone who just gets the work done rather than goofing off compiling kernels, installing ReiserFS and doing god knows what else other than things that really matter."

Those are the things that really matter, if your Admin takes a couple of weeks to do that, well, thats another story, but taking a few days to properly set up a server (especially since you can normally do it in parallel to the server you already have setup, basically only about 15 minutes downtime), means you probably wont have to touch the setup again for a year or more... instead of just an hour, and then having to fix things every week...

I dunno about you, but im pretty sure the time it takes for a proper setup, is better than possibly years of lost data, and all around confusion over whats there? whats missing? no I didnt get your e-mail, are you sure you sent it? why is my computer acting so strange?...

Re:Misleading (5, Funny)

fo0bar (261207) | more than 6 years ago | (#22372666)

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.

Which reminds me, have you done your emerge -abuop6QvvvvVVvVVxz world yet today?

Re:Misleading (1)

RonnyJ (651856) | more than 6 years ago | (#22372812)

Could you go into any detail into why most installations don't need this particular function? Even if you can, it's hardly misleading to call it a 'Linux Kernel 2.6 Local Root Exploit' if it is one, is it?

Re:Misleading (5, Insightful)

Kjella (173770) | more than 6 years ago | (#22372816)

You've got to be kidding me right? Like every sysadmin out there is supposed to know about every feature he doesn't use? Most of the time if you compile out something you'll end up breaking something you do want because you don't understand the internal kernel dependencies or what this really means in terms of functionality. Don't forget I now expect you on duty 24/7 to compile new kernels whenever there's a kernel patch available, particularly when you're sick and or vacation and whoever is filling in for you only knows apt-get/yum/whatever. Anyone that spent that much time on managing a Linux server would probably be fired because he'd be less efficient than a Windows server and an MSCE.

Re:Misleading (1)

caseih (160668) | more than 6 years ago | (#22372908)

No, it is a universal problem. If you want any vendor support at all, you have to be running stock packages, especially for the kernels. So this is a huge deal. It will affect most linux installations out there. People don't recompile their own kernels on a regular basis. Crap like this happens from time to time and it does hurt Linux' reputation. Frankly, going around speaking like this doesn't promote Linux at all with PHBs and the people who actually pay the bills and buy the technology.

No, the headline is not misleading. Most installations of linux that use the 2.6 kernel *are* vulnerable.

Whatever... (1)

dowdle (199162) | more than 6 years ago | (#22372922)

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.

Re:Whatever... (1)

Hal_Porter (817932) | more than 6 years ago | (#22372986)

Yeah, heaven forbid that you rely on employees not being mindless drones. Far better to hire a highly paid consultant to deindispensableize them.

Before the inevitable occurs: (4, Insightful)

ZorbaTHut (126196) | more than 6 years ago | (#22372522)

"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.)

Re:Before the inevitable occurs: (5, Insightful)

RonnyJ (651856) | more than 6 years ago | (#22372662)

The difference is that we know about this hole, and can now fix it
We know about it now, but how long have some other people known about it? There's this quote from the code:

This is quite old code and I had to rewrite it to even compile.

Re:Before the inevitable occurs: (2, Insightful)

moderatorrater (1095745) | more than 6 years ago | (#22372952)

what steps will be taken to ensure that bugs of this type - whatever they might be - don't crop up again?
All code in the kernel goes through a fairly exhaustive review process to the point where the major developers, like Linus, don't write code much, just review what's already been put in. If you look at the number of linux kernel exploits over the past year, you'll see that there's not a whole bunch (this is the only one I've heard of). Whether it's as good as a commercial, proprietary product, I don't know. But I do know that it's good enough to get the job done well.

For those that would rather write than read. (-1, Offtopic)

delire (809063) | more than 6 years ago | (#22372530)

This is a local exploit in that kernel version range, in other words instigated by someone at a keyboard connected to the host and with an existing user account on the machine.

Re:For those that would rather write than read. (1)

elzurawka (671029) | more than 6 years ago | (#22372612)

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.

Re:For those that would rather write than read. (5, Informative)

McDutchie (151611) | more than 6 years ago | (#22372614)

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.

Re:For those that would rather write than read. (2, Insightful)

etymxris (121288) | more than 6 years ago | (#22372618)

Well if you have a shared hosting account that allows ssh logins, anyone can now become root and start messing around.

Re:For those that would rather write than read. (1)

radu.stanca (857153) | more than 6 years ago | (#22372664)

"This is a local exploit in that kernel version range, in other words instigated by someone at a keyboard connected to the host and with an existing user account on the machine."

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.

That's still pretty dangerous (1)

Random Walk (252043) | more than 6 years ago | (#22372680)

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.

Re:For those that would rather write than read. (4, Insightful)

tabrisnet (722816) | more than 6 years ago | (#22372694)

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.

Re:For those that would rather write than read. (1, Informative)

Anonymous Coward | more than 6 years ago | (#22372876)

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.

Re:For those that would rather write than read. (1)

larry bagina (561269) | more than 6 years ago | (#22372762)

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.

Re:For those that would rather write than read. (1)

Doug52392 (1094585) | more than 6 years ago | (#22372920)

So could it be run on computers with public shell access (connected via SSH)?

This will be fixed in a day (1, Informative)

Doug52392 (1094585) | more than 6 years ago | (#22372574)

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...

*checks kernel version* 2.6.23.8-34... wow I'm out of date :) Is my kernel version effected?

Re:This will be fixed in a day (1)

chuckymonkey (1059244) | more than 6 years ago | (#22372682)

Test it and let us know. They provided the code.

Re:This will be fixed in a day (1)

Doug52392 (1094585) | more than 6 years ago | (#22372874)

It works. :( The first time I ran it I got a segmentation fault. The 2nd time I ran it, X crashed. When I ran it for a 3rd time in a bash session, I was sucessfully logged in as root just by running the program. I'm running Fedora 7, with the kernel version I said above.

Re:This will be fixed in a day (0)

Anonymous Coward | more than 6 years ago | (#22372744)

Patch is here [gentoo.org].

Re:This will be fixed in a day (0)

Anonymous Coward | more than 6 years ago | (#22372938)

If it where a Windows problem, it would be patched via Windows Update in a few weeks.

Now its a Linux kernel issue affecting god knows how many installations without proper update service, meaning that there will be boxes with this exploit years to come.

Buggy Code (0)

Anonymous Coward | more than 6 years ago | (#22372582)

I compiled the code without problem. But when I rebooted, the splash screen said 'Vista Home Premium'.

Works for me too (3, Insightful)

etymxris (121288) | more than 6 years ago | (#22372588)

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

Inside a Vserver on Grsec/PAX it seems save (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22372672)

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.

Is this x86/x86_64 only? (4, Interesting)

the_humeister (922869) | more than 6 years ago | (#22372684)

The proof-of-concept code only supports x86 and x86_64. Does that mean other architectures are immune?

Re:Is this x86/x86_64 only? (2, Informative)

cnettel (836611) | more than 6 years ago | (#22372822)

As it's all about VM handling, I'm not sure, maybe some platform might give a panic, maybe some will use a different codepath, but it seems to be high-level enough that it is common code for all architectures. However, the only parts that are specific for x86 and x64 in the actual exploit are really the exploit code that's called within the kernel. As it is inline assembler and calling-convention specific, one would need a separate set for each platform. This is just like a user-space buffer overflow needs a specific exploit per platform, although there might be a common bug.

Re:Is this x86/x86_64 only? (1)

Florian Weimer (88405) | more than 6 years ago | (#22372842)

The proof-of-concept code only supports x86 and x86_64. Does that mean other architectures are immune?
No.

Re:Is this x86/x86_64 only? (2, Funny)

Zoxed (676559) | more than 6 years ago | (#22372932)

> The proof-of-concept code only supports x86 and x86_64. Does that mean other architectures are immune?

I heard that the Debian Architecture group are working through the night to ensure it will work on *all* of their supported platforms. Should be on your favourite mirror by Monday lunchtime !!

Does not work!!! (0)

Anonymous Coward | more than 6 years ago | (#22372706)

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 am so depressed ... (1)

Cytlid (95255) | more than 6 years ago | (#22372724)

... 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.

Re:I am so depressed ... (4, Informative)

Cytlid (95255) | more than 6 years ago | (#22372792)

Uh oh. There's another link, (not the one from the /. article) that worked on my machine:

http://www.milw0rm.com/exploits/5093 [milw0rm.com]

Notice the original article links to 5092.

Re:I am so depressed ... (1)

Tony Hoyle (11698) | more than 6 years ago | (#22372994)

Second verson doesn't even compile for me: /tmp/cctpc16q.s: Assembler messages: /tmp/cctpc16q.s:118: Error: Incorrect register `%rax' used with `l' suffix

First one even works within a xen virtual machine, which I would have thought it couldn't do because of the hypervisor.

Doesn't seem to work on my virtual machine in the US - 'function not implemented' error. So that's safe.

Now I've got to work out how to patch all my flippin' machines on a sunday night... sigh...

Funny comments :) (5, Informative)

K. S. Kyosuke (729550) | more than 6 years ago | (#22372734)

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).

"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, ..." [last for four words utterly incomprehensible :)]
"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 :)) 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*.

This workaround works (4, Informative)

FliesLikeABrick (943848) | more than 6 years ago | (#22372754)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 [debian.org]

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.

Neat, but... (2, Informative)

kickmyassman (1199237) | more than 6 years ago | (#22372764)

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).

Re:Neat, but... (1)

BJH (11355) | more than 6 years ago | (#22372856)

It upgraded your rights but didn't replace your environment.

Just add /sbin and /usr/sbin to your PATH.

Re:Neat, but... (1)

robo_mojo (997193) | more than 6 years ago | (#22372894)

I still can't run administrative functions (like ifconfig) without running them with an absolute path

That's only because /sbin and /usr/sbin didn't get put in your path, which is set at login. It is the same as the difference between "su" and "su -l" (the later working as a login shell).

Anonymous Protests Scientology (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22372766)

Fucking newfags.

Newfags =/= Anonymous

This flaw is CVE-2008-0600 (5, Informative)

iamamoose (243231) | more than 6 years ago | (#22372830)

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 [kernel.org]

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 [redhat.com]

Fedora tracking bug
https://bugzilla.redhat.com/show_bug.cgi?id=432229 [redhat.com]

Re:This flaw is CVE-2008-0600 (2, Informative)

icydog (923695) | more than 6 years ago | (#22372976)

This worked on my Fedora box both locally (i.e. keyboard) as well as through SSH. However, it did NOT work on my CentOS 5 installation. The box locked up hard and now I have to call someone to reboot it... silly me...

where to find in menuconfig (2, Interesting)

FudRucker (866063) | more than 6 years ago | (#22372896)

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?

But this can't be real! (-1, Flamebait)

SwashbucklingCowboy (727629) | more than 6 years ago | (#22372916)

Linux doesn't have nasty defects like Windows. At least that's what all the Linux zealots claim.

Re:But this can't be real! (1)

eitreach (1211194) | more than 6 years ago | (#22372944)

Mm. Nonsense-generalising makes the world go round. Be sure to check for virusses installed while you wrote your message.

Fuck, this is bad (0, Troll)

ceeam (39911) | more than 6 years ago | (#22372924)

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.

Actual trial of the exploit..... (1)

Oxide (92607) | more than 6 years ago | (#22372934)

[hity@localhost ~]$ kwrite expl.c
[hity@localhost ~]$ gcc -o expl -O expl.c
[hity@localhost ~]$ ./expl
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7f98000 .. 0xb7fca000
[+] root
[root@localhost ~]# damn what a nasty hole :(
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...