fix for new elf loader bug?
Hi, is it safe to assume that Gregs patches.fixes/elf-coredump-fix one can find in the sles9-SP2 branch of the kotd is valid for the other SuSE kernels, too? It can be applied and according to Paul Starzetz description should suffice to fix the bug. cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Fri, May 13, 2005 at 11:20:20AM +0200, Frank Steiner wrote:
Hi,
is it safe to assume that Gregs patches.fixes/elf-coredump-fix one can find in the sles9-SP2 branch of the kotd is valid for the other SuSE kernels, too? It can be applied and according to Paul Starzetz description should suffice to fix the bug.
If it applies and builds correctly, yes. However, the full final approved fix for all the issues involved might be still pending. The fixes will of course be integrated into the other branches and released as security update within the next two or three weeks. Ciao, Marcus
Marcus Meissner wrote
If it applies and builds correctly, yes.
Ok, thanks!
However, the full final approved fix for all the issues involved might be still pending.
Yes, I'm aware of the difference of my self-patched kernel and an official SuSE release :-) No question that you do the more intensive and better testing! I just want a quick fix for now and don't mind to upgrade again after you've released the official update, possibly with more fixes. Thanks! cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
From: Frank Steiner [mailto:fsteiner-mail@bio.ifi.lmu.de]
Marcus Meissner wrote
If it applies and builds correctly, yes.
Ok, thanks!
However, the full final approved fix for all the issues involved might be still pending.
Yes, I'm aware of the difference of my self-patched kernel and an official SuSE release :-) No question that you do the more intensive and better testing! I just want a quick fix for now and don't mind to upgrade again after you've released the official update, possibly with more fixes.
An immediate hotfix that requires no patching or updates is to disable core dumps. As mentioned in http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt (This is from the guy who discovered this problem - see http://secunia.com/advisories/15341 ) "A hotfix for this vulnerability is to disallow processes to drop core. This can be accomplished by setting the hard core size limit for users to 0 (e.g. ulimit -H -c 0, man limits.conf)."
The Saturday 2005-05-14 at 17:24 +1200, Mike Tierney wrote:
"A hotfix for this vulnerability is to disallow processes to drop core. This can be accomplished by setting the hard core size limit for users to 0 (e.g. ulimit -H -c 0, man limits.conf)."
There is no "man limits.conf", in SuSE 9.3 at least. -- Cheers, Carlos Robinson
From: Carlos E. R. [mailto:robin1.listas@tiscali.es] The Saturday 2005-05-14 at 17:24 +1200, Mike Tierney wrote:
"A hotfix for this vulnerability is to disallow processes to drop core. This can be accomplished by setting the hard core size limit for users to 0 (e.g. ulimit -H -c 0, man limits.conf)."
There is no "man limits.conf", in SuSE 9.3 at least.
Hmm.... that man page must exist on some other version of Unix or maybe in a different Linux Distro. Under SuSE Linux it looks like "man bashbuiltins" is the place to look for info on the ulimit command. At least it is under SuSE SLES 9. Cheers Mike
The Tuesday 2005-05-17 at 09:25 +1200, Mike Tierney wrote:
There is no "man limits.conf", in SuSE 9.3 at least.
Hmm.... that man page must exist on some other version of Unix or maybe in a different Linux Distro.
The file is referenced in "/usr/share/doc/packages/pam/html/pam-6.html".
Under SuSE Linux it looks like "man bashbuiltins" is the place to look for info on the ulimit command. At least it is under SuSE SLES 9.
In SuSE linux, I understand it is read at login time, by "pam_limits", as set up in "/etc/pam.d/common-session": session required pam_limits.so -- Cheers, Carlos Robinson
On Monday 16 May 2005 4:55 am, Carlos E. R. wrote:
The Saturday 2005-05-14 at 17:24 +1200, Mike Tierney wrote:
"A hotfix for this vulnerability is to disallow processes to drop core. This can be accomplished by setting the hard core size limit for users to 0 (e.g. ulimit -H -c 0, man limits.conf)."
There is no "man limits.conf", in SuSE 9.3 at least.
It's at /etc/security/limits.conf Pretty well commented. Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-20a-default x86_64
The Monday 2005-05-16 at 17:59 -0700, Scott Leighton wrote:
There is no "man limits.conf", in SuSE 9.3 at least.
It's at /etc/security/limits.conf
Pretty well commented.
Comments in a configuration file are no substitute for a full blown man page. It will not respond to commands like "apropos limits", for example, and it is not organized as "documentation". Those comments do not mention when are the limits read and applied, for instance. It is documented instead in chapter 6.12 of the pam documentation, in pdf, html, or text formats. -- Cheers, Carlos Robinson
Mike Tierney wrote
An immediate hotfix that requires no patching or updates is to disable core dumps.
As mentioned in http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt (This is from the guy who discovered this problem - see http://secunia.com/advisories/15341 )
"A hotfix for this vulnerability is to disallow processes to drop core. This can be accomplished by setting the hard core size limit for users to 0 (e.g. ulimit -H -c 0, man limits.conf)."
But you can't do that in a running system. It won't affect running shells of normal users. So you need to reboot, and then you would need to reboot again to allow cores again. So it's easier to reboot only once with a patched kernel... -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
From: Frank Steiner [mailto:fsteiner-mail@bio.ifi.lmu.de]
Mike Tierney wrote
An immediate hotfix that requires no patching or updates is to disable core dumps.
As mentioned in http://www.isec.pl/vulnerabilities/isec-0023- coredump.txt (This is from the guy who discovered this problem - see http://secunia.com/advisories/15341 )
"A hotfix for this vulnerability is to disallow processes to drop core. This can be accomplished by setting the hard core size limit for users to 0 (e.g. ulimit -H -c 0, man limits.conf)."
But you can't do that in a running system. It won't affect running shells of normal users. So you need to reboot, and then you would need to reboot again to allow cores again. So it's easier to reboot only once with a patched kernel...
Well on Friday you did say "I just want a quick fix for now and don't mind to upgrade again after you've released the official update, possibly with more fixes." And given that there wasn't a SuSE patched kernel available, I gave you a "quick fix". The fact that it requires a small outage just means that it isn't the best solution for anyone running a 24x7 operation. However if a 10 minute outage decreases the chance you'll get hacked then you need to weight up the pro's and con's of doing this (or not). If you aren't in such a hurry then yes, wait for the official SuSE fix! :) This vulnerability is only a problem if someone actually gains local access to your system in the first place. Of course for all you know maybe someone has already hacked your application layer and is just waiting to use this new exploit to escalate themselves!
Mike Tierney wrote
"A hotfix for this vulnerability is to disallow processes to drop core. This can be accomplished by setting the hard core size limit for users to 0 (e.g. ulimit -H -c 0, man limits.conf)." But you can't do that in a running system. It won't affect running shells of normal users. So you need to reboot, and then you would need to reboot again to allow cores again. So it's easier to reboot only once with a patched kernel...
Well on Friday you did say "I just want a quick fix for now and don't mind to upgrade again after you've released the official update, possibly with more fixes."
Yes, you are right. But if the offical update does not contain more important fixes, I've one reboot less ;-) Anyway, thanks for caring! Don't take that wrong!
And given that there wasn't a SuSE patched kernel available, I gave you a "quick fix". The fact that it requires a small outage just means that it isn't the best solution for anyone running a 24x7 operation. However if a 10 minute outage decreases the chance you'll get hacked then you need to weight up the pro's and con's of doing this (or not).
Sure! The problem here is that we sth. like time windows in which we can reboot because we have processes running for weeks, doing important and uninterruptable computations. So if I have a chance to save one reboot, I try that :-) An inofficial kernel patch has a greater change for saving one reboot (hoping nothing else needs to be fixed).
This vulnerability is only a problem if someone actually gains local access to your system in the first place. Of course for all you know maybe someone has already hacked your application layer and is just waiting to use this new exploit to escalate themselves!
Right, I think that's the bigger problem. If e.g. apache has some new and easily exploitable flaw that is detected tomorrow, then the core problem suddenly is a remote exploit problem. cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
participants (5)
-
Carlos E. R. -
Frank Steiner -
Marcus Meissner -
Mike Tierney -
Scott Leighton