| |||||||||||||
RHELRHELPosted Sep 17, 2010 18:49 UTC (Fri) by corbet (editor, #1)In reply to: Die-hard bug bytes Linux kernel for second time (Register) by dowdle Parent article: Die-hard bug bytes Linux kernel for second time (Register) 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.
(Log in to post comments)
RHEL's workaround Posted Sep 17, 2010 19:14 UTC (Fri) by dowdle (subscriber, #659) [Link]
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.
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.
|
|||||||||||||