RE: [suse-security] Bugs on Kernel 2.4
"M. Edwin" <edwin@nsi.co.id> wrote:
Dear all,
One of my friend here just told me that there are some weaknesses on kernel 2.4.0 to 2.5.69. He kows it after reading e-week report. It told that after several attack on Debian server, the researcher know that the weaknesses is come from the kernel.
I just curios is there any patch from suse about this matter?
Regards, M. Edwin
Hi Edwin, This is my take and not offical. However, a posting at Slashdot indicates that both SuSE and Redhat are working on it. http://developers.slashdot.org/developers/03/12/01/2133249.shtml?tid=106&tid... The "newest kernels" apparently have already solved the problem, so I expect that there will soon be a SuSE patch. Friendly greetings. Gar -- In the Beginning was the Command Line ---Neal Stephenson -- __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
Hi Edwin,
This is my take and not offical. However, a posting at Slashdot indicates that both SuSE and Redhat are working on it. http://developers.slashdot.org/developers/03/12/01/2133249.shtml?tid=106&tid... The "newest kernels" apparently have already solved the problem, so I expect that there will soon be a SuSE patch.
Exactly. The SUSE LINUX 9.0 kernel that is offered as "optional" in YOU fixes the problem. All other SUSE Linux releases will see update packages soon. Olaf Kirch is currently handling it. The kernel is a very critical component of the system. As such, it needs extensive testing - otherwise, we are confronted with some hundred thousand to millions of systems that can't boot any more. Please allow us to use some time for this testing effort. An easy workaround against the brk() issue: Set the address space limit to another value than nothing, even a very high value. Add the line ulimit -v 2147483647 as the second lines of /etc/init.d/rc and /etc/profile, execute the command itself in your shell and then restart all daemons that allow logins (xdm, sshd, inetd/xinetd, ...). Alternatively, simply reboot after adding the lines. (Courtesy of Solar Designer)
Friendly greetings. Gar
Thanks for summarizing. Roman. -- - - | Roman Drahtmüller <draht@suse.de> // Nail here | SUSE Linux AG - Security Phone: // for a new | Nürnberg, Germany +49-911-740530 // monitor! --> [x] | - -
Roman, I'm rather uneasy about the suggested workround because if you use that ulimit command it has no effect on the reported limit. e.g. $ ulimit -v 2147483647 $ ulimit -v unlimited After some experiments I found that 4194303 works and 4194304 does not. This corresponds to 4 GB which should be big enough for my purposes. Of course, it may be that the limit is being set correctly and reported wrongly but you can understand my concern. I have verified that if root sets its shell ulimit to 4194303 and restarts sshd then the new limit applies to new ssh sessions, which is good. I'm using SuSE 8.2. Bob On Tue, 2 Dec 2003, Roman Drahtmueller wrote:
Hi Edwin,
This is my take and not offical. However, a posting at Slashdot indicates that both SuSE and Redhat are working on it. http://developers.slashdot.org/developers/03/12/01/2133249.shtml?tid=106&tid... The "newest kernels" apparently have already solved the problem, so I expect that there will soon be a SuSE patch.
Exactly. The SUSE LINUX 9.0 kernel that is offered as "optional" in YOU fixes the problem. All other SUSE Linux releases will see update packages soon. Olaf Kirch is currently handling it.
The kernel is a very critical component of the system. As such, it needs extensive testing - otherwise, we are confronted with some hundred thousand to millions of systems that can't boot any more. Please allow us to use some time for this testing effort.
An easy workaround against the brk() issue: Set the address space limit to another value than nothing, even a very high value.
Add the line
ulimit -v 2147483647
as the second lines of /etc/init.d/rc and /etc/profile, execute the command itself in your shell and then restart all daemons that allow logins (xdm, sshd, inetd/xinetd, ...). Alternatively, simply reboot after adding the lines. (Courtesy of Solar Designer)
Friendly greetings. Gar
Thanks for summarizing.
Roman. -- - - | Roman Drahtmüller <draht@suse.de> // Nail here | SUSE Linux AG - Security Phone: // for a new | Nürnberg, Germany +49-911-740530 // monitor! --> [x] | - -
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
============================================================== Bob Vickers R.Vickers@cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv Phone: +44 1784 443691
Roman,
I'm rather uneasy about the suggested workround because if you use that ulimit command it has no effect on the reported limit. e.g.
$ ulimit -v 2147483647 $ ulimit -v unlimited
After some experiments I found that 4194303 works and 4194304 does not. This corresponds to 4 GB which should be big enough for my purposes.
I was stupid, the ulimit is given in kBytes in bash. :-( Sorry. 2097151 should be ok. That's 2GB-1kB.
Of course, it may be that the limit is being set correctly and reported wrongly but you can understand my concern.
I have verified that if root sets its shell ulimit to 4194303 and restarts sshd then the new limit applies to new ssh sessions, which is good.
I'm using SuSE 8.2.
Should be independent of what SUSE you use...
Bob
Thanks, Roman.
Roman,
I'm rather uneasy about the suggested workround because if you use that ulimit command it has no effect on the reported limit. e.g.
$ ulimit -v 2147483647 $ ulimit -v unlimited
After some experiments I found that 4194303 works and 4194304 does not. This corresponds to 4 GB which should be big enough for my purposes.
I was stupid, the ulimit is given in kBytes in bash. :-( Sorry. 2097151 should be ok. That's 2GB-1kB.
Of course, it may be that the limit is being set correctly and reported wrongly but you can understand my concern.
I have verified that if root sets its shell ulimit to 4194303 and restarts sshd then the new limit applies to new ssh sessions, which is good.
I'm using SuSE 8.2.
Should be independent of what SUSE you use...
Bob
Thanks, Roman. -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
participants (4)
-
Bob Vickers
-
Eusebio Manuel Giraldez Garcia
-
GarUlbricht7@netscape.net
-
Roman Drahtmueller