RHEL's workaround [LWN.net]

RHEL's workaround

Posted Sep 17, 2010 19:14 UTC (Fri) by dowdle (subscriber, #659)
In reply to: RHEL by corbet
Parent article: Die-hard bug bytes Linux kernel for second time (Register)

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.

(Log in to post comments)

RHEL's workaround

Posted Sep 17, 2010 19:20 UTC (Fri) by drag (subscriber, #31333) [Link]

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.

RHEL's workaround

Posted Sep 17, 2010 19:27 UTC (Fri) by dowdle (subscriber, #659) [Link]

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

Posted Sep 17, 2010 23:31 UTC (Fri) by drag (subscriber, #31333) [Link]

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.

RHEL's workaround

Posted Sep 17, 2010 20:04 UTC (Fri) by jengelh (subscriber, #33263) [Link]

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

since some distros put baselibs into x86_64.

Workaround may not work?

Posted Sep 17, 2010 21:07 UTC (Fri) by dowdle (subscriber, #659) [Link]

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

Workaround may not work?

Posted Sep 18, 2010 16:39 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

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.

Workaround may not work?

Posted Sep 20, 2010 8:41 UTC (Mon) by vlima (subscriber, #4405) [Link]

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

Workaround may not work?

Posted Sep 23, 2010 10:15 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

That's the other bug.