Slashdot Mirror
Linux Kernel Exploit Busily Rooting 64-Bit Machines
An anonymous reader writes "Running 64-bit Linux? Haven't updated yet? You're probably being rooted as I type this. CVE-2010-3081, this week's second high-profile local root exploit in the Linux kernel, is compromising machines left and right. Almost all 64-bit machines are affected, and 'Ac1db1tch3z' (classy) published code to let any local user get a root shell. Ac1db1tch3z's exploit is more malicious than usual because it leaves a backdoor behind for itself to exploit later even if the hole is patched. Luckily, there's a tool you can run to see if you've already been exploited, courtesy of security company Ksplice, which beat most of the Linux vendors with a 'rebootless' version of the patch."
I thought only windows got exploited this way.... oh thats right All OS's do.
Oh no, now I need a permanently running virus scanner... may as well switch back to M$ :-(
Why does the summary and articles read like a paid advertisement for Ksplice?
First root! Oh crap...
Acidbitches..... In my day, naming your ubeR l3e7 h4xX0r 6r00p MEANT something.
Yes, there's an available rights escalation vulnerability in recent Linux Kernels that's best patched by updating your system with the latest updates. The breathless nature of the fine summary betrays an eagerness to get Linux admins to click the links before they've done so. I'd rather not. Social engineering is such a powerful exploit mechanism after all.
The Windows geeks obviously will want to paint this as a native Linux vulnerability that they don't have - and it is marginally true. That's fine - but it's an escalation bug, not a remote root, and they've several dozen remote root bugs to close before they point fingers.
Help stamp out iliturcy.
This is a local exploit so I'm not horribly concerned and here is why.
You should always treat your systems as if an exploit already exists for both remote and local connections.
The systems I maintain are part of a bit of an elaborate network. There is a huge investment in controlling incoming and outgoing traffic as well as managing who actually has access to systems. While a local exploit a big deal it's not like there are a great number of places for users to inject this code. If someone could compromise an input vector and piggyback the exploit that still wouldn't get them very far. In fact, without knowing key details regarding the network infrastructure they would simply nab a host that could not reach the outside world.
With that said we do have a bit of reliance on lbs, traffic inspection, firewalls and a good bit of monitoring equipment. However, there is a solid investment in specific purpose network and security protocols to accomplish these goals. In a bit of a cheaper shop I'm wondering what others do to maintain security and get some of the same tools. (I'm being very vague about our setup intentionally, but there have to be some decent foss network tools as well).
If hostile users have local access, you're pretty much boned anyway.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I have 64 bit hardware but I run x86 based distros. 64 bit is only good for the extra ram maybe to the desktop user. And there still is a lot of issues getting older programs to run on a 64 bit distro.
1. MS & Windows shills may laugh about this, but only because they feel your pain. Beyond that, what does making this statement even mean?
2. 64bit hardware is cheap. You can buy an AMD64 X2 5000 Dual Core CPU for 38 bucks shipped.. add a mobo for another 45 and if you need ram, another 50. eBay for more savings
just checked my kernel version against the ubuntu advisory, all good.
I guess the real story here is how quickly the holes are patched. No one should claim linux is perfect...but at least things like this should be fixed very quickly.
In this case...all is well - thank you ubuntu team (and those of other distros) !
Now Ksplice is really starting to piss me off. This is at least the fifth time we've get this kind of crap on slashdot.
Besides that, this is an escalation vuln ... it's local, ok? Not a remote exploit. And, regardless of all that, there's already a fix, which was promptly released before this got out of hand.
So, between the ksplice assholes that abuse each vulnerability that is published to blow it out of proportion and somehow imply that if you require ksplice to patch this without loosing your job (I mean, come on, If your service is critical enough that it can't accept 2 minutes of downtime for a reboot, then you have redundancy and can update machines one by one without any real downtime) ; and the winslow assholes that don't understand shit about security and somehow think that this means that GNU/Linux is insecure and as bad as their shitty system, I'm going nuts every time there is a new vuln in the kernel.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
I have an Ubuntu 10.04 cloud server and want to make sure everything is patched and not rooted. Does apt-get update/upgrade fix this particular exploit at this time? I also tried to run the Ksplice tool to see if I'm already rooted but it tells me this when I try to run it:
$ ./diagnose-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)
$$$ Kernel release: 2.6.33.5-rscloud
!!! Error in setting cred shellcodes
Any advice?
First you need remote access to my home machine, which is behind a NAT'd router and doesn't expose any services outside. That means that drive-by scanning won't work, and even if it did you'd have to find your way in via the only open port - ssh.
My systems in the commercial space are properly firewalled. It's a bad thing if anyone has shell access to them at all, let alone root.
Am I the only person who says "hell no" to running that "diagnosis" program? After looking through the code real quick, I have no interest whatsoever in running a program that performs the very exploit I'm supposed to be scared of, cuz I don't have time to make sure ksplite neutralized it properly. Also, since it's only a local exploit, I'm not concerned enough about it to run a diagnosis tool that implements it.
And good lord god almighty, what 12 year old wrote this code, that they think having function names like put_your_hands_up_hooker() makes them cool?
You don't even need that. PAE makes 64-bit unnecessary for a lot of things. Whenever I install linux on a USB drive with the intention of using it on multiple computers, I usually stick to a PAE-enabled 32-bit kernel, since it will work on older hardware and still support more than 4GB of RAM.
There is something to be said though about going to a 64bit operating system. The fact that there are a little more than twice as many general purpose registers in the CPU available means that code can be compiled to not need to do memory fetches anywhere near as often which means that the code will run faster. the extra addressing space has always been a red herring argument (e.g. i only need it if i have more than 4gb of ram).
Downloading the fix from Ubuntu as I read this article :-)
*** Korbinus ***
http://www.geotruc.net
@JDMetro my x64 distro handles x86 programs just find #osxftw #linuxsux
C'mon now. As others have pointed out, and has been mentioned earlier on /., this is a local root exploit. It's bad, it affects a lot of users (in theory), but to write this is to simply spread fear for most of those using Linux.
Why? Because the systems that inexperienced users run also happen to be those with a few, generally trusted users. Think netbooks. Sure, all local root exploits are bad and should be patched asap. But that doesn't mean "you're probably being rooted as I type this". It means that a remote attacker needs user-level privileges (say, with a browser or plugin vulnerability) first. Since Ubuntu and probably other major distros have already patched this, and the default settings for updates on these systems is to check fairly frequently, most end users will have the patched kernel quickly.
That leaves multi-user systems. The admins of these servers certainly benefit from finding out about the vulnerability asap, and they did (including through previous stories here). By now, though, most admins should have something in place if they don't have full trust in their users. If they don't, they should definitely be looking at whether this was exploited.
The bottom line is that there are many local root exploits which come out every year. This is the latest one, with a patch already available. Responsible admins of multi-user systems are used to dealing with this, and home users are almost certainly going to be patched before it causes any issues. For them, the latest Flash vulnerability is more worrisome. Even the extremely rare remote exploit of a service isn't usually an issue, since most modern distros don't start much of anything by default (including ssh, IIRC).
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
Whats new in that? Tons of GNU + Linux webservers are rooted & defaced every single day. Yawn... most non-zealots already knew that.
I'm not rich enough to afford 64bit hardware, but still this is not good...
Dang, my 3 year-old laptop, mid-level (at best) when it was news, runs 64-bit operating systems, and so does the $200 desktop I just built for my mom. There's plenty of decent 3-4 year-old hardware available used for dirt cheap that is 64-bit. this isn't a new thing any more, and you don't have to be rich. That comment just sounds odd in 2010, unless you are not in an English-speaking country or Western Europe.
This is a hacked account, for which the owner can not be held responsible.
... until you get closer to 16GB of RAM and you start running out of lowmem (especially on older 2.4 kernel systems).
$ man woman *
-bash:
Tell us how great OSS is.
OSS is great... my Ubuntu machines were already patched a day before the first scare stories about this exploit appeared here on Slashdot.
I'm not the king of all C coders, and please for the love of all that is good and holy don't trust some random stranger on the internet, but I read the source and if it's doing anything bad, it's doing it quite sneakily -- more so than I'd expect the teenager who wrote the exploit source to be capable of, frankly.
Now, do I wish the ksplice guys would've cleaned up/de-obfuscated their 'borrowed' code to make it a little less alarming-looking? Yep. Do I wish they weren't doing their ridiculous Chicken-Little routine in a transparent attempt to move some product? Also yes. Could that binary be pretty much anything? Uh-huh.
Is anything bad going to happen to you if you compile and run that C code? As far as I can tell, no.
The obvious way to have the most fum with this is to run a W7 host with a Linux client in a VM so you can be rooted while you are being rooted. ;)
Microsoft already felt the pain, because the Xbox 360 hypervisor got owned by the same exact hole . It would almost be the same instruction-by-instruction identical bug were it not for the fact that the 360 is a PowerPC system and this is an x86_64 hole. Yes, they, too, used a 32-bit compare to check the system call humber, then indexed into the array using the full 64 bits, exactly the same bug that caused this Linux hole.
Point out a current remote root exploit in Windows. To the best of my knowledge, there are none. Which means that the original poster is just fluffing his feathers trying to divert attention from the Linux issue.
While this isn't something that means Linux is majorly insecure or anything, it is a Linux issue. However fanboys don't like that, they can't just say "Yep, there's a problem." Instead they want to try and deflect it, make it about something else. So he deflects the issue by claiming there are some nebulous "remote root bugs," without any specifics.
Fortunately, I'm not rich enough to afford 64bit hardware, but still this is not good...
An Atom-330 and motherboard costs about $80... and I think the 230 is 64-bit for a few dollars less.
Our UNIX admin has the philosophy that anyone with local access can get root if they want it bad enough. Security isn't done by presuming you've made that impossible. Rather security is done by making sure you don't give access to just anyone, and to monitoring what people do. Local escalation exploits are things to be fixed, since they can always make a remote exploit worse (someone exploits something remotely, gets unprivileged access, exploits the local exploit to get root) they aren't a critical threat usually.
However I will say you don't make things much better when you start with name calling with regards to Windows and the people that run it. That smacks of being the sort of asshole that knows little about the other platform that you are painting them to be. That you have a preferred platform is great. One would hope it is based on good reasons. However name calling on another platform indicates it is more likely based on zealotry than anything else.
Stop perpetuating this fucking myth. There are other good reasons to use a 64-bit build besides the address space it gets its namesake from. I can run crufty old 32-bit software just fine on a 64-bit Linux.
There have been plenty of benchmarks pointing to 64-bit being no worse and in many cases outperforming their 32-bit counterparts. Things like SSE being enabled for all 64-bit binaries by default with GCC, extra registers, NX bit, and so on all standard on 64-bit Linux machines.
As for compatibility, I want to know. WTF doesn't run on a 64-bit Linux that actually affects more than some obscure corner case that maybe 10 know about and three of which actually care about? I hear it all the time, but never actually see it. What is this compatibility problem?
Its just a bunch of crap that has been regurgitated on the internet because it once had some amount of truth many years ago. Go ahead with your i386 and i586 packages built for 1993 and act all smug.
Linux exploit story sends the Slashdot crowd into a hissy fit lol.
Talk about a biased group. Mention a Linux exploit, a very serious one in this case, and look at them up in arms. More biased than Fox News and CNN combined.
Oh and you missed the "defective by design" tag on this article.
Pretty much everything since Prescott on the Intel side and, err... everything on the AMD side is 64bit. If you have anything you bought since late 2006, good changes that it's a 64bit system...
http://tinyurl.com/linuxbad. Reason for http://openbsd.org/ and http://freebsd.org./
Microsoft and their associated Windows shills are loving this.
You lot stopped just short of calling Linux 'unsinkable'. Of course people are going to have fun with it, it's just not limited to shills.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Tell us how great OSS is.
Tell us how much better Linux is.
Tell us how badly Microsoft sucks.
I'm a PC, and using Windows instead of Linux was my idea.
I knew it was just a matter of time before Ballmer showed up as an AC on Slashdot.
I have 64 bit hardware but I run x86 based distros. 64 bit is only good for the extra ram maybe to the desktop user. And there still is a lot of issues getting older programs to run on a 64 bit distro.
The x86_64 architecture has more registers than i386 and can do some operations 64 bits at a time rather than 32 bits. This means that programs compiled to run on a 64 bit architecture are often significantly faster than those compiled to run on 32 bit architectures.
I think an average figure is 20% faster or so on the same hardware -- you get this simply by installing a 64 bit distribution and using 64 bit binaries. Your system can probably still run 32 bit binaries (if it has the right libraries) but they won't be faster.
The advantages go beyond a larger address space.
I should also mention that the issue about getting "older programs to run" used to be a big deal -- but isn't any more. The old 32 bit binaries typically work after installing the 32 bit libraries needed (and they're usually part of the distribution) and most programs that have been maintained in the last five years or so compile and work on 64 bit distributions just fine.
As a long time user I get the option to disable advertising. I don't. I even whitelist Slashdot in Adblock because I support the site and the banner ads are rarely obnoxious.
These poorly disguised articles-as-ads are quite annoying though. Just make KSplice pay for a banner like everyone else.
What is annoying me about these issues is that they are described so poorly that I'm not certain if I have a problem. I run 64-bit Linux but no 32-bit code and there are no local users other than for the services I'm running (http and ssh). So do I need to take the time to do something or can I wait for a normal update?
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Is anything bad going to happen to you if you compile and run that C code? As far as I can tell, no.
You are very likely correct in thinking that adding yet another anonymous recommendation on the internet will make more people run the code. However, this is Slashdot, where the users are slightly more security aware than on an average internet site.
You see, If I were to attack all those nifty linux boxen out there, what would be a better attack vector than advertising your exploit on slashdot, which is known to accept almost anything on the front page, and yet is very likely to contain the biggest active linux user community on the nets? By looking at the code it seems obvious that the tool contains enough binary code to contain an exploit or three. If it is never used in a malicious way, it is somewhat difficult to say. So, outside a security lab setting, it is hard to tell if the provided code is not the exploit itself. Definitely "You are probably getting hacked right now! Check for viruses for free!" has been one of the more common attack vector against Windows users.
Whatever the case, I would not recommend running code that looks like this:
static char dis4blens4sel1nuxhayettgdr64545[] and
static int wtfyourunhere_heee(char *out_release, char* out_version)
I'm pretty sure more than 10 people know about and more than 3 people use flash. As much as I hate flash, until we DO get rid of it, it is pretty much required if you want to watch more a dozen videos online. Oh yeah, did I mention thunderbird's lightning extension. I went for about 6 months before I could get that to work!
I've been running 64 bit on my machine for years, but there are still some developers that simply don't realise how many of us do.
Not only is it cheap, but even the Atoms are getting 64-bit across the range with the next revision. I don't think there will be any non-64 bit chips in AMD or Intel's lineup at that point.
where do you get that numbers?
Going to 64 bit means your instructions will be 64 bit, which means doubling the cache mem usuage.
Depending on how the os/app uses the cache you may even find an slow down on performance.
From performance point of view, if you don't really need 64 bits ( probably most of users will be fine with 4GB ram in next years) stay at 32 bits.
Does anybody know what this means? The system is already patched. I just wanted to know if someone left a backdoor before I could apply the patch and reboot. $ ./diagnose-security-issue-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)
$$$ Kernel release: 2.6.35.4
!!! Error in setting cred shellcodes
Some people here are students, and until you can find this kind of stuff in a dumpster... man, there are priorities (aka pizza and beer)
When our name is on the back of your car, we're behind you all the way!
2. 64bit hardware is cheap. You can buy an AMD64 X2 5000 Dual Core CPU for 38 bucks shipped.. add a mobo for another 45 and if you need ram, another 50. eBay for more savings.
Everybody lives in America. Right?
Y'know, sometimes there are posts that are poignant, interesting, on-topic, and yet are modded down as a troll for no better reason than people who have mod points are more interested in squelching challenging ideas. That's fine, and slashdot has a mechanism to deal with that, called Karma.
Because I have good /. Karma I can call your attention to the parent post even though I believe it's been badly moderated. Because I'm a Slashdot subscriber, I get an extra point to add to this post, which calls attention to the parent. I have enough good Karma that even if this post is moderated a troll I will have lost nothing.
I'm making this amplifying post because the parent post was moderated down in one second. It was born silenced. Obviously there were moderators prepared to prevent you from hearing my response to the question asked. Some of you might for this reason alone find my words above meaningful or intriguing.
Help stamp out iliturcy.
Wow, I don't think "pretty much all" windows machines were ever infected with the same thing. Good thing Linux is sooooo much more secure. I mean other than the fact that no it isn't, people just don't target them. I think people got way too comfy and caused this dire situation.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
Well if that's how you feel then go ahead and enjoy yourself while you can -- the next winderrz catastrophe will be along in just a matter of minutes. :D
What does that have to do with anything? You can't buy 5 year old technology at discounted prices in countries other than America? I have a stack of P4's that are compatible with 64 bit, I'll give them to you if you pay shipping. Thank Dell and their 3 year warranty and motherboards that are guaranteed to die after 3.5 years.
How badly can the /. moderation system be abused? I'm not sure. Please read the cousin post and the parent and decide for yourself whether the moderation system has been abused by me or somebody else.
If it's me, I can bear it.
Help stamp out iliturcy.
I run ubuntu 10.04, but I use a 2.6.35 kernel from the maverick kernel ppa. I need it because I have an WPC300N linksys 802.11n wireless card. The broadcom sta driver wouldn't work when I was running 2.6.32. It would be cool if ksplice supported more kernel configurations, particularly maverick kernels.
because this is a local exploit and I don't have any public ports. wtf is this FUD?
--
Stay tuned for some shock and awe coming right up after this messages!
Without a doubt.
But I don't trust my computer anyway. Fuck malware. I'm a good power surge or hardware failure away from data loss anyway. If anything, I'm kept on my toes to do things like have a decent plan for making backups and keeping them fresh.
I don't have a false sense of security, so it's fun witnessing the folly of people that do. In a small way it's a pity that this story is almost certainly sensationalized.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
If you're wondering if I'm willing to burn up all my established good reputation to buy the reader the chance to read my parent comment, the answer is yes.
Now the question is how many mod points have you got?
Help stamp out iliturcy.
Just to clarify I understand that there are two zero day root-providing bugs. (Everyone talks about THE bug.)
CVE-2010-3301 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=36d001c70d8a0144ac1d038f6876c484849a74de and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eefdca043e8391dcd719711716492063030b55ac
CVE-2010-3081 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c41d68a513c71e35a14f66d71782d27a79a81ea6
Sometimes I wish /. moderation was trackable.
Help stamp out iliturcy.
hahahahahahaha....wait...I'm running 3 servers with it. Crap.....
Yep, even Windows limits RAM to 16GB when running 32-bit with PAE in it's 3G/1G split mode for the same reason. (It defaults to 2G/2G split, unlike Linux.)
The situation appears to be exactly as described by Ksplice.
CVE-2010-3081 has been discussed on RedHat forums and elsewhere.
The Ac1db1tch3z exploit published on the full disclosure list http://seclists.org/fulldisclosure/2010/Sep/268
does indeed appear to contain a backdoor (0p3n1ng th3 m4giq p0rt4l).
From the comments, the vulnerability was found in 2008 and the exploit has been used by the author for some time, and may have been circulating in the underground. When the vulnerability was found and disclosed by Ben Hawkes, the exploit was published to a wider audience.
A number of sysadmins may well have run the exploit on their systems to prove to themselves that this was a real threat. In doing so they may unknowingly have left a backdoor.
More commonly, proof-of-concept exploits posted on full-disclosure lists are crafted by security researchers, do not contain backdoors, and are relatively easy to read. In this case, the disclosed exploit is crafted by a hacker, may well contain a backdoor, and is written with leetspeak runtime messages and obfuscated code.
I admit I do not fully understand the code in the exploit or in the detection tool, or indeed the nature of the backdoor. However, on a Fedora 9 system, running the detector says there is no backdoor. After the exploit is run, the detector says there is a backdoor, so
the exploit must have changed the state of the system in some way. The detector looks for 3 separate backdoors; the one on my
test system disappears after reboot. As I thought the fix was to update the kernel to a patched version, which requires a reboot, I'm not sure how the backdoor could survive. I do not see how having the backdoor is riskier than having an unpatched system.
I can say, though, that the vulnerability exists in stock kernels 2.6.25 - 2.6.36, and was back-ported by RedHat into 2.6.18 used /proc.
in RHEL 5 (hence CENTOS 5). As stated by others, an unprivileged user account is required in order to exploit the vulnerability, which exists only on 64-bit x86 systems which also can run 32-bit code. One published mitigation step, which does not require a reboot, is to disable 32-bit compatibility mode by writing into
"You're probably being rooted as I type this. " .. Oh no a privledge escalation exploit...the world is doomed..ksplice save us.
If there is not going to even be the appearance of editorial integrity then what is the point?
I'm running the 32-bit flash plug-in on my 64-bit MythTV box, what is the problem?
The /. editors fall hook, line, and sinker for these advertisements for Ksplice submitted by an 'anonymous reader' every 6-8 weeks. Get used to them.
"What kind of music do pirates listen to?" -Paul Maud'dib
"Yeeeaaarrrrr n' Bee!!" -Stilgar, Leader of Sietch Tabr
In recent years, any mention of Linux reminded me of how religious leaders in some quarters address their Prophet - you know, "Mohammed, praise be on his name" or "Jesus Christ, blessed be thy name".
Maybe this will end the "Linux, it has no malware" illusion that many seems to have.
Entia non sunt multiplicanda praeter necessitatem.
Their diagnostic tool doesn't even work properly. Tried it on up-to-date Sabayon system and it failed.
Actually, the extra virtual memory space program-side is far more important than the extra physical memory space ever was. Typically, a 32-bit program is limited to 2GB of address space, including actually used ram, memory mapped files, reserved but unused pages (e.g. the stack growth area), memory mapped device memory (e.g. graphics mem) and the program and its dlls. Thanks to fragmentation of the address space by all of these, a program can fail to allocate memory without even getting close to 2GB of ram use. I could, as a proof of concept, write a program which will fail to allocate a 512MB block while only using kilobytes of ram, simply by requesting one 4kB memory page from every 512MB through the address space.
64-bit software resolves that problem (at least until we get programs trying to allocate exabytes of ram in one block)
Actually, the extra virtual memory space program-side is far more important than the extra physical memory space ever was. Typically, a 32-bit program is limited to 2GB of address space, including actually used ram, memory mapped files, reserved but unused pages (e.g. the stack growth area), memory mapped device memory (e.g. graphics mem) and the program and its dlls. Thanks to fragmentation of the address space by all of these, a program can fail to allocate memory without even getting close to 2GB of ram use. I could, as a proof of concept, write a program which will fail to allocate a 512MB block while only using kilobytes of ram, simply by requesting one 4kB memory page from every 512MB through the address space.
64-bit software resolves that problem (at least until we get programs trying to allocate exabytes of ram in one block)
Story sucks. Alarmist advertisement poop.
Dude! - I am SO going to root my very own computer!
..........FULL STOP.
Damn these kids and their acid. *squints his eyes*
Obviously both copied from SCO. Namely their 64 bit code.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Going to 64 bit means your instructions will be 64 bit, which means doubling the cache mem usuage.
Not true. x86 and x86_64 both use a variable-length instruction encoding. You actually get slightly better instruction density with x86_64, because a number of instructions that used to only work with eax now work with any target register, so for a couple of bits extra in the longer version of the instruction you avoid two register-to-register moves.
Pointers are 64-bit, but you'd need your program to consist entirely of pointers for this to double cache usage. In practice, you do see a small increase in data-cache usage, but it's offset by other things.
From performance point of view, if you don't really need 64 bits ( probably most of users will be fine with 4GB ram in next years) stay at 32 bits.
If we were talking about PowerPC or SPARC, you'd be (basically) correct. x86-64, however, is not just x86 with 64-bit pointers. It also gives you these other advantages:
I am TheRaven on Soylent News
Well, the last machines I picked up for free was an UltraSPARC. My local university computer society just got given an SGI machine with 16 MIPS64 chips. The computer labs are on a 3-year rolling upgrade cycle, and the machines that they threw out (into the arms of conveniently placed students) were all 64 bit. Low-end x86-64 machines are pretty easy to find these days.
I am TheRaven on Soylent News
I don't know how you got informative. Most 64 bit programs that use a reasonable amount of memory run slightly slower, due to increased memory bandwidth needs and cache effects. There is certainly no 20% boost to be had, as can be found by googling any 32 vs 64 bit benchmark.
I'm all in favor of x86_64, but as proven by one of dev blogs (no longer available) for a facebook-ish website using custom python code, it doesn't necessarily bring speedups/advantages everywhere. Their point was that python uses *a lot* of pointers. Tests showed, that even though switching to 64 bits brought some really minor improvements, it also brought much more memory usage to their servers, effectively worsening their performance. They've stayed with x86. They conducted tests some 2 or 3 years ago, I wonder what would be the result today?
Exactly. It is also good to mention other AMD64 goodnesses such as SSE extensions and the NX bit, which are nice additions to what x86 offers.
I think we'd all be interested to see where you came up with that 20%.
Obviously if your program just works on 64 bit floats or integers it will be faster, however doubling the bus width doesn't really make cache misses any faster. Sure you get a little more register space, but context switches still kill you. Pulling out a arbitrary percentage is like saying "for every core you add to an N core cpu, you should expect to see an N/2 percent speed up over a single core version."
My apologizes if that seems some what flamey, but it is just important to mention any potential speed ups are largely dependent on the specific workload at hand. Most programs don't see any speed up worth mentioning as they spend their life waiting for IO; the portion of their life doing actual work is nominal.
Uh, windows admins DO lash out at linux. The CEO calls Linux unamerican, GPL a cancer and insists that 237 patents (he's not going to tell you) are being infringed by linux.
And the fanbois lash out at linux when an exploit turns up just like linux fanbois do. There's more windows fanbois, though, so even that is not even handed.
Then there's the windows fanboi who ignores the fact of windows existence as a negative force, like you.
Uh....no
Since your pointers now doubled in size, the memory required to store them (cache them) has also doubled.
How expensive is a cache miss?
How expensive is it when you have to bring in twice as much data (for the double wide pointer)?
The extra registers don't buy you nearly as much as you think.
Modern out of order processors can hide the small register space with renaming. Furthermore, the spilling and filling out of 8 registers can be hidden by store->load forwarding logic.
Yet another problem coming from the programming language...I wonder when people will admit that the tools we are using for O/S development and systems programming are not good enough!!!
did anyone check the source code for that diagnose command?
static void put_your_hands_up_hooker(int argc, char *argv[])
WTF?
And as proof of concept, you are trying to seed the same comment randomly through the Slashdot "page" space ?
What exactly is the point of supplying a checksum by the same route/download method as the file in question? Surely if the file can be modified, so can the checksum. Maybe it would be useful if people got the checksum and verified it was the same checksum everyone else saw, then verified the file with it, but that just doesn't happen.
I posted the comment and it didn't show up. Looks like it did eventually.
"I'm not sure how the backdoor could survive"
Compromised GCC ?
"I do not see how having the backdoor is riskier than having an unpatched system."
Everyone on the planet accessing your machine vs local users ?
Damn man.. well written, reasoned- no raving-- that was a BEAUTIFUL POST until you ruined it by asserting something I knew flawed....
See, when I read an opinion piece, I can really get behind the authors point of view unless I see GLARING OBVIOUS MISTAKES... which ruin the emphasis of the entire rest of your post. I think, "if he's wrong about this basic FACT, how much can I trust his premise?"
What's my problem?
"OS-X is fine for general use, especially now that you can get Photoshop"
Photoshop-- is and has been the penultimate MAC app
Photoshop arguably MADE Macintosh what it is today....
in the 80's- financial sector used IBM PC compatibles,
and EVERY design shop/art whatever used macs and photoshop
every day http://en.wikipedia.org/wiki/Special:Random
While you do make a valid point (be careful about what you run) and I personally can't actually understand the code provided I have to say that sometimes you have to put a little trust in others. Do you inspect and thoroughly understand every update that your distro suggests? Considering the fact the tool is distributed through Ksplice's website, you have to be seriously paranoid to think Ksplice would even dare to do anything like that.
Perfect is the enemy of done.
And the disadvantage is that pointers take twice as much memory, and require structures to be 64-bit aligned, resulting in additional memory usage. This can result in non-trivial increase of memory usage and throughput, often severely reducing performance both from the extra bus pressure and earlier onset of paging, less IO caching.
Last time I checked most systems come with 4 GB RAM now. I just looked at a cheap (550 euro) Dell laptop that has 4 GB RAM. Personally I'm running 64 bit Linux because my system has 8 GB RAM (I needed to compile the OpenJDK a few times, and I decided that compiling to RAM disk was worth the additional 120 euro's or so - output is some 1.5 GB, excluding intermediate files).
While I certainly appreciate the effort, in the future please don't semi-obfuscate your publicly-released source code. That really doesn't give me the confidence that I need to run it on my machine.
I think if you're in a position where you apparently own Ksplice's servers, it'd be easy enough and far more damaging to quietly add a security hole to lots of systems using their patch infrastructure. Seems like a better attack vector than spreading an odd source file via a site full of distrustful/inquisitive geeks...
Switch back to Slashdot's D1 system.
Adobe released a new 64 bit Flash for Linux last week.
This certainly has to a highly unlikely series of typos. Let me fix that for you...
An anonymous reader writes
"Running 64-bit Windows? Haven't updated yet? You're probably being rooted (or pummeled with UAC requests) as I type this. WhosYourDaddyTrojan, this week's second high-profile local root exploit in the Windows kernel, is compromising machines left and right. Almost all 64-bit machines are affected, and 'Ac1db1tch3z' (classy) published code to let any local user get a root security wizard. Ac1db1tch3z's exploit is more malicious than usual because it leaves a backdoor behind for itself to exploit later even if the hole is patched. Unfortunately, there's isn't a tool you can run to see if you've already been exploited. Don't you wish you were running Linux, which has never had a single bug or exploit?"
I'm glad that I switched back to 32 bits two weeks ago, after 3 years of using 64 bits. I got tired of the Flash issues and a few other incompatibilities.
Worth noticing: .br web domains was showing that Ataturk protraits.
http://info.abril.com.br/noticias/internet/locaweb-sofre-ataque-cracker-17092010-33.shl
They just defaced every page in many compromised hosts.
Some said this exploit meant 30% of
Why haven't you upgraded to the recently-released 64-bit Flash yet? Is your distro that slow?
32-bit Windows had extra layers to support 16-bit binaries. So this kind of backwards compatibility is not a new idea, but it should not be needed in open source at all. I personally like having a clean system with a single architecture.
Escher was the first MC and Giger invented the HR department.
Going to 64 bit means your instructions will be 64 bit, which means doubling the cache mem usuage.
Depending on how the os/app uses the cache you may even find an slow down on performance.
AFAIK, cache is also used for data, and data is not doubled in size by the architecture change. But I agree that memory/cache usage is somewhat increased when going from 32 to 64 bits.
However, x86-64 has other improvements over 32-bit x86, so you often get a net speedup. Other posters have already mentioned extra registers and guaranteed SSE2.
In other architectures, such as PPC, there are none of these extra improvements. Thus many people choose to run a 32-bit userland on 64-bit PPC (usually with a 64-bit kernel).
Escher was the first MC and Giger invented the HR department.
Fairly badly written and mostly full of comments designed to blow smoke up his own arse.
This isn't a group of leet haxors, it's an undergrad trying to big up a RHEL kernel whole that I'm not sure will reliably work.
Worried? Moi? Bring it on kiddies.
Yep everything you say is correct.
But I do agree most people can live with 32 bit for now. For most users CPU performance isn't a bottleneck anymore.
For scientific users, gamers, video editors, and servers of all kinds 64 bit is the way to go.
Of course Microsoft in their wisdom decided to do one thing that drives me crazy with their 64bit OS.
WHY THE HECK DID YOU PUT 32 bit PROGRAMS IN Program Files(x86)!
You should have put the NEW 64 bit programs in the new directory and kept the older programs where they where for compatiblitly.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I actually tried to get some Atom/ION hardware from the UK because it hadn't made it to the US yet. Unfortunately, Amazon refused to ship that sort of thing to my location. A little later on, I nearly imported it myself from Japan because I was getting tired of waiting for the stuff to be finally here in America.
The US doesn't necessarily get the newest stuff first.
64-bit has been around for a VERY long time.
A Pirate and a Puritan look the same on a balance sheet.
Do you inspect and thoroughly understand every update that your distro suggests
Of course not. This is because it is considerably more difficult to compromise a distro's packet distribution system than it is to compromise or spoof a website. Tricking my browser should be even easier.
Things might have been different had I spotted any kind of digital signature (or even a checksum) anywhere near the download page, or if the download had even originated on a SSL verified server. This is very likely to be because of incompetence of the guys running the site, but on my list of reasons for adding things to the kernel, incompetence is not exactly on the top.
You have to rethink what it means to be "poor". I live in the US, work a full-time job in the IT industry, and I can't afford a hamster.
Plus you could run the 32-bit version of Flash on 64-bit Linux anyways, it's just more work:
http://www.linux.com/archive/feature/142075
And I haven't had any trouble running any other 32-bit binary blobs.
"When information is power, privacy is freedom" - Jah-Wren Ryel
I think if you're in a position where you apparently own Ksplice's servers, it'd be easy enough and far more damaging to quietly add a security hole to lots of systems using their patch infrastructure. Seems like a better attack vector than spreading an odd source file via a site full of distrustful/inquisitive geeks...
Unless they realized you think of that, and pulled a double-reverse psychological maneuver?
It's not a compatibility layer. It's that programs compiled against 32 bit shared libraries need those 32 bit shared libraries to run, and this is going to be difficult to get past, short of making everything a static binary.
The additional speed and such makes the small amount of additional complexity well worth the trouble.
And really, under Linux in 2010, you don't need 32 bit programs for anything except some commercial software where they don't offer 64 bit versions. (To be fair, the situation is the same under Windows, except that since you don't get source to everything, you're stuck with what they provide -- and it's usually a 32 bit binary.)
It's not a compatibility layer. It's that programs compiled against 32 bit shared libraries need those 32 bit shared libraries to run, and this is going to be difficult to get past, short of making everything a static binary.
True, it's not like emulating another architecture, because the CPU can run in different modes. But you still need some level of OS support for this mode switch.
I thought the case with 16-bit on 32-bit Windows was exactly the same, since the CPU can run in 16-bit mode as well. Or is there a key difference?
Escher was the first MC and Giger invented the HR department.
Try Ramen instead. It's not quite as satisfying, but it's cheap.
What is this... bullshit?
Those sort so shitty 'optimization' progs are for windoze fools..
my Ubuntu machines were already patched a day before the first scare stories about this exploit appeared here on Slashdot.
That's not a great measure of anything; Duke Nukem Forever was released last year, but /. is still posting stories about how it will never get produced.
/. is a little slow to pick up news at times.
Psych! DNF is still a leprechaun riding a unicorn. But
Here's a semi-deobfuscated version. My assembly skills aren't really up to snuff, so I doubt I'll go much further. http://gist.github.com/588199
Mod parent up
"You're probably being rooted as I type this"
don't you know what a LOCAL-root exploit is or are you by any chance trying to scare us into executing malware with root privileges?
The MAFIAA is a bunch of mindless jerks who will be the first up against the wall when the revolution comes
OMG, fucking is a myth?!
The tool isn't good for non-Redhat kernels. It checks for CVE-2010-3081 only, but not for CVE-2010-3080.
The latter wasn't "backported" to RHEL5, but is still wide open elsewhere:
$ ./diagnose-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)
$$$ Kernel release: 2.6.33.3
!!! Could not find symbol: per_cpu__current_task
A symbol required by the published exploit for CVE-2010-3081 is not
provided by your kernel. The exploit would not work on your system.
$ ./robert_you_suck
resolved symbol commit_creds to 0xffffffff81071b90
resolved symbol prepare_kernel_cred to 0xffffffff81071840
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
sh-3.2#
Yes, the initial problem was a real issue. But this one ONLY affects Ksplice users, because "th3 m4giq p0rt4l" left by Ac1db1tch3z's code resided in memory only. If, after updating, the one reboots like one is meant to, there is no problem. However, if the kernel is updated in memory while running (not a good idea in any case) as is done by Ksplice, the vulnerability remains. If one uses the "rebootless" patch after running Ac1db1tch3z's code, then you'll still have to reboot to fix the problem.
tl;dr Ksplice created a problem which only affects its own users and now slashdot is trying to convince us that it affects everyone. Story is moot.
They're only human, no need to call them tools.
Well, for one both the exploit and the detector are broken by default - it's looking for per_cpu__current_task for >=2.6.30 kernels and not every kernel has that - it's just 'current_task' on 2.6.36-rc4. Turn off that check and both the detector and exploit work. Ignoring the l33+, the important bits are the shellcode and any remnants of the exploit when run.
The exploit itself is trivial to understand - compat_alloc_user_space() didn't check the bounds, and one user didn't properly handle the checking first.
Here's the actual exploit:
getsockopt(7, SOL_IP, MCAST_MSFILTER, 0x804b4a0, 0x804b8a8) = -1 EFAULT (Bad address)
and a quick glance at net/compat.c shows that no check is made on optlen. The rest is just stack-trashing and shellcode,
your basic exploit.
The patched was announced by Canonical (Ubuntu) the same day that Ben Hawkes announced the exploit and published a proof of concept code.
The required kernel update is "2.6.32-24.43" or higher. That kernel was automatically updated on my 64bit Kubuntu 10.04 system with: /var/cache/apt/archives/linux-headers-2.6.32-24-generic_2.6.32-24.43_amd64.deb /var/cache/apt/archives/linux-headers-2.6.32-25-generic_2.6.32-25.44_amd64.deb
-rw-r--r-- 1 root root 757586 2010-09-17 10:04
and, 11 hour later, again:
-rw-r--r-- 1 root root 770132 2010-09-17 21:05
the same day that Hawkes announced it. Most 64bit Linux desktops are single user, and not susceptible if the owner did not hand out local accounts to his or her kids (and even then?), and most corporate Linux users would not advertize that their servers or workstations were exploited, so claims that Linux systems are being "compromised left and right" are spacious, to say the least, or FUD or outright lying at worst.
Running with Linux for over 20 years!
16-bit also had the annoyances involved with stepping out of protected mode on top of the bitness switch, which is why it was so easy to bring down the operating system form inside a poorly behaving program or shim driver.
CentOS 5 fixes are available - see http://bugs.centos.org/view.php?id=4518 Redhat 5 also has new kernel - see https://rhn.redhat.com/errata/RHSA-2010-0704.html GO GO GO !!!
Does anyone know if SELinux prevents this. I thought this was one of those things that falls on to SELinux will protect you unless you are using oracle or some other dumb program that makes it impossible to run SELinux correctly.
I'm a PC, and using Windows instead of Linux was my idea.
You are a PC??? Nice to meet you PC i am a human
Yes, but given their recent track record, I'm betting any money they'll do it again for quite a while. Besides, that version of flash completely messes up webkit if you are using qt4.6 (current in most distros) forcing either a non-package-manager upgrade to 4.7 (not easy on some distros) or not using the new flash.
Comparing to linux, windows are most vulnerable is the experience of the most of the administrators. But from knowledge point of view it also depends on who is administrating your system. The post is very well written and alarming for those who aren't up to date with administrating their systems. If you are looking for secured servers get it from unichost. For me they are most reliable so for !
Regards, Sam I Love My Reliable Service Provider Do you?
It is really a very very good article, GHD Hair Straighteners and CHI Flat Irons onlinestore - ghdhairsiron.com. Discount GHD Straighteners, CHI Hair Straighteners, CHI Nano Ceramic Flat Iron hot sale. Include CHI Original Flat Iron, CHI Earth Flat Iron, CHI Pink Dazzle Flat Iron, CHI Camo Flat Iron, CHI Classic Flat Iron, CHI Digital Flat Iron, CHI Guitar Flat Iron, CHI Turbo Flat Iron, CHI Wee Flat Iron, GHD Kiss Hair Straighteners, GHD Mini Hair Straighteners, GHD MK4 Hair Straighteners, GHD MK5 Hair Straighteners, GHD Precious Hair Straighteners, GHD Radiance Hair Straighteners, GHD Salon Hair Straighteners and GHD New Hair Straighteners - Choose Your Destiny - GHD Green Envy Hair Straighteners, GHD Blue Serenity Hair Straighteners, GHD Red Lust Hair Straighteners, GHD Purple Indulgence Hair Straighteners. We provide good service, our GHD IV Hair Straighteners, CHI Nano Flat Iron, CHI Ceramic Flat Iron free shipping and fast. Buy CHI Ceramic Flat Iron Original, CHI Ceramic Flat Iron Pink, CHI Ceramic Flat Iron Thermostat Blue, CHI Flat Iron Dazzle, CHI Flat Iron Pink Dazzle, CHI Digital Ceramic Flat Iron, CHI Ceramic Flat Iron Guitar, CHI Turbo Flat Iron 1", CHI Turbo Flat Iron 2",