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:5, Informative)
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.
Re:Perhap the kernel's size is becoming too unweil (Score:3, Informative)
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 ....
exploited (Score:1, Informative)
Patches are available (Score:3, Informative)
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.
Bit late to be news (Score:5, Informative)
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.
Re:Perhap the kernel's size is becoming too unweil (Score:4, Informative)
I've seen far too many rooted servers to agree with you about the deployment issue.
Re:Perhap the kernel's size is becoming too unweil (Score:4, Informative)
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.
Re:Why is there anything 32 bit on a 64 bit server (Score:3, Informative)
Everything else on there was compiled for 64 bit.
Re:Bit late to be news (Score:3, Informative)
Slackware forum [linuxquestions.org] has a link to the white hat's page [sota.gen.nz]. Here [sota.gen.nz] you can get a very neat proggy that will root you in less than 200 if you are still unpatched.
Gentoo Hardened nomultilib (Score:3, Informative)
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).
Re:But...but... (Score:4, Informative)
It's also part of the reason behind the slow turnaround time on patches coming out of Redmond. They do regression testing.
Re:Serve them right (Score:5, Informative)
It's quite possible to have two independent reasons for doing something.
Re:Confirmed (Score:2, Informative)
That's what you get for using Ubuntu on a server!
Immediate community action and timely patches?
If that's what we get, then thank you, Ubuntu.
Re:Why is there anything 32 bit on a 64 bit server (Score:4, Informative)
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 [linuxquestions.org], and the origina [sota.gen.nz] hack [sota.gen.nz].
Re:code comments? (Score:1, Informative)
Actually, the changed code is commented in the offending patch
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commit;h=d4d67150165df8bf1cc05e532f6efca96f907cab [kernel.org]
Thanks Redhat dude.
BTW, is it the norm for kernel developers to sign-off commits for their own patches? Maybe if someone else was responsible for reviewing and signing-off on the patch, this could have been caught ahead of time? Another person could have missed it too, but then again, maybe not.
Re:Doesn't work (Score:3, Informative)
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.
Re:Perhap the kernel's size is becoming too unweil (Score:3, Informative)
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?
Re:Perhap the kernel's size is becoming too unweil (Score:2, Informative)
in most reputable development firms... people would get fired over this.
Which dream world do you live in?
Re:Patches are available (Score:2, Informative)
Re:Doesn't work (Score:5, Informative)
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)
Re:Bit late to be news (Score:3, Informative)
RHEL was never affected. Red Hat BugID 630551 [redhat.com] states: /dev/sequencer device file is restricted to root access only."
"This issue did not affect the version of Linux kernel as shipped with Red Hat
Enterprise Linux 3, 4, and 5 as it did not include upstream commit 7034632d
that introduced the problem. It did not affect Red Hat Enterprise MRG as the
Further, Red Hat states for CVE-2010-3080 [redhat.com] that the commit upstream that brought the bug back was never allowed into Red Hat kernels:
"This issue did not affect the version of Linux kernel as shipped with Red Hat Enterprise Linux 3, 4, and 5 as it did not include upstream commit 7034632d that introduced the problem."
I guess you get what you pay for.
I'll be curious to see in the next few days if downstream from Red Hat followed Red Hat's same kernel compile options. Some prominent downstream versions would be CentOS and Oracle's OEL.
Re:Perhap the kernel's size is becoming too unweil (Score:3, Informative)
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.
Re:Serve them right (Score:2, Informative)
Re:Perhap the kernel's size is becoming too unweil (Score:3, Informative)
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.
Re:Perhap the kernel's size is becoming too unweil (Score:2, Informative)
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 [kernel.org]
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.
Re:Perhap the kernel's size is becoming too unweil (Score:3, Informative)
> 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.
Re:In Soviet Russia! (Score:3, Informative)
Unfortunately the Burroughs refused to run mainframe software with such bugs. Burroughs died.
IBMs ran such software without complaint. IBM survived.
Since the programs certainly had some design errors, it really becomes a question of which erroneous behaviors are silliest. Often the "most correct" are the silliest.
Re:Doesn't work (Score:3, Informative)
try for example "man su":
NAME
su - change user ID or become superuser
or sudo, but you'll have to all the way down to the description:
DESCRIPTION
sudo allows a permitted user to execute a command as the superuser or another user
Outside geek circles "root" doesn't mean anything, but superuser is at least somewhat meaningful. Though most don't actually deal with it at all anymore, they're in a sudo group so they only ever user their account and some applications ask them to reenter their password to become administrators. To most people "root" is more like "system" than "superuser" to most people these days.