Slashdot Mirror
Hole In Linux Kernel Provides Root Rights
oztiks writes with this excerpt from The H:
"A vulnerability in the 32-bit compatibility mode of the current Linux kernel (and previous versions) for 64-bit systems can be exploited to escalate privileges. For instance, attackers can break into a system and exploit a hole in the web server to get complete root (also known as superuser) rights or permissions for a victim's system. According to a report, the problem occurs because the 32-bit call emulation layer does not check whether the call is truly in the Syscall table. Ben Hawkes, who discovered the problem, says the vulnerability can be exploited to execute arbitrary code with kernel rights. ... Hawkes says the vulnerability was discovered and remedied back in 2007, but at some point in 2008 kernel developers apparently removed the patch, reintroducing the vulnerability. The older exploit apparently only needed slight modifications to work with the new hole."
That's why those of us in the know stick to 8-bit Linux kernal.
I mean this is what, the third 'reverted' security patch we've heard about in the recent past that needed replacement?
Maybe it's time to seperate out core kernel code and the arch specific stuff into seperate modules with seperate administration. Git would make this easy, so why aren't we seeing it done?
For those who compile from source, here is the patch:
---kernel.c
+++kernel.c
@@ -1,1 +1,1 @@
- void goatse(long cx) {
+ void goatse(int cx) {
The change from long to int closes the massive hole.
You're talking about git submodules and I'm gonna go ahead and guess that the answer you'll receive from the kernel folks about that is a big fat "no". Maybe if Git had usable project hierarchies, things might be different.
Also to note: even Git can't fix stupid policy or stupid programming decisions.
Linux Kernel used to have hole that provided root rights.
For instance, attackers can break into a system and exploit a hole in the web server to get complete root (also known as superuser) rights or permissions for a victim's system.
Something must be wrong with my Linux - this "superuser" account doesn't appear to exist.
$ su - superuser
su: user superuser does not exist
$
#DeleteChrome
I mean this is what, the third 'reverted' security patch we've heard about in the recent past that needed replacement?
In other news, direct from Windows Update: "A security issue has been identified that could allow an authenticated remote attacker to compromise your system and gain control over it." x10 "A security issue has been identified that could allow an unauthenticated remote attacker to compromise your system and gain control over it." x5 and other misc. vulnerabilities =)
So if you can't find any real reason why Linux is better, you just lie about the competition?
He is probably referring to the bout of security fixes for windows 7 with the same wording.. there has been quite a few of them lately.
Just confirmed it on my ubuntu 10.04 server.
And that has to do with linux?... Oh thats right nothing.
Pointing at what other people are doing wrong so you can look better makes you look like an ass in the long run. People notice it. Stop doing it and worry about what you are doing...
Root escalation is a serious issue but instead of figuring out 'hey how can we stop this from happening again' you are busy saying 'look see teh windowz sux'.
uh ok...
He is probably referring to the bout of security fixes for windows 7 with the same wording.. there has been quite a few of them lately.
And that's relevant to this thread how again?
Might as well start posting stuff about Chewbacca.
Maybe Linux' kernel is too big?
Chewbacca lives on Endor wihout any Linux or Windows computers ....
RIP America
July 4, 1776 - September 11, 2001
Root is a privilege, not a right.
You can get a patch here.
Linux sucks, but it's okay because Windows sucks too? Great reasoning. I look forward to using it to convince people to switch.
I am TheRaven on Soylent News
I'm just guessing here but someone (not me) may have used it already. Travelnotes has been rooted.
If you know how to drive git you could try applying these:
x86-64, compat: Retruncate rax after ia32 syscall entry tracing
x86-64, compat: Test %rax for the syscall number, not %eax
there is a workaround of disabling 32bit binaries (I'd paste a link if Google Chrome dev channel would let me... for some reason I can only paste into /.'s comment box before I've typed anything else, I'll follow-up with it), but of course you may need them depending on what your machine does.
There's also a separate issue that also gives local root, fixed by:
compat: Make compat_alloc_user_space() incorporate the access_ok()
I'm running a kernel base don 2.6.35.4 but with all 3 of those commits applied (note the last one tries to modify an arch/tile/ file which doesn't exist in 2.6.35.4, just ignore that) and can confirm that neither exploit works.
I'm not sure, but I think they have BSD machines on Endor. And, yes, a few Apples - they also have a few elitests who admire bling above all else.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
You're talking about git submodules and I'm gonna go ahead and guess that the answer you'll receive from the kernel folks about that is a big fat "no". Maybe if Git had usable project hierarchies, things might be different.
Also to note: even Git can't fix stupid policy or stupid programming decisions.
If ever there was a case of missing the forest for the trees, it's this right here.
No, Linux sucks, but it sucks a lot less than Windows. I mean, the "fix" is already out. My update reminder has been sitting in the taskbar ever since I woke up. Every time my mouse rolls over my autohidden taskbar, I get a flash of red to remind me about the kernel update. I've ignored it, because the exploits are simply not deployed. Unlike Windows, where there are thousands of exploits deployed, some of them sitting on servers waiting for the opportunity to do a "drive by" installation. When it is convenient for me to do so, I'll download the update, and apply it.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Linux is better than Windows.
Oh.
Wait.
Stuff is, what it is.
The fix was out before the maintainers rolled it back, too. Whoops.
Maybe it's time to write unit tests for the kernel.
Okay, I get that when system calls are made to 32 bit whatever, bad things could happen. But why would there be anything 32 bit there at all? Shouldn't everything that is running on a server be compiled for 64 bit? I gotta say, this is a good reason to hate 32 bit binary blobs being distributed by vendors who don't want to release the source for their drivers and what-not... well more than I already do.
Perhaps I am misunderstanding something and that 32 bit calls are still an inherent part of 64 bit Linux? I've been running 64 bit for years and years and now I wonder if I'd be better off running 32 bit?
Ubuntu, at least, has already released the patch as a kernel upgrade; it was fixed early in the week so I presume most other distros have too.
Unless you need the big address space and MOST apps don't - 32 bit code runs faster.
Since when?
64-bit code gives you twice as many registers at the cost of doubling the size of pointers, and on older Intel CPUs losing some of the microop fusion optimisations. Every time I've seen people post comparative benchmarks of their 32-bit code recompiled to 64-bit, they've shown significant speedups.
I always like it when other programmers complain they can't do something because of a programs behavior, gives me this warm fuzzy feeling.
A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
Okay, I get that when system calls are made to 32 bit whatever, bad things could happen. But why would there be anything 32 bit there at all? Shouldn't everything that is running on a server be compiled for 64 bit?
Flash. Ubuntu handles 32-bit Flash integration automatically with 64-bit Firefox, but on some other distros it's easier just to install 32-bit Firefox instead.
Flash and Java are almost necessities on many servers. Sun Java and Adobe Flash have lacked 64 bit support, so 32 bit versions were mandatory. Or, nearly mandatory. There are options to Sun and Adobe, but performance isn't exactly the same. (Not saying better or worse, just different, which can be a problem in and of itself) When Adobe and Oracle both get around to releasing a consumer grade, final version of these ubiquitous applications, then Linux and Windows will both probably drop 32 bit compatibility as "default" installation options.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Not interesting enough. Rewriting something that already works is where it's at.
Unfortunately, it's often prohibitive for you to fix every other piece of software out there that doesn't work the way you want it to, especially when it's quite enough just to deal with your own software.
Because it's spelled separate, not "seperate".
I don't have to keep entering my password for sudo access anymore!
Meh. Do you make your living from convincing people to switch from Windows to Linux? Does it really matter to you what other people use? As far as I'm concerned, Linux just needs to suck less than Windows, which it does. As long as that remains true, I won't have to worry about the hassle of considering migrating everything I do to Windows.
I've seen far too many rooted servers to agree with you about the deployment issue.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Also, since the kernel is fairly 'well documented', we should be able to tell WHO is responsible for removing the patch, and reintroducing the vulnerability.
Perhaps, we could ask them why such a thing happened, and whether the linux community needs to backtrack this specific dev/s, kernel patching to date.
You want to talk about 'quality control' in the open source world, here it is right in front of us. Will it be done properly and thoroughly?
Java may be, but flash?
Yea, because one bitch on slashdot spending 2 minutes writing such a post is really detracting from figuring out "hey how can we stop this from happening again"
I'm pretty sure the people that actually matter won't be found on slashdot poking fun at everyone else.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
On a largely Linux-focues tech news site you just defined 'root'. Why not also define '32-bit compatibility mode', 'Linux', 'kernel', '64-bit', 'privileges', 'web server', 'call', 'emulation layer', 'Syscall table'.
Protip: We're nerds. Write for your audience. If I don't understand a term, I can look it up. I'd prefer to have to do that than have random definitions stuck in the summary.
Hawkes says the vulnerability was discovered and remedied back in 2007, but at some point in 2008 kernel developers apparently removed the patch, reintroducing the vulnerability
and this, my friends, is why we add comments to our code
Yeah... at this point i'm wondering if there are some kernel developers who like there to be security bugs in the kernel?
Why else would they revert the security patch? Polticial reasons? They don't like the fix?
Or perhaps some of the kernel developers a black hats working covertly, and the 'fixes' cause them problems exploiting their secret bugs.......
no, it does not run faster, all things being equal. 64 bit compiled code runs 20-25% faster. no I'm not counting specially optimized code that's heavy on SSE and f riends. yes, it does use more ram and disk space.
> Why else would they revert the security patch?
Because they made a mistake. People do that.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
A LOT of hosts still get rooted because of weak passwords. A LOT of valuable hosts get rooted through social engineering. Just because you've seen rooted hosts, doesn't mean that there is any wide-scale deployment of anything.
If you're using your Linux server to browse Flash apps on the web, you might be doing it wrong...
Le français vous intéresse?
If you're using your Linux server to browse Flash apps on the web, you might be doing it wrong...
Yeah, I missed the 'server' part :).
I've got some very expensive commercial software on my nodes which is produced by utter idiots that have put 32bit binaries in directories called "linux64". They've been migrating their stuff from 32bit to 64bit since 2003 so they'll get there eventually. Until then it's a mixed system with a lot of undocumented messing about to install their software.
Everything else on there was compiled for 64 bit.
And that, my friends, is why a microkernel is better than a monolithic kernel.
Do they have code reviews in Open Source land? We sure as hell do in boring business software world. Tends to catch shit like this.
You're talking about git submodules and I'm gonna go ahead and guess that the answer you'll receive from the kernel folks about that is a big fat "no". Maybe if Git had usable project hierarchies, things might be different.
Also to note: even Git can't fix stupid policy or stupid programming decisions.
If ever there was a case of missing the forest for the trees, it's this right here.
Its a bug tracking issue, not a a version control issue.
http://michaelsmith.id.au
is Ric Romero writing about security now?
--
Stay tuned for some shock and awe coming right up after this messages!
Agreed
"What luck for the rulers that men do not think." - Adolph Hitler
Another issue I see commonly is. Linux is complicated and user unfriendly --> Admin doesn't have perfect settings --> abusable security flaw.
1 reverted security patch is a mistake.
2 reverted security patches is a major mistake
3 unintentionally reverted critical patches in 6 months is a pattern of major fuck-ups.
I'm not saying people don't make mistakes. Part of the purpose of version control is to prevent such accidental reversions.
A pattern of reverting security changes, and not detecting those reversions before the software goes to world-wide release is pretty inexcusable, in most reputable development firms... people would get fired over this.
I suppose an interesting characteristic of the OSS development module is you can't fire people for screwing up, because they're not paid in the first place, they can follow slipshod practices as much as they like, with 'accidental' reversions or other changes all over the place
When I worked at a web hosting company, we once had a customer call in to complain that javascript and flash weren't running on our servers. Of course, they aren't supposed to....
makes one wonder what the money gets used for.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
I won't dispute the value of code reviews, but something much simpler should have detected a reverted security patch.
A simple test suite ought to detect code reversions.
Just make it policy to write a thorough 'test' for any security or other critical bug is discovered. The test should be thorough and designed to detect the bug, cause the kernel to crash, or panic, if any known bug is still present.
Then simply require the test suite to be run against the binary and all tests pass before a new kernel can be released.
Virtualization or running the kernel in user mode (as un User-Mode linux) could be utilized to facilitate testing.
Sun Java and Adobe Flash have lacked 64 bit support, so 32 bit versions were mandatory.
The Sun JVM has been available in a 64-bit version for years. Even the browser plugin is available in a 64 bit version now.
You and I have been looking at vastly different sets of benchmarks.
Some go better at 64 bit. Many others do worse.
Well, vast majority of pwned Windows boxes end up that way due to operator error, not some code exploit - you know, users clicking on boobies!.jpg.exe links in mails and such. It's not something you can truly fix, short of making an iPad.
Many others not optimized for 64 bit. Sorry but a change in compiler isn't enough to be declared optimized. 64bit being slower than 32bit was disproven years ago... it's a myth that won't die.
Amirite?
News like this makes me smile that I decided to use Gentoo Hardened 64-bit nomultilib whenever I built servers. Makes it harder if the software needed to run is only available as 32-bit binaries, but I haven't run into any yet that I've needed.
Since it has no 32-bit emulation layer, this is probably one of the few 64-bit linux not affected (without a patch).
Marketing and Sales.
Chewbacca lives on Endor wihout any Linux or Windows computers ....
They use Force computers.
Chewbacca lives on Endor wihout any Linux or Windows computers ....
Lies, deceit! Wookies come from Kashyyyk. :)
Man blir trött av att gå och göra ingenting.
Its a bug tracking issue, not a a version control issue.
Indeed, and the 'bug' in this instance appears to be someone on the team who retracted the fix.
The version control system should make it possible to figure out who that was. Especially because, it seems, the version control system was not part of the problem.
Or are the dudes in the bazaar all wearing gray robes? Hopefully kernel development isn't "A maze of twisty little passages, all alike"
Linux just sucks differently from Windows. It isn't purely a matter of degree.
Much the same as the BSDs suck differently from Windows or Linux.
Life is filled with trade-offs. But it's more fun to engage in zealotry than it is to acknowledge that and move on. So we have the usual chest thumping we see here.
User IDs in decentralised version control system are under the control of the comitter. Linus pulls patches from a team of patch maintainers who should always be able to account for the veracity of the meta data in their repos.
http://michaelsmith.id.au
The vulnerability is affecting kernels compiled with 32-bit compatibility support. Enabling this option seems to be the default, even on x64 systems that do not have 32-bit libraries and cannot execute 32-bit binaries. You can say
zcat /proc/config.gz | grep CONFIG_IA32_EMULATION
to see if you have it on. More info, and the origina hack.
In theory, you can write a unit test to cover anything and everything you want. In practicality, the amount of code to perform expansive unit tests quickly dwarfs the amount of code in the product you are testing.
Like the summary said, the old attack didn't work exactly, it had to be tweaked slightly. Even if you had a unit test for this situation, it most likely would have passed (meaning the test exploit would fail).
The original security exploit had to be modified to exploit the current kernel, so unless you expect them to maintain all the old security vulnerability test units....
Simple fact, stuff happens. I would like to see a programmer / admin that can say in the last 6 months they have not made or almost made a major to semi-major mistake. Linux is a big project and they are reacting properly to this by re-adding the fix quickly.
The test doesn't have to detect exploitability, only that the bug is still present (or not).
The offending patch was authored and committed by a Redhat developer. Since this guy made his own company's product insecure for their clients, I'd say that Redhat could very well fire him. Whether they will or not depends on the company. Besides, do you know of a Microsoft (or any closed source software company) employee being fired based on their coding vulnerable software? How about a CEO being fired for selling vulnerable software to the public? Where's the accountability there?
Perchance the Linux vulnerability patch committing folk should start peppering their patches with comments containing BIG FAT WARNINGs of the outcome if their patch is optimized away by some eager beaver wannabe super kernel dev.
Vulnerability re-exposing patches would thus be much more likely to ring the patch reviewers bells.
You want to talk about 'quality control' in the open source world, here it is right in front of us. Will it be done properly and thoroughly?
You mean by ridiculing the person who made a mistake in front of the whole world? Patch your own fucking kernel if you're so damn smart.
The fact that because we can't fire developers makes it an incentive to bad coding practices is not an argument:
for some people (esp. Linux developers where pride is an important fuel to their creativity), being pointed out in public by such bad behavior is much worse than being fired in the equivalent closed software company.
Moreover, you will never know how many developers in a closed model had turned a simple patch into a remote exploit and if the culprit was really fired afterward esp. if it's a core developer (the one that knows everything and that you can't fire).
I think I can remember at least one Windows bug few years ago that was very much like another that was closed but there are some many 0-day and remote exploits that is becomes difficult to keep track.
Its a bug tracking issue, not a a version control issue.
No, it's a software complexity issue. The problem is, with the size of the kernel, it would be prohibitively expensive to write and run tests even just for the major bugs fixed.
"The older exploit apparently only needed slight modifications to work with the new hole." That's what she said.
"I have never let my schooling interfere with my education." --Mark Twain
Reported by Tavis Ormandy, biggest asshole on the planet.
Comment removed based on user account deletion
I will not have you talking about C3PO that way!
No, Linux sucks, but it sucks a lot less than Windows. I mean, the "fix" is already out.
This severe issue has been there for 2 years now, and "a fix is already out"?
I see the standards you hold Linux to are high.
I live with feet in both sides, and I can tell you, Open Source generally does much (100x) better than closed source. Especially in companies that need to release product or die. Hey, that's about every commercial company I know....
C3PO? That must be why I was modded "troll". I wasn't referring to the midget droid - he wouldn't be caught dead using BSD or Apple!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Most of the ones I've seen (that we can trace back to the intrusion point) are the fault of bad PHP code, honestly. Still.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
All 64-bit systems from Intel and AMD also come with some level of SSE. It comes along the address space "for free" because it became a standard feature by the time 64-bit machines came around. GCC, by default takes advantage of SSE when you target x86_64.
Many distributions do not enable stuff like SSE when compiling 32-bit packages. It wasn't there for i386 or i586. Whats more is the same 32-bit packages built for the all 32-bit installs are used to provide the 32-bit land on 64-bit systems. I tried some time ago to make a 32-bit program preform just as fast as the 64-bit program. No matter what flags I threw at the compiler the 32-bit version always lagged behind the 64-bit version because the 32-bit user space wasn't optimized to take advantage of newer processor features. In short I would have had to recompile all of 32-bit land to match performances.
I've yet to encounter a situation where 64-bit builds were slower. It is at least no worse, and often better. In my experience switching to a 64-bit system is about more than just address space. I'm sure you could build a 32-bit system to preform nearly as well... but really what's the point?
I may not need the extra address space, but it certainly doesn't seem to hurt me any. Given the tag-along-extras I get with it... seems like a good deal to me.
in most reputable development firms... people would get fired over this.
Which dream world do you live in?
The address space is needed since the total virtual addressible space needs to be divided among things like the hardware, kernel and user space. You already see this when you have 4GB of memory on a 32-bit Intel system and the hardware consumes 1GB of memory for it's addressing. Windows further splits the space into 2GB for kernel/hardware and user space. So no application can every address more than 2GB of memory (paged or physical combined) and the kernel shares the other 2GB with the 1GB of hardware addressing (leaving 1GB for it's own).
On 64-bit the addressible space is larger and the hardware address ranges can be located anywhere withing the massive amount (like 128TB) of virtual address space. So the 1GB of hardware address ranges don't have to fit in the 4GB of address space that the physical memory uses, and you can access the full 4GB of memory.
amd64 has many more registers and a better instruction set than i386 so it should execute both 32 and 64-bit code as fast if not faster than 32-bit systems. The performance gain might not be massive if software is not geared for the newer opcodes or registers, but by all rights there is no reason that the 64-bit code should run slower than 32-bit code.
You don't allocate memory or disk space in blocks of 32 or 64 bits so the savings are not affected by the larger size of the addressible bits. If you allocate a page of memory in Windows the memory manager allocates (IIRC) 64K of storage for the page regardless of the smallest addressible unit size. The extra 32-bits used to store an integer would be insignificant in the overall 64K of page space.
The clash of honour calls, to stand when others fall.
It's too bad most closed-source software that people actually buy shrink-wrapped is sold by software product sales companies rather than actual software development companies.
Hell, some of my CE equipment needs reboots because of software bugs or insufficient cooling considerations in the design. People who put out products to make a profit are not generally engineering things to public safety standards or business-critical standards. Most are selling consumer-grade hardware and software at as low a cost per unit as they can without completely losing the market.
I've seen far too many servers configured improperly or using simple/short/common root passwords to agree with you about the deployment issues being responsible for a random sample of rooted servers.
Okay, so I was misunderstanding. Very interesting indeed. I expect an extremely swift round of patches for all of my OSes shortly. I don't believe any distro will sit on their hands over this one.
As far as "/proc/config.gz" goes, I don't have one. Is there another way that Fedora puts this information out?
I've seen far too many servers configured improperly or using simple/short/common root passwords to agree with you about the deployment issues being responsible for a random sample of rooted servers.
Not to mention admins who will enter passwords using an unsecure workstation to access something else remotely, admins who use the same password everywhere, admins who routinely login to unencrypted protocols, etc.
Around 15% to 25% of revenues going to customer acquisition and retention (marketing, sales calls, rebates, incentives, whatever) is a pretty common budgetary decision in US businesses. So yeah, after payroll, facilities, and other operating costs marketing and sales are a major expense. The most common advice I get as a small-business owner both online and in person from other business owners is 20%.
I've heard as low as 10%, but that's still a big chunk of the budget. I've also heard of people spending as high as 40% of revenues for a short period when entering a new market segment.
It's informative to stick "how much to spend on marketing" into a search engine and see what the different magazines, forums, and blogs say. Different industries of course have slightly different needs, but at least 10% and not more than 30% under normal circumstances should be a decent starting place for considering what to spend.
Yeah but none of those exploits is in the Windows 7 kernel itself (which is rarely ever patched). They'll all be related to other components distributed with the operating system. This could be many things including Windows Media Player and IIS. If you want to compare the number of Linux patches with Windows Updates you would need to compare the Windows patches to the patches of s Linux distro not just the Linux kernel itself.
The clash of honour calls, to stand when others fall.
Isn't Git Linus' software?
I'm sorry, but as a Linux guy, it's really hard to watch a Windows guy get a chuckle at somebody else given their chosen OS's inferiority and not have a chuckle about it myself.
Get your Unix fortune now!
Ksplice.
, one ... Bingo.
Aaaah, the beauty of open source at work. Doesn't that just feel good?
Linux does still suck in a few ways (My Ubuntu still can't handle playing sound from Firefox/Flash and Rythmbox at the same time - quite unbelievable, yes, I know) but you have to hand it to the Kernel teams all over the world: when it comes to finding, announcing and fixing critical bugs, nothing beats the Linux crew.
Go, Kernel team, go!
We suffer more in our imagination than in reality. - Seneca
Bad PHP on it's own should not on it's own cause the system to be rooted. If it does you have other problems (be they admin stupidity or local root exploits like this one).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
According to this comment, RHEL wasn't affected. So a Redhat developer committed a patch that made everybody else look worse. Maybe he got a raise.
I don't believe ridicule was mentioned.
Anyway, no matter how painful it might be for the person who reverted the patch, the issue does need to be investigated in order to find out how to detect other instances and how to stop it from happening again.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
A 2 year old bug reappeared, you mean, but this wouldn't give you the opportunity to smear linux, would it...
You'd need all the software for windows too because there's a hell of a lot more than there is on the Windows install disk, even with the crapware that Dell et al bundle on there.
You'd have to include all the dev tools for Windows, all the compilers for windows and all the MS software (including stuff for Win3.11 where it still runs on the current system) and THEN you get somewhat of a parity.
In trying to even up the software count, you have made it worse, just the other way.
PS According to Microsoft, most of those programs are an inherent and necessary part of the OS therefore from MS's own attribution are more like the Linux Kernel than the distribution.
Pointer size is not a bottleneck in properly written code. If your data structures contain more pointers than data, they either need redesigning or are used in a context where performance is not an issue.
Sun Java and Adobe Flash have lacked 64 bit support
eh?
sun has had 64 bit binaries for linux as long as i can remember, at least since 1.4.x, and i'd take a loose bet they had 1.3.x 64 bit packages too. ( any earlier and you'd be stretching to find a 64 bit intel/amd linux distro...)
the java runtime itself has been natively 64 bits for a long time.
you _may_ be getting confused with the horrendous java applet plugin for _browsers_ which i think has only recently been part of the distributed java bundles.
correcting my own presumptions,
seems java 5 was the first 64 bit sun distribution for linux.
takes a while to get there, but you can still click round the oracle java sites and find the binaries..
http://java.sun.com/javase/downloads/jdk/142/
http://java.sun.com/javase/downloads/5u22/jdk
for the impatient
still, java 5 released sept 29 2004, so i guess i'm stretching to remember installs from 6 years ago
The patch mentioned in TFA does not fix the bug. The patches at the bottom of http://sota.gen.nz/compat2 are the correct ones.
And then other kernel teams go and break it again later. Yaaay Linux!
In practicality, the amount of code to perform expansive unit tests quickly dwarfs the amount of code in the product you are testing.
Obviously you write only these that cover some important bugs/functionality. Privilege escalation bug is enough justification.
Like the summary said, the old attack didn't work exactly, it had to be tweaked slightly. Even if you had a unit test for this situation, it most likely would have passed (meaning the test exploit would fail).
That would be true if you wrote a test for the full exploit which is *not* a unit test. A unit test would cover the source of the bug (as opposed to its consequences), that is, ensuring top half of %rax is zero when looking up the syscall table (or just ensuring that %rax is always < nr_syscalls). That sort of test would catch the regression.
Actually, I think it's a code quality issue.
Look at http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commitdiff;h=d4d67150165df8bf1cc05e532f6efca96f907cab
It seems to me that the critical line of code reloading EAX was deleted because the committer couldn't see why it was necessary, and there was no comment in the code to explain its purpose. With no comment, and no unit test to guard against regressions (and I recognise that isn't always practical), this was an accident waiting to happen.
Lies, deceit! Wookies come from Kashyyyk. :)
Exactly. Why would a Wookiee, an eight-foot tall Wookiee, want to live on Endor, with a bunch of two-foot tall Ewoks? That does not make sense!
No, it's a software complexity issue. The problem is, with the size of the kernel, it would be prohibitively expensive to write and run tests even just for the major bugs fixed.
So much for open source.
Maybe it's time to revive the split between stable and unstable, and vetting of all changes going from unstable to stable. Yes, it means a slower release pace, but the number of regressions and plain broken things (IMA, bootmem disabling, now this) having made it into production kernels lately is rather frightening.
Perhaps it's time to declare the new model a success, and move on back to the old model, so problems can be given enough time to be discovered in unstable, and either fixed, or not brought over to stable.
It hasn't been for a while. He did start it, but he hasn't done most of the work.
It's true that you can say that the current software isn't good enough and write your own. Sometimes you have enough resources and time to do that. And if so, good for you. But many times you don't. And while Linus started Git to have a good VCS for Linux, he didn't write his own compiler for Linux, or his own text editor that is custom-tuned for Linux, or even his own build system. Kbuild still uses make at the core. All of those other parts have their problems and warts and it'd be absurd to expect Linus and co. to write their own versions of all of them just so they can make the software exactly like they want it. We have a term for that kind of behavior: NIH syndrome and most folks consider it to be a bad thing.
> So if you can't find any real reason why Linux is better, you just lie about the competition?
Lying simply isn't necessary.
Windows is in the habit of running untrusted binaries often without knowledge or permission of the user.
THIS aspect of WinDOS makes it far more vulnerable than anything else to any sort of problem that starts out as a local root exploit.
A Pirate and a Puritan look the same on a balance sheet.
But unfortunately, fixes only come out for a few "active" branches. This is a problem for those who have to stay at a specific kernel level (like embedded, where there's little chance of getting all the special device support ported over to a new version in any sensible time frame, or systems certified for a specific use, and where changing the kernel level would mean a full recertification). So in many cases, it's a "fix it yourself".
The problem with the Linux kernel now, as I see it, is that the progression is too rapid, and even "long term stable" branches are EOLed too quickly. I'd like to see "long term stable" have a life span of at least 5 years, and preferably 10.
I mean, RHEL is still on 2.6.18, but the oldest long term stable is 2.6.27, and it's already being replaced by 2.6.32. So unless you have a vendor like Red Hat that can backport for you, or the manpower and time to do it yourself, you're pretty much screwed. And you start to look elsewhere.
First of all, there is no such things as a security patch in the Linux kernel. A patch is a patch, and all flaws are flaws. The fact that, on the phenomenally rare occasion that something likes this happens, it is so rare and unusual as to inspire conspiracy theories, goes to show just how truly solid the Linux kernel and it's development model truly is.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
> Well, vast majority of pwned Windows boxes end up that way due to
> operator error, not some code exploit - you know, users clicking
> on boobies!.jpg.exe links in mails and such. It's not something
> you can truly fix, short of making an iPad.
Nonsense. You can make it a little harder for end users to do stupid things when prompted by a website.
Talk about "moving goalposts".
NO ONE using ANY OS should ever have to worry about the act of loading data causing malware to run instead.
This is just retarded and should have been stopped a long time ago.
A Pirate and a Puritan look the same on a balance sheet.
I was unaware that Microsoft doesn't have code reviews.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Possibly in /boot/config-<version>.
But I'll save you the trouble and just tell you that every x86_64 binary kernel image I've ever seen has 32-bit emulation enabled by default. Unless you've compiled the kernel yourself and explicitly disabled 32-bit emulation (like I have on a Gentoo system I run), it's got about a 99% chance of being on.
You are at least partly right - but I think that you are at least partly wrong too. Sure, there are people who, for one reason or another, have to keep an old version of the kernel. However - they can always recompile the kernel with a specific patch. Since this particular exploit is a regression to a two year old kernel, I suspect that *nearly everyone* has the opportunity to patch their kernel. I can't possibly know this, but I suspect that the very people who have opted to retain an old kernel are the very people who are most capable of patching their own kernels. I mean - they have very specific reasons for not upgrading, and they must understand the kernel to some extent to have made their decisions. Alright - maybe I'm talking out my ass. Does anyone else have any better insight to this?
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Don't fucking explain to me what "root" means. That's just insulting.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Unless you turned off most of the hardening features of the Gentoo Hardened kernel, it was protected all along. See
http://bugs.gentoo.org/show_bug.cgi?id=326885#c10
Looking at the bug, it really looks like something simple to test automatically.
I'm just wondering whether anybody is running any kind of unit-tests or regression tests on the Linux kernel?
The unit test doesn't have to exploit. It just has to cause a crash if the root cause bug still exists. The maintenance on this test shouldn't be so bad; the test would probably be much simpler than the exploit and likely never really needed any maintenance to speak of.
And yes, I do expect old security vulnerability test units to be maintained. That's what is done in the proprietary world and in some other big FOSS projects, and until this discussion I simply assumed it was happening in the Linux kernel. I get that total test-driven-development has a scalability problem once you get to something of this size, but elevation of privileges exploits are a narrow enough and important enough subset that they should have tests. So I would second the recommendation that, going forward, that all new Linux security fixes be coupled with a simple unit test that exposes the issue, and that is run before future kernel point releases. Maybe not necessarily on the same day, but if a security patch is submitted there should also be a bug of highest priority to write a matching test, and if it isn't fixed within a relatively short period there should be a good justification (eg. "issue requires 47 days to reproduce -- unit testing is impractical").
Yeah circle those wagons! I'm sure Linux will be better off in the long run, that way!
Nonsense. You can make it a little harder for end users to do stupid things when prompted by a website.
Sure you can. You can make more prompts - to which they will promptly agree. You can disable running from browser (as Chrome does), but then the page providing the link will also provide steps to run outside browser, and enough people will do that.
Simply put, so long as you give your users the ability to shoot themselves in the foot, they will do so if someone manages to convince them to - and, as history shown, it's not hard at all. The only fix is to take away the ability to shoot oneself entirely, and that is the point at which you get an iPad - an "appliance".
Why does the server even have X installed, much less flash?
Well, they could have annotated it and gone back to the commit. Seems pretty brave to take out a block of assembler like that without checking.
http://michaelsmith.id.au
Its a bug tracking issue, not a a version control issue.
No, it's a software complexity issue. The problem is, with the size of the kernel, it would be prohibitively expensive to write and run tests even just for the major bugs fixed.
Maybe Andrew Tanenbaum can interest Linus Torvalds in that modular kernel he has been working on.
http://michaelsmith.id.au
It's worth giving atvice to those with sense
And, for that matter, why do you assume that zcat is gzip in disguise? Those who run posix compliant systems have a different zcat that doesn't do .gz files, and (sometimes) a gzcat that does gzip files. Try "gzip -dc" instead -- it has a greater chance of succeeding outside your own system.
This is only relevant to linux, so it's perfectly reasonable to assume the system is linux. Those foolish enough to cripple their system for the sake of following the posix standard probably wouldn't listen to any advice anyway.
I am trolling
That's not an unreasonable thing to do on, say, a server dedicated to running one application as fast as possible. (Or you could install a distribution that optimises for modern processors). If it gives a substantial performance advantage over 64-bit (and the grandparent seemed to think it does; the only way to tell is to actually benchmark your real application) then it would be worth it.
I am trolling
I thought the linux guys were always on top of their game, especially with all the source code documentation and the code repositories...
this is one of those things that should never happen....but we are human i guess, i thought only M$ had the corner stone on these sort of mistakes.
on it's own
"its".