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.
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.
protip: If you need markup to indicate your joke, you might be using a different definition of 'joke' to your readers.
I am TheRaven on Soylent News
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.
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.
better != perfect
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.
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...
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
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.
Classy.
Le français vous intéresse?
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
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
It's also part of the reason behind the slow turnaround time on patches coming out of Redmond. They do regression testing.
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.
Who the fuck calls that superuser?
All I had to do was turn around and reach at the bookshelf behind me:
"But we must warn you: there is a special user on every UNIX system, called the super-user, who can read or modify any file on the system. The special loginm name root carries super-user privledges...."
from page 52, "The UNIX Programming Environment", Brian W. Kernigan & Robert Pike, Prentice Hall, 1984.
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?
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.
cd /usr/src/linux &&
grep -ilE 'super.?user' `find . -iname *.[ch]`
arch/avr32/mm/cache.c
arch/h8300/include/asm/cachectl.h
arch/ia64/kernel/unaligned.c
arch/m68k/include/asm/cachectl.h
arch/m68k/kernel/sys_m68k.c
arch/parisc/hpux/sys_hpux.c
arch/x86/kernel/apm_32.c
arch/x86/kernel/ioport.c
drivers/char/apm-emulation.c
drivers/char/rio/errors.h
drivers/char/rio/rioctrl.c
drivers/net/wireless/airo.c
drivers/scsi/megaraid.c
drivers/scsi/megaraid/megaraid_mm.c
drivers/staging/vt6655/iwctl.c
drivers/staging/vt6656/iwctl.c
fs/cachefiles/daemon.c
fs/ext4/mballoc.c
fs/fcntl.c
fs/namei.c
fs/ntfs/super.c
fs/smbfs/file.c
fs/ubifs/budget.c
fs/ufs/ufs_fs.h
fs/unionfs/sioq.c
fs/utimes.c
fs/xfs/quota/xfs_qm.c
fs/xfs/quota/xfs_qm_syscalls.c
fs/xfs/xfs_quota.h
include/linux/acct.h
include/linux/dqblk_xfs.h
include/linux/fd.h
include/linux/keyboard.h
include/linux/random.h
include/linux/sched.h
include/linux/shm.h
include/net/sock.h
kernel/kexec.c
kernel/sys.c
kernel/sysctl.c
kernel/time/ntp.c
mm/mempolicy.c
mm/migrate.c
mm/oom_kill.c
net/core/dev.c
net/core/sock.c
net/netlink/af_netlink.c
net/netrom/af_netrom.c
(full disclosure: I also piped it thru |sed -e 's/^\.\///g' for formatting purposes (slashdot puts it all one one line if they begin with ./ for some reason) and |sort because I'm just like that)
The revolution will not be televised... but it will have a page on Wikipedia