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