Here's a stab at an SL_rpm to help mitigate the issue for the time
being:

http://www-zeuthen.desy.de/~wiesand/ww/

It will remove(!) the suspicious modules for all kernels on the system,
even those installed later on. It then checks whether one of them is
loaded, and sends mail to root if it is.

Use at your own risk! Any bugs in the script, and this could irreparably
damage your OS installation. Comments very welcome.

- Stephan


On Fri, 2009-08-14 at 15:40 +0200, Matthias Schroeder wrote:
> Troy Dawson wrote:
> > Stephan Wiesand wrote:
> >> On Fri, 2009-08-14 at 11:59 +0100, Dr Andrew C Aitchison wrote:
> >>> On Fri, 14 Aug 2009, Urs Beyerle wrote:
> >>>> I guess SL is affected like most other Linux distributions.
> >>>>
> >>>> I'm not 100% sure, but setting vm.mmap_min_addr to a value above 0
> >>>> should prevent an exploit.
> >>>>
> >>>> # sysctl vm.mmap_min_addr=4096
> >>> The default on my SL53 machines appears to be 65536
> >>> so there may be no need to do this.
> >>>
> >>> And Stephan Wiesand <[log in to unmask]> replied:
> >>>> I successfully rooted a 32bit SL5 system with SELinux enabled
> >>>> and vm.mmap_min_addr=64k with the public exploit :-(
> >>> Did this machine have kernel-2.6.18-128.4.1.el5 and hence the 
> >>> fix for CVE-2009-1895 which allows a user to bypass mmap_min_addr - see
> >> Yes.
> >>
> >>> https://rhn.redhat.com/errata/RHSA-2009-1193.html  ? 
> >>> Though I did see that there are other ways of bypassing
> >>> vm.mmap_min_addr :-(
> >> Yes, and they work fine :-/
> >>
> > 
> > Has anyone with a TAM with RedHat reported this to them yet?
> 
> You mean
> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-2692, right?
> 
> 
> > I'm pretty sure someone has, I just want to verify and get a bug 
> > tracking number.
> 
> There is also an IT, you should be able to see it.
> 
> Matthias
> 
> > 
> > Troy
-- 
Stephan Wiesand
  DESY - DV -
  Platanenallee 6
  15738 Zeuthen, Germany