Hole In Linux Kernel Provides Root Rights 274
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."
Re:Perhap the kernel's size is becoming too unweil (Score:1, Insightful)
So if you can't find any real reason why Linux is better, you just lie about the competition?
Re:Perhap the kernel's size is becoming too unweil (Score:3, Insightful)
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...
Re:Patch (Score:0, Insightful)
A piece of crap that's compatible with a rather wide variety of consumer software.
(Though I'll admit that I really don't use most of it.)
Re:But...but... (Score:4, Insightful)
Linux is better than Windows.
better != perfect
Re:Patch (Score:1, Insightful)
If I had mod points, I'd give this a Funny
Then again, I suppose the reason it's funny is because I administer quite a few Windows and Linux boxes, so I read quite a lot of sarcasm into this troll – "patching" Linux with Win7 is like shooting a radio to "fix" the crappy music coming out; come to think of it, that's giving way too much credit to Win7.
It's called humor, you should try it.
Re:Perhap the kernel's size is becoming too unweil (Score:2, Insightful)
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?
code comments? (Score:5, Insightful)
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
Re:Perhap the kernel's size is becoming too unweil (Score:2, Insightful)
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.......
Re:code comments? (Score:3, Insightful)
> and this, my friends, is why we add comments to our code
It's also a good argument for regression testing.
Re:Perhap the kernel's size is becoming too unweil (Score:4, Insightful)
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.
Re:Perhap the kernel's size is becoming too unweil (Score:3, Insightful)
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
Re:Perhap the kernel's size is becoming too unweil (Score:1, Insightful)
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.
Re:Unit Tests (Score:3, Insightful)
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).
Re:Unit Tests (Score:5, Insightful)
The test doesn't have to detect exploitability, only that the bug is still present (or not).
Errare Humanum est (Score:3, Insightful)
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.
Re:Why is there anything 32 bit on a 64 bit server (Score:2, Insightful)
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.
Re:Serve them right (Score:4, Insightful)
Linux is often the better choice for desktop usage when security is not an issue.
Security is *always* an issue. Especially on the desktop. One merely needs to look at the large botnets comprised entirely of zombie Windows machines to understand why.
Re:Perhap the kernel's size is becoming too unweil (Score:1, Insightful)
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.
Re:Perhap the kernel's size is becoming too unweil (Score:3, Insightful)
> 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.