RE: [suse-security] SuSE Apache patch sufficient?
However, the exploit posted this morning on vulnwatch indicates that such an exploit exists against Linux.
Again: No, the exploit posted on vulnwatch this morning works agains xBSD only.
If you read the comments in the .c file, you will see their claim that they have exploited this under linux. Quoting below: * However, contrary to what ISS would have you believe, we have * successfully exploited this hole on the following operating systems: * * Sun Solaris 6-8 (sparc/x86) * FreeBSD 4.3-4.5 (x86) * OpenBSD 2.6-3.1 (x86) * Linux (GNU) 2.4 (x86) So either they are bluffing or the eploit does exist. I prefer not to assume the former. And I don't exactly consider these folks a trusted third party.
Again: No, the exploit posted on vulnwatch this morning works agains xBSD only.
If you read the comments in the .c file, you will see their claim that they have exploited this under linux. Quoting below:
* However, contrary to what ISS would have you believe, we have * successfully exploited this hole on the following operating systems: * * Sun Solaris 6-8 (sparc/x86) * FreeBSD 4.3-4.5 (x86) * OpenBSD 2.6-3.1 (x86) * Linux (GNU) 2.4 (x86)
So either they are bluffing or the eploit does exist. I prefer not to assume the former. And I don't exactly consider these folks a trusted third party.
Unless I see the exploit working, I don't believe it.
This, however, does not have any influence on the severity of the bug: a
_possible_ code execution vulnerability is just as bad as an evident code
execution vulnerability.
Roman.
--
- -
| Roman Drahtmüller
Hi, Roman Drahtmueller wrote:
Unless I see the exploit working, I don't believe it.
This, however, does not have any influence on the severity of the bug: a _possible_ code execution vulnerability is just as bad as an evident code execution vulnerability.
so, would it mean much work to compile RPMs for a 3.1.26 apache for all SuSE versions? Or are there just to many dependencies? For a quick fix I just compiled apache 3.1.26 using the config.status from SuSE and exhanged the binary and the modules, seems to run fine. However, I don't use much additional mod packages like php4 etc... cu, Frank -- Dipl.-Inform. Frank Steiner mailto:fst@informatik.uni-kiel.de Lehrstuhl f. Programmiersprachen mailto:fsteiner@web.de CAU Kiel, Olshausenstraße 40 Phone: +49 431 880-7265, Fax: -7613 D-24098 Kiel, Germany http://www.informatik.uni-kiel.de/~fst/
Hi Frank,
Unless I see the exploit working, I don't believe it.
This, however, does not have any influence on the severity of the bug: a _possible_ code execution vulnerability is just as bad as an evident code execution vulnerability.
so, would it mean much work to compile RPMs for a 3.1.26 apache for all SuSE versions? Or are there just to many dependencies? For a quick fix I just compiled apache 3.1.26 using the config.status from SuSE and exhanged the binary and the modules, seems to run fine. However, I don't use much additional mod packages like php4 etc...
I can promise you: It's a real mess!
No, I'm afraid we can't make a version upgrade. It will just break,
nothing else.
Sorry,
Roman.
--
- -
| Roman Drahtmüller
Roman Drahtmueller wrote:
I can promise you: It's a real mess! No, I'm afraid we can't make a version upgrade. It will just break, nothing else.
Ok, I understand that! In the meantime I read on the bugtraq that Linux seems not to be vulnerable in the way OpenBDS and FreeBSD are. So I guess, unless sth. else is proven, we can assume the patched Apache to be secure, right? http://online.securityfocus.com/archive/1/278223/2002-06-21/2002-06-27/2 Best regards, Frank -- Dipl.-Inform. Frank Steiner mailto:fst@informatik.uni-kiel.de Lehrstuhl f. Programmiersprachen mailto:fsteiner@web.de CAU Kiel, Olshausenstraße 40 Phone: +49 431 880-7265, Fax: -7613 D-24098 Kiel, Germany http://www.informatik.uni-kiel.de/~fst/
I can promise you: It's a real mess! No, I'm afraid we can't make a version upgrade. It will just break, nothing else.
Ok, I understand that! In the meantime I read on the bugtraq that Linux seems not to be vulnerable in the way OpenBDS and FreeBSD are. So I guess, unless sth. else is proven, we can assume the patched Apache to be secure, right?
Yes. I wouldn't insist on the claim that it isn't exploitable on Linux. This was only the first impression. It may turn out to be right - or wrong. Better upgrade the package.
http://online.securityfocus.com/archive/1/278223/2002-06-21/2002-06-27/2
Best regards, Frank
Roman.
--
- -
| Roman Drahtmüller
* Frank Steiner wrote on Fri, Jun 21, 2002 at 10:21 +0200:
so, would it mean much work to compile RPMs for a 3.1.26 apache for all SuSE versions? Or are there just to many dependencies?
I think the main problem would be the (probably) changed behavior of apache and/or it's mod_packages. If someone uses i.e. mod_php and upgraded a larger site, she would know what I mean. In such upgrades, you can have i.e. a function does something different (nothing special in PHP's history :)). Well, after upgrade, some functions of some scripts are broken... Hope you'll enjoy debugging :) Well, and the new PHP version usually require the very newest pre-alpha anything libs...
For a quick fix I just compiled apache 3.1.26 using the config.status from SuSE and exhanged the binary and the modules, seems to run fine.
Well, usually that works if you have a not too old installation, and you compiled the binaries on a very similar system. But if you make a binary RPM after i.e. upgrading a used package, you would need this upgrade package on the RPM targets, too...
However, I don't use much additional mod packages like php4
Yes, I wouldn't do also, but I don't think that SuSE could ommit it :) And the millions of functions of the millions of modules cannot be tested... Well, and usually i.e. new mod_php's don't work with older apache's and so on... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
We've run this code against a few GNU/Linux servers running Apache versions prior to the fix... In all cases it caused Apache children processes to seg fault. In no cases was any exploit code executed, or parent processes killed.
If you read the comments in the .c file, you will see their claim that they have exploited this under linux. Quoting below: * However, contrary to what ISS would have you believe, we have * successfully exploited this hole on the following operating systems: * Linux (GNU) 2.4 (x86) So either they are bluffing or the eploit does exist. I prefer not to assume the former. And I don't exactly consider these folks a trusted third party. -- James Ogley, Unix Systems Administrator, Pinnacle Insurance Plc james.ogley@pinnacle.co.uk www.pinnacle.co.uk +44 (0) 20 8731 3619 Using Free Software since 1994, running GNU/Linux (SuSE 8.0) Updated GNOME RPMs for SuSE Linux: www.usr-local-bin.org
********************************************************************** CONFIDENTIALITY.This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose, or store or copy the information in any medium. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Pinnacle Insurance plc. If you have received this email in error please immediately notify the Pinnacle Helpdesk on +44 (0) 20 8207 9555. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************
----- Original Message -----
From: "Alan Rouse"
If you read the comments in the .c file, you will see their claim that they have exploited this under linux. ... So either they are bluffing or the eploit does exist. I prefer not to assume the former. And I don't exactly consider these folks a trusted third party.
you're right - this also confused me. I guess they are bluffing... So I tried it against different systems and it did'nt work. I tested it against - Debian 2.2 with apache 1.3.24 - Mandrake 7.2 with apache 1.3.20 - SuSE 8.0 with apache 1.3.23 none of them were exploitable - all of them have 1.3.26 now. cheers, Andreas
you're right - this also confused me. I guess they are bluffing... So I tried it against different systems and it did'nt work. I tested it against - Debian 2.2 with apache 1.3.24 - Mandrake 7.2 with apache 1.3.20 - SuSE 8.0 with apache 1.3.23
.... We've run this code against a few GNU/Linux servers running Apache versions prior to the fix...
In all cases it caused Apache children processes to seg fault.
In no cases was any exploit code executed, or parent processes killed.
Read the comments again, this exploit only claims to work on OpenBSD: * Remote OpenBSD/Apache exploit for the "chunking" vulnerability. Kudos to * the OpenBSD developers (Theo, DugSong, jnathan, *@#!w00w00, ...) and * their crappy memcpy implementation that makes this 32-bit impossibility * very easy to accomplish. This vulnerability was recently rediscovered by a slew * of researchers. Apparently this also relies on kernel problems, so you'd need the right shellcode for a Linux exploit. --Jeremy
participants (7)
-
Alan Rouse -
Andreas Syska -
Frank Steiner -
James Ogley -
Jeremy Buchmann -
Roman Drahtmueller -
Steffen Dettmer