LWN: Comments on "Die-hard bug bytes Linux kernel for second time (Register)"

How many such apps can you actually name?

nix — Fri, 24 Sep 2010 11:32:15 +0000

Hang on. "This technical problem is handled by making it illegal" is not a valid argument. People *do* link glibc statically, so a 'solution' that breaks that will break existing code. (In practice, this solution would never have any hope of being implemented anyway, because it would represent a gigantic kernel ABI break, which is one thing the kernel hackers very much dislike.)

Regression testing?

patrick_g — Thu, 23 Sep 2010 15:52:47 +0000

Well I know at least two projects : http://ltp.sourceforge.net/ and http://autotest.kernel.org/

Perhaps it's a good subject for a future LWN article ?

Die-hard bug bytes Linux kernel for second time (Register)

tialaramex — Thu, 23 Sep 2010 10:22:17 +0000

There are two bugs.

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.

Workaround may not work?

tialaramex — Thu, 23 Sep 2010 10:15:09 +0000

That's the other bug.

Regression testing?

walles — Thu, 23 Sep 2010 08:26:37 +0000

Does anybody know what kind of regression testing is performed on the kernel? Are regression tests written? Are they run?

This sounds like a good example of something that should have been caught automatically the second time it was introduced.

How many such apps can you actually name?

khim — Mon, 20 Sep 2010 21:20:12 +0000

Sorry, but you are totally wrong.

Sure, static linking is horrible, but people *do* use it, so we have to cope...

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.

Die-hard bug bytes Linux kernel for second time (Register)

dv1m — Mon, 20 Sep 2010 17:53:53 +0000

Confused by the CVE ID numbers:

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.

"any 64-bit installation"?

dwmw2 — Mon, 20 Sep 2010 11:13:17 +0000

Only x86_64, surely? This isn't a generic bug in the 32-bit compat layer on 64-bit kernels; it's in the low-level arch-specific syscall code.

The quote seems a little misleading. Although perhaps we could argue that pretty much every 64-bit Linux installation *is* x86_64 :)

Workaround may not work?

vlima — Mon, 20 Sep 2010 08:41:53 +0000

The robert_you_suck.c exploit found here still works as far as I can tell.

Die-hard bug bytes Linux kernel for second time (Register)

nix — Sun, 19 Sep 2010 14:47:20 +0000

I know my memory is appalling. That's why I spend half my time guarding against forgetfulness-inspired mistakes. It doesn't stop all of them, though, as this shows.

Die-hard bug bytes Linux kernel for second time (Register)

maney — Sun, 19 Sep 2010 14:23:33 +0000

Oh yes, it got cut in two and renamed, didn't it?

Demonstrating how easily even a careful, master LWN commentor can let a small mistake in. ;-)

user mode for 32-bit syscall emulation

nix — Sun, 19 Sep 2010 13:20:31 +0000

Plus, of course, a lot of apps (particularly proprietary ones and games) are statically linked to glibc, so from the POV of the OS 'do not use' glibc, at least not the magic future one here being discussed. Sure, static linking is horrible, but people *do* use it, so we have to cope...

Die-hard bug bytes Linux kernel for second time (Register)

nix — Sun, 19 Sep 2010 13:05:12 +0000

Oh yes, it got cut in two and renamed, didn't it?

This discussion is fast becoming moot anyway...

khim — Sun, 19 Sep 2010 13:03:24 +0000

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.

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.

Just because the Linux sucks at security sometimes does not mean it's not a good approach.

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...

Workaround may not work?

tialaramex — Sat, 18 Sep 2010 16:39:15 +0000

There is now a follow-up post from the same user in which they say they were testing some other exploit for some other bug.

Die-hard bug bytes Linux kernel for second time (Register)

jake — Sat, 18 Sep 2010 15:21:06 +0000

> part of the point of the uprobes patches that the kernel hackers have
> been refusing to allow in for so long

a minor nit, that's "utrace", not (the related but separate) uprobes, i believe.

jake

user mode for 32-bit syscall emulation

