Hi, Troy !

three little comments ...

- if i install the rpm,i've got 2 mails for each host, i think one is enough ... ;-)
( maybe something with the %triggerin option)

if i execute the script by hand, i've got only one ...

- the rpm sends  mails although everything is ok, is that wanted ?

- it's easier to have a overview, if the hostname is in the subject
   and  only for host with problems


cheers & thanks for all the work

 	martin

On Fri, 14 Aug 2009, Troy Dawson wrote:

> Hi Stephan,
> I took yours and changed a few times and made my own.  I haven't put it into 
> testing yet, but here is what I have.
>
> http: //home.fnal.gov/~dawson/test/SL_fix_bad_km.sh
> http: //home.fnal.gov/~dawson/test/SL_fix_bad_km-1.0-1.noarch.rpm
> http: //home.fnal.gov/~dawson/test/SL_fix_bad_km-1.0-1.src.rpm
>
> Basically it goes through a list of modules.
> If the module is already loaded,
>  it first tries to stop the service if it knows how (such as bluetooth and 
> irda)
>   If the modules is still loaded, it tries "modprobe -r"
>   If the module is still loaded it tried "rmmod"
>
> It then uses your find script, finds all the offending kernel modules, and 
> moves them to a safe directory.  We do this instead of just removing them.
>
> We have all the output going to an log file, and send a nice email, saying 
> what we did, to root.
>
> I'm sorry it's taken me so long to get this out, but there was various 
> testing and talking along the way.
> Troy
>
> Stephan Wiesand wrote:
>>  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
>
>
> -- 
> __________________________________________________
> Troy Dawson  [log in to unmask]  (630)840-6468
> Fermilab  ComputingDivision/LCSI/CSI LMSS Group
> __________________________________________________
>