Die-hard bug bytes Linux kernel for second time (Register)
The oversight means that untrusted users with, say, limited SSH access have a trivial means to gain unfettered access to pretty much any 64-bit installation. Consider, too, that the bug has been allowed to fester in the kernel for years and was already fixed once before and we think a measured WTF is in order." It's worth noting that exploits for this vulnerability have been posted.
Posted Sep 17, 2010 18:32 UTC (Fri)
by dowdle (subscriber, #659)
[Link] (10 responses)
Posted Sep 17, 2010 18:49 UTC (Fri)
by corbet (editor, #1)
[Link] (9 responses)
Posted Sep 17, 2010 19:14 UTC (Fri)
by dowdle (subscriber, #659)
[Link] (8 responses)
echo ':32bits:M::\x7fELF\x01::/bin/echo:' > /proc/sys/fs/binfmt_misc/register
Here's how to find what 32-bit packages you have installed on an rpm-based system... for anyone who was curious:
rpm -qa --qf "%{n}.%{arch}\n" | grep -v x86_64 | grep -v none | grep -v noarch
That might not be very elegant but it works for me.
Posted Sep 17, 2010 19:20 UTC (Fri)
by drag (guest, #31333)
[Link] (2 responses)
Does this prevent anybody from copying a 32bit binary from to your machine via "wget http://blah/exploit" and then executing it?
Yeah sure maybe it's missing some critical lib somewhere, but that is not much of a step for a stepper.
Posted Sep 17, 2010 19:27 UTC (Fri)
by dowdle (subscriber, #659)
[Link] (1 responses)
Posted Sep 17, 2010 23:31 UTC (Fri)
by drag (guest, #31333)
[Link]
Posted Sep 17, 2010 20:04 UTC (Fri)
by jengelh (guest, #33263)
[Link]
Posted Sep 17, 2010 21:07 UTC (Fri)
by dowdle (subscriber, #659)
[Link] (3 responses)
http://www.h-online.com/open/news/forum/S-workaround-DOES...
Posted Sep 18, 2010 16:39 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
Posted Sep 20, 2010 8:41 UTC (Mon)
by vlima (guest, #4405)
[Link] (1 responses)
Posted Sep 23, 2010 10:15 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
Posted Sep 17, 2010 18:38 UTC (Fri)
by error27 (subscriber, #8346)
[Link]
Posted Sep 17, 2010 18:47 UTC (Fri)
by dowdle (subscriber, #659)
[Link] (1 responses)
Posted Sep 17, 2010 18:51 UTC (Fri)
by dowdle (subscriber, #659)
[Link]
Posted Sep 17, 2010 19:19 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (8 responses)
This way, any bugs on the emulation code would affect only the calling program, not the whole kernel.
Posted Sep 17, 2010 21:37 UTC (Fri)
by jreiser (subscriber, #11027)
[Link] (7 responses)
for the ones that call into the kernel directly, the kernel could redirect the call back to the C library emulation code Where would this C library emulation code reside? One of the reasons for running 32-bit code on a 64-bit machine is to get almost 4GB of usable user address space while using 32-bit pointers. It's already a significant problem that randomized placement of 32-bit VDSO linux-gate.so.1 fragments the address space. (If a process uses more than a few shared libraries then the probability of suffering performance loss due to randomized placement of VDSO is something like 5% to 30%: https://bugzilla.redhat.com/show_bug.cgi?id=162797#c4) Having the kernel put another VDSO into the address space [and glibc is a fat one at almost 1.5MB] would be even worse.
I care because I write program generators, such that the generated programs make "bare" syscalls without using glibc. The kernel should keep its code out of the user address space.
Posted Sep 17, 2010 22:49 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (6 responses)
If you are generating your own code which does not use the C library and calls the kernel directly, you could call the 64-bit syscalls directly like glibc would do. But programs which do not use glibc at all should not be that common, and initializing glibc would install the hook to intercept attempts at 32-bit system calls (which would work somewhat like a signal handler).
Yes, this idea implies always having the 32<->64 compat layer within glibc even on pure 32-bit systems (after all, one use case for that compat code is to run a pure 32-bit distribution with a 64-bit kernel).
Posted Sep 18, 2010 6:08 UTC (Sat)
by drag (guest, #31333)
[Link] (1 responses)
For example by using the various qemu-blah architectures it's possible to setup a chroot in your Debian system to execute programs and such. It's a nice feature when your doing cross architecture development.
But I don't see why you'd bother to go through all this trouble on x86-64 to run 32bit binaries because it already has excellent support. Just because the Linux sucks at security sometimes does not mean it's not a good approach.
Posted Sep 19, 2010 13:03 UTC (Sun)
by khim (subscriber, #9252)
[Link]
Well, if the capability is full of security holes it's not "excellent" by any stretch of imagination. On the other hand I think in few more years we'll be able to just disabled 32bit suppport (jut like iBCS was hot few years ago, but mostly is forgotten and broken today so will 32bit ABI) I don't see the need to introduce some crazy glibc-based emulation scheme now. Funny: when Flash death is wished for it's usually because it's full of security holes - and this is certainly good enough reason, but when 32bit emulation is concerned is not good enough reson? Sorry, but no. As this incidents shows current approach is really bad, but the trouble is: any replacement will need lots of work and will probably be too late to be actually usable. So we'll have this messy piece of code in our kernels for few more years...
Posted Sep 18, 2010 14:38 UTC (Sat)
by jreiser (subscriber, #11027)
[Link] (3 responses)
Posted Sep 19, 2010 13:20 UTC (Sun)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Sep 20, 2010 21:20 UTC (Mon)
by khim (subscriber, #9252)
[Link] (1 responses)
Already handled. Please read paragraph 6 and recall that FSF is very serious about copyright enforcement. Very, very, very few proprietary programs are linking GLibC statically. Sure they can bundle particular version of GLibC they like, but usually it's linked as shared library to make possible to use 6b option. So, no, in practice static linking is not a problem at all: even if GLibC is linked statically you must have a way to replace it.
Posted Sep 24, 2010 11:32 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Sep 17, 2010 19:42 UTC (Fri)
by nix (subscriber, #2304)
[Link] (4 responses)
He's been saying for years that ptrace() is almost unmaintainable: part of the point of the uprobes patches that the kernel hackers have been refusing to allow in for so long was to ditch a lot of this and replace it with something actually maintainable. So Roland can legitimately say 'nyah nyah I told you so' at this point. (But he won't because that would be nasty, and Roland doesn't do nasty.)
Posted Sep 18, 2010 15:21 UTC (Sat)
by jake (editor, #205)
[Link] (3 responses)
a minor nit, that's "utrace", not (the related but separate) uprobes, i believe.
jake
Posted Sep 19, 2010 13:05 UTC (Sun)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Sep 19, 2010 14:23 UTC (Sun)
by maney (subscriber, #12630)
[Link] (1 responses)
Demonstrating how easily even a careful, master LWN commentor can let a small mistake in. ;-)
Posted Sep 19, 2010 14:47 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Sep 20, 2010 11:13 UTC (Mon)
by dwmw2 (subscriber, #2063)
[Link]
The quote seems a little misleading. Although perhaps we could argue that pretty much every 64-bit Linux installation *is* x86_64 :)
Posted Sep 20, 2010 17:53 UTC (Mon)
by dv1m (guest, #58319)
[Link] (1 responses)
I thought this was about CVE-2010-3081, but this line is confusing:
"The Register reports on CVE-2010-3301, a local root vulnerability which has...."
And then user dowdle also used CVE-2010-3301.
Posted Sep 23, 2010 10:22 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
People keep insisting on talking about them as if they were one bug, e.g. proposing a workaround for bug A, then reporting it "doesn't work" because they tested an exploit for the bug B.
I don't really know what to say about that except, obviously you wouldn't want to employ any of these people in a capacity that required them to remember and distinguish things, so say, waiting at tables is right out.
Posted Sep 23, 2010 8:26 UTC (Thu)
by walles (guest, #954)
[Link] (1 responses)
This sounds like a good example of something that should have been caught automatically the second time it was introduced.
Posted Sep 23, 2010 15:52 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link]
Perhaps it's a good subject for a future LWN article ?
Die-hard bug bytes Linux kernel for second time (Register)
https://www.redhat.com/security/data/cve/CVE-2010-3301.html
There's a bit of confusion between the vulnerability described in the article and CVE-2010-3081 - at least I have been confused, though that happens frequently. Both were reported by Ben and involve similar mistakes. RHEL5 is vulnerable to this other bug, and exploits are in the wild.
RHEL
RHEL's workaround
RHEL's workaround
RHEL's workaround
RHEL's workaround
RHEL's workaround
rpm -qa --qf="%{ARCH}\t%{NAME}\n" | pcregrep '^i.86|-32bit'since some distros put baselibs into x86_64.
Workaround may not work?
Workaround may not work?
The robert_you_suck.c exploit found here still works as far as I can tell.
Workaround may not work?
Workaround may not work?
Ben Hawkes wrote up the vulnerability on his blog page 1 and page 2. (Really only page 2 is this bug but they're both related and interesting).
These bugs were found with a hand audit and so probably that's what we need to do more of.
Die-hard bug bytes Linux kernel for second time (Register)
Die-hard bug bytes Linux kernel for second time (Register)
http://lists.debian.org/debian-security/2010/09/msg00019....
Die-hard bug bytes Linux kernel for second time (Register)
Die-hard bug bytes Linux kernel for second time (Register)
Most well-written programs will do system calls via the C library The number of well-written programs is quite small. Perhaps you meant just "most programs".
user mode for 32-bit syscall emulation
user mode for 32-bit syscall emulation
user mode for 32-bit syscall emulation
This discussion is fast becoming moot anyway...
But I don't see why you'd bother to go through all this trouble on x86-64 to run 32bit binaries because it already has excellent support.
Just because the Linux sucks at security sometimes does not mean it's not a good approach.
But programs which do not use glibc at all should not be that common Program generators already have been used by hundreds of users to write thousands of programs that do not use glibc, and those programs have been distributed. Removing the ability for a 64-bit Linux kernel to handle a 32-bit system call would be a gigantic abandonment of the Linux ABI.
user mode for 32-bit syscall emulation
user mode for 32-bit syscall emulation
Sorry, but you are totally wrong.
How many such apps can you actually name?
Sure, static linking is horrible, but people *do* use it, so we have to cope...
How many such apps can you actually name?
Die-hard bug bytes Linux kernel for second time (Register)
Die-hard bug bytes Linux kernel for second time (Register)
> been refusing to allow in for so long
Die-hard bug bytes Linux kernel for second time (Register)
Oh yes, it got cut in two and renamed, didn't it?
Die-hard bug bytes Linux kernel for second time (Register)
Die-hard bug bytes Linux kernel for second time (Register)
"any 64-bit installation"?
Die-hard bug bytes Linux kernel for second time (Register)
Die-hard bug bytes Linux kernel for second time (Register)
Regression testing?
Regression testing?