jreiser — Sat, 18 Sep 2010 14:38:53 +0000

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

drag — Sat, 18 Sep 2010 06:08:07 +0000

I know that it's possible to run foreign binaries on your system through virtualization.

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.

RHEL's workaround

drag — Fri, 17 Sep 2010 23:31:27 +0000

I suppose so. But I have not seen any negative impact in the past from it and I've been mixing 32bit userlands with 64bit kernels for ages; except from the security perspective.

user mode for 32-bit syscall emulation

cesarb — Fri, 17 Sep 2010 22:49:06 +0000

What I proposed depends on the 32-bit code being able to somehow do 64-bit syscalls, instead of doing a 32-bit syscall to be translated by the kernel (and in fact the kernel would not have any 32-bit syscall entry point at all).

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).

user mode for 32-bit syscall emulation

jreiser — Fri, 17 Sep 2010 21:37:35 +0000

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".

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.

Workaround may not work?

dowdle — Fri, 17 Sep 2010 21:07:39 +0000

According to this comment the workaround doesn't work. Can anyone else verify this?

http://www.h-online.com/open/news/forum/S-workaround-DOES...

RHEL's workaround

jengelh — Fri, 17 Sep 2010 20:04:11 +0000

rpm -qa --qf="%{ARCH}\t%{NAME}\n" | pcregrep '^i.86|-32bit'

since some distros put baselibs into x86_64.

Die-hard bug bytes Linux kernel for second time (Register)

nix — Fri, 17 Sep 2010 19:42:49 +0000

Notice that this bug was reintroduced by Roland McGrath. Roland is the original author and co-maintainer of glibc, and co-maintainer of the kernel's horrendously arcane ptrace code: if anyone can be said to be a careful programmer and master hacker it's Roland.

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.)

RHEL's workaround

dowdle — Fri, 17 Sep 2010 19:27:19 +0000

I wasn't saying that by removing 32-bit packages that users can't add their own. I was just thinking that if I didn't have any 32-bit apps on the system that I was using or that the system was using... that turning off the ability to run 32-bit apps as a temporary workaround for the bug shouldn't have much of a negative impact. Does that make good sense to you?

RHEL's workaround

drag — Fri, 17 Sep 2010 19:20:22 +0000

Are you sure that actually does anything for you?

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.

Die-hard bug bytes Linux kernel for second time (Register)

cesarb — Fri, 17 Sep 2010 19:19:43 +0000

Perhaps it would be a good idea to do all this compat handling in userspace, using a specially modified 32-bit glibc. Most well-written programs will do system calls via the C library, and for the ones that call into the kernel directly, the kernel could redirect the call back to the C library emulation code.

This way, any bugs on the emulation code would affect only the calling program, not the whole kernel.

RHEL's workaround

dowdle — Fri, 17 Sep 2010 19:14:12 +0000

Per that RH link Jon provided there is a workaround... that basically stops 32-bit binaries from being able to run. On almost all of my 64-bit systems I had previously removed all of the 32-bit packages... except for the single glibc.i686 so the fix should work for me.

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.

Die-hard bug bytes Linux kernel for second time (Register)

dowdle — Fri, 17 Sep 2010 18:51:18 +0000

See Jon's comment above... and the Debian kernel released today... that includes a fix for CVE-2010-3081 which seems to be the same thing or pretty darn close. So, Debian has updated the kernel.

RHEL

corbet — Fri, 17 Sep 2010 18:49:54 +0000

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.

Die-hard bug bytes Linux kernel for second time (Register)

dowdle — Fri, 17 Sep 2010 18:47:07 +0000

Also, it does not appear that Debian is affected either:
http://lists.debian.org/debian-security/2010/09/msg00019....

Die-hard bug bytes Linux kernel for second time (Register)

error27 — Fri, 17 Sep 2010 18:38:14 +0000

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)

dowdle — Fri, 17 Sep 2010 18:32:49 +0000

Please note that RHEL kernels are reported not affected:
https://www.redhat.com/security/data/cve/CVE-2010-3301.html