hi, little correction ..
> - 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 ...
indeed it triggers twice,
because i've got different kernels (smp and none-smp-kernel) on the
machine ;-)
cheers,
martin
On Sat, 15 Aug 2009, Martin Flemming wrote:
> 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
>> __________________________________________________
>>
>
>
Gruss
Martin Flemming
______________________________________________________
Martin Flemming
DESY / IT office : Building 2b / 008a
Notkestr. 85 phone : 040 - 8998 - 4667
22603 Hamburg mail : [log in to unmask]
______________________________________________________
|
