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 <[email protected]> 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 [email protected] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI LMSS Group
__________________________________________________
