Re: How to Install Wireless Adapter on Toshiba Laptop
On 14/08/2009, Eugene Shin interglob...@gmail.com wrote: After thoughts, I decided to manually download and install kmod-ath5k*rpm and kmod-mac80211*rpm. It seems that I made some progress in setting up network service in the end; the network adapter recognized the ath5k and wlan0 as a hardware and wireless adater respectively. But still I cannot activate the wireless adapter. Whenever I attempt to activate it, it says ath5k device wlan0 does not seem to be present, delaying initialization. Is this just a technical problem that I would be able to resolve soon, or did I make a fundamental mistake when I installed them? Eugene, As I do not use the package (I do not use any wireless connection), it is rather difficult for me to comment. However, from what you have written, it seems that you have correctly installed both packages (kmod-ath5k kmod-mac80211). I assume you appreciate that the correct kmod, matching both your architecture (32-bit or 64-bit) and your kernel type must be installed? There is one thing that would be nice to know -- the Vendor:Device ID paring for your wireless card. (FAQ #4 at http://elrepo.org/tiki/FAQ is appropriate.) If ath5k is the appropriate driver for the card, then I feel that your inability to connect is probably nothing more than a configuration issue. And that is something with which I will not be able to advise you . . . Hopefully somebody else will be able to assist. Alan.
kernel security
Hello SL Users, Is this an issue in SL, too? If yes, when will there be a new kernel? http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html Regards Marc
Re: kernel security
Hi, 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 Any other suggestions? Cheers, Urs Gasser Marc wrote: Hello SL Users, Is this an issue in SL, too? If yes, when will there be a new kernel? http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html Regards Marc
Re: kernel security
Urs Beyerle wrote: Hi, 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 at least on a SL5 system with mmap_min_addr support. Urs
Re: kernel security
On Fri, 2009-08-14 at 12:46 +0200, Urs Beyerle wrote: Urs Beyerle wrote: Hi, 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 at least on a SL5 system with mmap_min_addr support. I successfully rooted a 32bit SL5 system with SELinux enabled and vm.mmap_min_addr=64k with the public exploit :-( Working on a patched SL5 kernel. The fix from git is not applicable to the SL4 kernel (which is vulnerable as well). Any ides for a workaround? Urs -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany
Re: kernel security
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 stephan.wies...@desy.de 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 https://rhn.redhat.com/errata/RHSA-2009-1193.html ? Though I did see that there are other ways of bypassing vm.mmap_min_addr :-( -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge a.c.aitchi...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
Re: kernel security
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 stephan.wies...@desy.de 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 :-/ -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany
Re: kernel security
On Fri, 2009-08-14 at 13:28 +0200, Urs Beyerle wrote: Try unload and remove the following kernel modules: ipx.ko irda.ko x25.ko ax25.ko bluetooth.ko sctp.ko pppoe.ko pppox.ko Does this help? Yes it helps. It also helps (on SL5) to disable SELinux and reboot... Cheers, Stephan Urs 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 stephan.wies...@desy.de 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 :-/ -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany
kernel panic
I'd like to report a problem with 2.6.18-128.4.1.el5 x86_64 kernel running on SL 5.0 on laptop ASUS A6000KT: if I turn the power off -- it will trigger the kernel panic. Cheers Alex
Re: kernel security
Urs Beyerle wrote: Try to unload and remove the following kernel modules: ipx.ko irda.ko x25.ko ax25.ko bluetooth.ko sctp.ko pppoe.ko pppox.ko and appletalk.ko if you have it. Urs
Re: kernel security
Is this issue only exploitable locally, or can it be done remotely? Thanks - Original Message From: Urs Beyerle urs.beye...@env.ethz.ch To: Stephan Wiesand stephan.wies...@desy.de Cc: Dr Andrew C Aitchison a.c.aitchi...@dpmms.cam.ac.uk; scientific-linux-us...@fnal.gov scientific-linux-us...@fnal.gov; Gasser Marc marc.gas...@psi.ch Sent: Friday, 14 August, 2009 14:00:13 Subject: Re: kernel security Urs Beyerle wrote: Try to unload and remove the following kernel modules: ipx.ko irda.ko x25.ko ax25.ko bluetooth.ko sctp.ko pppoe.ko pppox.ko and appletalk.ko if you have it. Urs
Re: kernel panic
Alex Kruchkoff wrote: I'd like to report a problem with 2.6.18-128.4.1.el5 x86_64 kernel running on SL 5.0 on laptop ASUS A6000KT: if I turn the power off -- it will trigger the kernel panic. Cheers Alex What wireless driver does that laptop have? We've had problems with the altheros chipset, although in the past they just hung, and didn't panic, but I haven't tested them on the new kernel. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI LMSS Group __
Re: kernel security
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 stephan.wies...@desy.de 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
RE: kernel panic
Troy, It's kernel-module-ndiswrapper-2.6.18-128.4.1.el5-1.53-1.SL.x86_64, but I do not use wireless since SL4. Cheers Alex From: owner-scientific-linux-us...@listserv.fnal.gov [owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Troy Dawson [daw...@fnal.gov] Sent: Friday, 14 August 2009 23:32 To: Alex Kruchkoff Cc: scientific-linux-us...@fnal.gov Subject: Re: kernel panic Alex Kruchkoff wrote: I'd like to report a problem with 2.6.18-128.4.1.el5 x86_64 kernel running on SL 5.0 on laptop ASUS A6000KT: if I turn the power off -- it will trigger the kernel panic. Cheers Alex What wireless driver does that laptop have? We've had problems with the altheros chipset, although in the past they just hung, and didn't panic, but I haven't tested them on the new kernel. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI LMSS Group __
Re: kernel security
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 stephan.wies...@desy.de 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 daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI LMSS Group __
