Apache is lek!

[jep]

http://httpd.apache.org/info/security_bulletin_20020617.txt

Hoe erg 't precies is zullen we zien, maar houd 't in ieder geval even in de gaten .

[jep]

Al heb ik 't idee dat security.nl dit als gewoonlijk weer op loopt te blazen.

[Verwijderd]

Als je het goed leest is apache op windows lek, niet degene op linux en andere *nixen..

[jep]

Oh?

Vooral windows, niet alleen windows. Wat er precies op welk ssyteem niet goed is, weten ze alleen nog niet.

[Mark]

Probleem is al sinds 28-5-2002 bekend (zie CAN nummer op mitre.org).
Het lijkt een serieus probleem, want de CAN staat op resevered. Dit betekend dat er geen informatie word verstrekt (eventuele links naar proof of concept/bugtraq) om zo misbruik te voorkomen.

[Mark]

Op maandag 17 juni 2002 23:36 schreef jep het volgende:
Oh?

Vooral windows, niet alleen windows. Wat er precies op welk ssyteem niet goed is, weten ze alleen nog niet.

In Apache 1.3 the issue causes a stack overflow. Due to the nature of the
overflow on 32-bit Unix platforms this will cause a segmentation violation
and the child will terminate. However on 64-bit platforms the overflow
can be controlled and so for platforms that store return addresses on the
stack it is likely that it is further exploitable. This could allow
arbitrary code to be run on the server as the user the Apache children are
set to run as.

Aangezien de gemiddelde gebruiker hier nog steeds 32 bits platformen gebruikt lijkt me dit dus geen problemen op te leveren voor bezoekers hier

[jep]

Sorry, ik werk alleen met 64bits systemen he .

Nah, we zullen 't zien als ze er meer over loslaten

[Wilke]

Apache lek? Oh! Dan ga ik meteen over op een veilige webserver!

* Wilke pakt de IIS installatie-CD er bij.....


Hmmmmmmm, hoe 'make install' ik dit

[serieus mode]

Da's dan voor het eerst sinds lange tijd dat zoiets (potentieel) ernstigs geconstateerd wordt in Apache!

Hoewel ik me aansluit bij de mensen die zeggen dat toch bijna niemand al 64-bits platforms draait. Of zoals MS zou zeggen: 'That vulnerability is completely theoretical'

[Verwijderd]

Op dinsdag 18 juni 2002 00:40 schreef Mark het volgende:
Aangezien de gemiddelde gebruiker hier nog steeds 32 bits platformen gebruikt lijkt me dit dus geen problemen op te leveren voor bezoekers hier

Nouja, de server krijgt een SEGFAULT. Oftewel, je (HTTP)service gaat d'r alsnog vandoor (en aangezien elke idioot een return script uit services heeft runnen is dat ding na een minuut wer up)... Toch een hele minuut! .

Maar als ik het goed begrijp zijn er nog geen patches?...

[edit]
En het is dus (voor 64bit systemen) een remote exploit, maar geen remote root exploit. Dus aangezien iedereen apache als dedicated user apache/group apache chrooted draait (toch jep? ), kan je d'r alsnog weinig mee behalve de HD gaan zitten volstoppen met zooi. Quota, klaar. .

[Mark]

Op dinsdag 18 juni 2002 00:48 schreef Wilke het volgende:
Hoewel ik me aansluit bij de mensen die zeggen dat toch bijna niemand al 64-bits platforms draait. Of zoals MS zou zeggen: 'That vulnerability is completely theoretical'

Inderdaad, zoveel mensen zijn er niet met een Alpha, 64-bit Power 3/4/RS64 of een Sparc 64-bitter onder de motorkap van hun server.
Mag hopen dat er ook nog niemand zo dom is geweest om al geld aan de Itanium uit te geven

[Mark]

Op dinsdag 18 juni 2002 00:54 schreef beelzebubu het volgende:

[edit]
En het is dus (voor 64bit systemen) een remote exploit, maar geen remote root exploit. Dus aangezien iedereen apache als dedicated user apache/group apache chrooted draait (toch jep? ), kan je d'r alsnog weinig mee behalve de HD gaan zitten volstoppen met zooi. Quota, klaar. .

chrooted is nog niet eens perse nodig. Zorg gewoon dat de user waarop hij draait alleen maar leesrechten heeft op de documentroots en schrijfrechten op de logdirs (welke je natuurlijk op een ander filesystem neer zet).

[2P]

oei
* 2P heeft thuis een Alpha (64 bit) met Apache draaien

Op zich is het niet zo'n ramp voor mij, want wie wil nou mijn server platleggen?

Maar ook al krijgt iemand www UID access op m'n box, dan kan ie er lekker helemaal niets mee
Ik draai uiteraard chrooted en alleen root heeft schrijf rechten op me www bestanden. De www groep mag alleen lezen, dus een attacker zou er niets mee kunnen
Ik kan in ieder geval wel rustig slapen vanacht

[Verwijderd]

Op dinsdag 18 juni 2002 01:03 schreef Mark het volgende:
chrooted is nog niet eens perse nodig. Zorg gewoon dat de user waarop hij draait alleen maar leesrechten heeft op de documentroots en schrijfrechten op de logdirs (welke je natuurlijk op een ander filesystem neer zet).

Volgens mij kun je dan altijd nog /tmp zitten volproppen... Op zich niet ideaal 100% veilig dus. .

[Wilke]

Nu ook verkrijgbaar op slashdot!

[Mark]

Op dinsdag 18 juni 2002 01:06 schreef beelzebubu het volgende:

[..]

Volgens mij kun je dan altijd nog /tmp zitten volproppen... Op zich niet ideaal 100% veilig dus. .

Hmmm, inderdaad, good point...effe kijken hoe ik dat weer es ga oplossen

[Mark]

Dan hier het gehele stukkie:

code:

Advisories
Internet Security Systems Security Advisory
June 17, 2002

Remote Compromise Vulnerability in Apache HTTP Server

Synopsis:

ISS X-Force has discovered a serious vulnerability in the default
version of Apache HTTP Server. Apache is the most popular Web server and
is used on over half of all Web servers on the Internet. It may be
possible for remote attackers to exploit this vulnerability to
compromise Apache Web servers. Successful exploitation may lead to
modified Web content, denial of service, or further compromise.

Affected Versions:

Apache 1.x

Note: Many commercial Web Application Servers such as Oracle 9ias and
IBM Websphere use Apache HTTP Server to process HTTP requests.
Additional products that bundle Apache HTTP Server for Windows may be
affected.

Description:

The Apache HTTP Server is maintained by the Apache Software Foundation.
Apache is an extremely popular open-source Web server. Netcraft
(http://www.netcraft.com) reports that as of May 2002, Apache accounts
for over 63% of all active Web sites. Apache¿s installed base is larger
than all other Web servers combined.

The Apache Project is an open-source and volunteer collaboration aimed
to create and maintain a free, feature-rich, powerful, and secure Web
server implementation. Apache is well regarded as the best, freely
available Web server.

Apache contains a flawed mechanism meant to calculate the size of
"chunked" encoding. Chunked encoding is part of the HTTP Protocol
Specification used for accepting data from Web users. When data is sent
from the user, the Web server needs to allocate a memory buffer of a
certain size to hold the submitted data. When the size of the data being
submitted is unknown, the client or Web browser will communicate with
the server by creating "chunks" of data of a negotiated size.

The Apache HTTP Server has a software flaw that misinterprets the size
of incoming data chunks. This error may lead to a signal race, heap
overflow, and to exploitation of malicious code.

X-Force has verified that this issue is exploitable on Apache for
Windows (Win32) version 1.3.24. Apache 1.x for Unix contains the same
source code, but X-Force believes that successful exploitation on most
Unix platforms is unlikely.

Recommendations:

Internet Scanner X-Press Update 6.12 includes a check,
ApacheChunkedEncodingBo, to detect installations of Apache HTTP Server
for Win32. XPU 6.12 is available from the ISS Download Center at:
http://www.iss.net/download. For questions about downloading and
installing this XPU, email [e-mail].

Detection support for this attack will be included in future X-Press
Updates for RealSecure Network Sensor 6.x and 7.0. These XPUs will be
available from the ISS Download Center, and this alert will be updated
when these updates become available.

ISS X-Force has developed a patch for this issue. Follow the
instructions below, or contact your vendor for assistance:

To apply a source code patch to your Apache package:

1. Locate your source directory and navigate into the "main" sub-
directory.
2. Verify that "http_protocol.c" is present in the current directory.
3. To update your http_protocol.c file, create a file named
"apache_patch.diff", containing the following text:

--- http_protocol.c.vuln    Fri Jun 14 16:12:50 2002
+++ http_protocol.c Fri Jun 14 16:13:47 2002
@@ -2171,7 +2171,7 @@

     /* Otherwise, we are in the midst of reading a chunk of data */

-    len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
+    len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz : r->
remaining;

     len_read = ap_bread(r->connection->client, buffer, len_to_read);
     if (len_read <= 0) {

4. Apply the source code update using the "patch" command, or a similar
   utility.
5. Build new binaries and reinstall.

The Apache Server Project has been notified and will make a formal patch
available soon. Please refer to the Apache Server Project¿s homepage for
more information: http://httpd.apache.org/

Additional Information:

http://www.iss.net/security_center
http://www.apache.org
http://httpd.apache.org/

Credits:

This vulnerability was discovered and researched by Neel Mehta of the
ISS X-Force.


______

About Internet Security Systems (ISS)
Founded in 1994, Internet Security Systems (ISS) (Nasdaq: ISSX) is a
pioneer and world leader in software and services that protect critical
online resources from an ever-changing spectrum of threats and misuse.
Internet Security Systems is headquartered in Atlanta, GA, with
additional operations throughout the Americas, Asia, Australia, Europe
and the Middle East.

Copyright (c) 2002 Internet Security Systems, Inc. All rights reserved
worldwide.

Permission is hereby granted for the electronic redistribution of this
document. It is not to be edited or altered in any way without the
express written consent of the Internet Security Systems X-Force. If you
wish to reprint the whole or any part of this document in any other
medium excluding electronic media, please email [e-mail] for
permission.

Disclaimer: The information within this paper may change without notice.
Use of this information constitutes acceptance for use in an AS IS
condition. There are NO warranties, implied or otherwise, with regard to
this information or its use. Any use of this information is at the
user's risk. In no event shall the author/distributor (Internet Security
Systems X-Force) be held liable for any damages whatsoever arising out
of or in connection with the use or spread of this information.

X-Force PGP Key available on MIT's PGP key server and PGP.com's key
server, as well as at http://www.iss.net/security_center/sensitive.php

Please send suggestions, updates, and comments to: X-Force
[e-mail] of Internet Security Systems, Inc.

[jep]

En toen zijn apache group:

Please note that the patch provided by ISS does not correct this
vulnerability.

Tis wat

[deadinspace]

Op dinsdag 18 juni 2002 00:54 schreef beelzebubu het volgende:
En het is dus (voor 64bit systemen) een remote exploit, maar geen remote root exploit. Dus aangezien iedereen apache als dedicated user apache/group apache chrooted draait (toch jep? ), kan je d'r alsnog weinig mee behalve de HD gaan zitten volstoppen met zooi. Quota, klaar. .

Toch lullig als je dan ergens nog een local root exploit hebt..
En als je je best doet met een forkbomb kun je de bak anders misschien nog wel plat krijgen.

Op dinsdag 18 juni 2002 01:10 schreef Mark het volgende:
Hmmm, inderdaad, good point...effe kijken hoe ik dat weer es ga oplossen

Quota op het filesystem waar /tmp op staat instellen?

[xychix]

Op dinsdag 18 juni 2002 01:10 schreef Mark het volgende:

[..]

Hmmm, inderdaad, good point...effe kijken hoe ik dat weer es ga oplossen

user quota's en groeps quota's

Op dinsdag 18 juni 2002 00:54 schreef beelzebubu het volgende:

[..]

Nouja, de server krijgt een SEGFAULT. Oftewel, je (HTTP)service gaat d'r alsnog vandoor (en aangezien elke idioot een return script uit services heeft runnen is dat ding na een minuut wer up)... Toch een hele minuut! .

Tell me more ?? een script dat checked of een service uit de lucht is en start deze weer op ? moet ik ook hebbu... waar te vinden ?
-laatmaar- k heb zojuist in een ander actief topic een mooi perl script gevonden, och zie ik het nut niet, een service gaat toch niet down ?
En mocht hij ooit down gaan door een hack poging dan wil ik de attacker 1 minute later geen nieuwe kans geven, mooi down laten zijn !

[Verwijderd]

Op dinsdag 18 juni 2002 06:46 schreef xychix het volgende:
Tell me more ?? een script dat checked of een service uit de lucht is en start deze weer op ? moet ik ook hebbu... waar te vinden ?
-laatmaar- k heb zojuist in een ander actief topic een mooi perl script gevonden, och zie ik het nut niet, een service gaat toch niet down ?
En mocht hij ooit down gaan door een hack poging dan wil ik de attacker 1 minute later geen nieuwe kans geven, mooi down laten zijn !

Voor zover ik weet worden services automatisch gestart en gecheckt. Zijn ze niet meer actief (status), dan worden ze gerestart. Weet dit niet 100% automatisch, maar 't lijkt me dat dit allemaal automatisch gebeurt.

Op dinsdag 18 juni 2002 01:21 schreef jep het volgende:
En toen zijn apache group:
[..]

Tis wat

code:

--- http_protocol.c.vuln    Fri Jun 14 16:12:50 2002
+++ http_protocol.c Fri Jun 14 16:13:47 2002
@@ -2171,7 +2171,7 @@

     /* Otherwise, we are in the midst of reading a chunk of data */

-    len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
+    len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz : r->
remaining;

     len_read = ap_bread(r->connection->client, buffer, len_to_read);
     if (len_read <= 0) {

Ik zie niet zo snel in hoe dit op 32-bit systemen tot problemen zou leiden - dus dan zou het uberhaupt alleen een probleem op 64-bit platformen moeten zijn. Het kan dus zijn dat deze patch de local exploit weghaalt maar de crash niet. Maar het eigenlijke probleem van een buffer overflow kun je niet weghalen met een unsigned int castje, da's veel te simpel, schat ik.
De exploit is, voor zover ik begrijp, een resource overflow exploit. Nu houdt apache overal haar resources bij - en hier zal in de telling ergens een lek zitten. Daar moet je dus strikter met semaphores (locking) gaan werken, en daarna dus in 1.x het bijhouden van resource use uit 2.x overbouwen, zodat apache zelf ziet wanneer het teveel gebruikt en daar gelijk een einde aan maakt. Dat zal de echte oplossing zijn.

[Verwijderd]

misschien toch handig om /var op een aparte partitie te zetten, zelfs als 't quota gedoe mis gaat is er dan nog steeds geen probleem.

[Mark]

Op dinsdag 18 juni 2002 06:46 schreef xychix het volgende:

[..]

user quota's en groeps quota's
[..]

Daar voorkom je geen zaken als session hyacking mee volgens mij. Op het moment dat hackers/crackers/script kiddies zomaar zaken in /tmp kunnen plaatsen en lezen kunnen ze ook bijvoorbeeld sessions (PHP/Perl) kapen. Deze worden bewaard onder de Apache user en de Apache user is de enigste gebruiker (buiten root natuurlijk) die deze bestanden mag openen/wissen/manipuleren.

Dat /tmp met een quota draait (en op een apart partitie) is logisch, dus het voldrukken van /tmp door een normale user (en dus ook de user waar apache onder draait) zal sowieso niet lukken.

[2P]

Op dinsdag 18 juni 2002 11:28 schreef Mark het volgende:

[..]

Daar voorkom je geen zaken als session hyacking mee volgens mij. Op het moment dat hackers/crackers/script kiddies zomaar zaken in /tmp kunnen plaatsen en lezen kunnen ze ook bijvoorbeeld sessions (PHP/Perl) kapen. Deze worden bewaard onder de Apache user en de Apache user is de enigste gebruiker (buiten root natuurlijk) die deze bestanden mag openen/wissen/manipuleren.

Tja dan moet je het filesystem gewoon wat beveiligen, door bv. noexec aan te zetten. Bij mij staat het zo:

code:

/dev/wd0d on /tmp type ffs (local, nodev, noexec, nosuid, with quotas, softdep)

En verder natuurlijk ervoor zorgen dat op webserver niveau alleen lees rechten zijn, zodat een attacker nooit documenten kan veranderen/verwijderen.

Bijvoorbeeld mijn index:

code:

-rw-r-----  1 root  www  1167 Jun 12 19:18 index.php

[Steije]

Op maandag 17 juni 2002 23:30 schreef jep het volgende:
Al heb ik 't idee dat security.nl dit als gewoonlijk weer op loopt te blazen.

Ik denk dat security.nl wel checked op de betrouwbaarheid van een bericht.

[deadinspace]

Op dinsdag 18 juni 2002 07:44 schreef beelzebubu het volgende:
Voor zover ik weet worden services automatisch gestart en gecheckt. Zijn ze niet meer actief (status), dan worden ze gerestart. Weet dit niet 100% automatisch, maar 't lijkt me dat dit allemaal automatisch gebeurt.

Nou, niet in Debian hoor. En dat hoort ook niet... Als een daemon crasht dan heeft dat een reden. Als het echt van levensbelang is maak je zelf maar iets.

[odysseus]

Het staat nu ook op de FP, hier om precies te zijn .

[Ronald]

Lekje is niet meer

Apache 1.3.26 Changelog

Apache 2.0.39 Changelog

[Verwijderd]

thnx guys, ik ga het ff installen

[Verwijderd]

(cupis): dystopia: unofficial debs listed on debian-devel list until they get into the archive

we wachten met smart...

OpenBSD heeft 'm allang gefixed, staat alleen nog niet op de main page.

Edit: http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01197.html staan de quick-fixes. Voor OpenBSD moet je even de source is current pakken oid.

[Mark]

Op woensdag 19 juni 2002 01:45 schreef dystopia het volgende:
(cupis): dystopia: unofficial debs listed on debian-devel list until they get into the archive

we wachten met smart...

OpenBSD heeft 'm allang gefixed, staat alleen nog niet op de main page.

Edit: http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01197.html staan de quick-fixes. Voor OpenBSD moet je even de source is current pakken oid.

Wat is er mis met zelf de tarball downloaden en zelf compileren ?
Imho worden mensen niet slimmer door het gebruik van package managers...

Back ontopic....

Bij mij draait 1.3.26 inmiddels al op een aantal servers. Moest natuurlijk wel alle DSO modules opnieuw compileren (libphp, mod_perl, mod_python, mod_ssl) en liep hier tegen het probleem aan dat mod_perl-1.26 een beetje flipte onder Apache 1.3.26.
Downloaden van de laatste mod_perl versie (1.27) loste dit gelukkig op voor mij

Verder geen noemenswaardige problemen

[Verwijderd]

Op woensdag 19 juni 2002 02:26 schreef Mark het volgende:

[..]

Wat is er mis met zelf de tarball downloaden en zelf compileren ?

Als ik zelf zou gaan compileren op Debian zou ie een boel overwriten cq. verkeerd zetten/doen na de make install. Een tijdelijke oplossing is het misschien wel ja. Aangezien ik niet vuln. was...

Wat betreft OpenBSD: ik ga daar niet al teveel zelf voor compileren. Niet zo'n geweldige ervaring mee. Bovendien is de complete base van het OS geaudit. Dat ga je dan toch niet overwriten, dan ben je wel heel gek bezig. Ports collectie is er ook niet voor niks. Dat zijn geen standaard 'packages' die zo even gecompiled zijn. Daar is behoorlijk aan getweaked. En bovendien Apache compileren op een P1 200 mHz zie ik niet zitten. En bovendien 2: de patches zaten er allang in, in de source iig.

Imho worden mensen niet slimmer door het gebruik van package managers...

Deels mee eens. Zelf compileren kan nuttig zijn. Echter niet altijd. Package systeem kan veel werk uit handen nemen. Neem dit geval: je doet een apt-get update en een apt-get dist-upgrade en je bent kloar. Alleen vind ik dat ze nogal traag zijn met hun fix.

[2P]

Op woensdag 19 juni 2002 02:42 schreef dystopia het volgende:

Wat betreft OpenBSD: ik ga daar niet al teveel zelf voor compileren. Niet zo'n geweldige ervaring mee. Bovendien is de complete base van het OS geaudit. Dat ga je dan toch niet overwriten, dan ben je wel heel gek bezig. Ports collectie is er ook niet voor niks. Dat zijn geen standaard 'packages' die zo even gecompiled zijn. Daar is behoorlijk aan getweaked. En bovendien Apache compileren op een P1 200 mHz zie ik niet zitten. En bovendien 2: de patches zaten er allang in, in de source iig.

Tja, je zult toch echt wel moeten compilen als je de nieuwe httpd op OpenBSD wilt draaien. Ik heb er nu geen zin meer in maar morgen zal ik wel weer ff een cvsup draaien en de httpd boel opnieuw compilen.
Apache zit btw niet in de ports maar maakt deel uit van het basesystem van OpenBSD.

[ShadowBumble]

Hier even de volledige meldingen van dit "lek" en de bevestiging dat het alweer gefixed is.

-----BEGIN PGP SIGNED MESSAGE-----

______________________________________________________________________________
SGI Security Advisory

Title: Apache Web Server Chunk Handling vulnerability
Number: 20020605-01-A
Date: June 18, 2002
Reference: CERT CA-2002-17
Reference: Apache Security Bulletin 20020617
Reference: CAN-2002-0392
______________________________________________________________________________

SGI provides this information freely to the SGI user community for its
consideration, interpretation, implementation and use. SGI recommends
that this information be acted upon as soon as possible.

SGI provides the information in this Security Advisory on an "AS-IS" basis
only, and disclaims all warranties with respect thereto, express, implied
or otherwise, including, without limitation, any warranty of merchantability
or fitness for a particular purpose. In no event shall SGI be liable for
any loss of profits, loss of business, loss of data or for any indirect,
special, exemplary, incidental or consequential damages of any kind arising
from your use of, failure to use or improper use of any of the instructions
or information in this Security Advisory.
______________________________________________________________________________


SGI is currently investigating the Apache vulnerability reported by
CERT http://www.cert.org/advisories/CA-2002-17.html and Apache
http://httpd.apache.org/info/security_bulletin_20020617.txt

This vulnerability was assigned the following CVE:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0392

No further information is available at this time. As further information
becomes available, additional advisories will be issued.

For the protection of all our customers, SGI does not disclose, discuss
or confirm vulnerabilities until a full investigation has occurred and
any necessary patch(es) or release streams are available for all vulnerable
and supported Linux and IRIX operating systems.

Until SGI has more definitive information to provide, customers
are encouraged to assume all security vulnerabilities as exploitable and take
appropriate steps according to local site security policies and requirements.

As further information becomes available, additional advisories will be
issued via the normal SGI security information distribution methods
including the wiretap mailing list.


- -----------------------------------------
- --- SGI Security Information/Contacts ---
- -----------------------------------------

If there are questions about this document, email can be sent to
[e-mail].

------oOo------

SGI provides security information and patches for use by the entire
SGI community. This information is freely available to any person
needing the information and is available via anonymous FTP and the Web.

The primary SGI anonymous FTP site for security advisories and patches
is patches.sgi.com (216.32.174.211). Security advisories and patches
are located under the URL ftp://patches.sgi.com/support/free/security/

The SGI Security Headquarters Web page is accessible at the URL
http://www.sgi.com/support/security/

For issues with the patches on the FTP sites, email can be sent to
[e-mail].

For assistance obtaining or working with security patches, please
contact your SGI support provider.

------oOo------

SGI provides a free security mailing list service called wiretap and
encourages interested parties to self-subscribe to receive (via email) all
SGI Security Advisories when they are released. Subscribing to the mailing
list can be done via the Web (http://www.sgi.com/support/security/wiretap.html)
or by sending email to SGI as outlined below.

% mail [e-mail]
subscribe wiretap <YourEmailAddress>
end
^d

In the example above, <YourEmailAddress> is the email address that you
wish the mailing list information sent to. The word end must be on a
separate line to indicate the end of the body of the message. The
control-d (^d) is used to indicate to the mail program that you are
finished composing the mail message.


------oOo------

SGI provides a comprehensive customer World Wide Web site. This site is
located at http://www.sgi.com/support/security/ .

------oOo------

For reporting *NEW* SGI security issues, email can be sent to
[e-mail] or contact your SGI support provider. A
support contract is not required for submitting a security report.

______________________________________________________________________________
This information is provided freely to all interested parties and
may be redistributed provided that it is not altered in any way,
SGI is appropriately credited and the document retains and includes
its valid PGP signature.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBPQ9dj7Q4cFApAP75AQG0IgP/Xz89pQ+026JedcfnXI2PQZC6goU52azr
h3TZJvzinVn4eU92BtXLjQ6lffPwjvQSylr5694XUN1fHqtaHb5O4SYWmP4fVOKb
S9bu10y28vLXS6mLlDz7cAop7BcHLV+FEwyeeHvV6ddhJ5ogdMC/oFGggyyAFdzv
3bdDYjpTwWQ=
=NL5f
-----END PGP SIGNATURE-----

Hey all,

Jay Dyson reported earlier that Apache httpd 2.0.39 was available for
download. Version 1.3.26 is now available:

http://httpd.apache.org/dist

See also:

http://www.apache.org/dist/httpd/Announcement.html

On Tue, 18 Jun 2002, Jay D. Dyson wrote:

> > The Apache Software Foundation has released two new versions of Apache
> > that correct this vulnerability. System administrators can prevent the
> > vulnerability from being exploited by upgrading to Apache version
> > 1.3.25 or 2.0.39.
>
> I've just visited http://httpd.apache.org/ for the upgrade on
> Apache and noted that v2.0.39 is available
• , but v1.3.25 is nowhere to
> be found. Is anyone in the know on an ETA for Apache v1.3.25?
>
> - -Jay

Dave Ahmad
SecurityFocus
www.securityfocus.com

Heerlijk die bugtracking lists

[Verwijderd]

Op woensdag 19 juni 2002 02:52 schreef 2P het volgende:

[..]

Tja, je zult toch echt wel moeten compilen als je de nieuwe httpd op OpenBSD wilt draaien. Ik heb er nu geen zin meer in maar morgen zal ik wel weer ff een cvsup draaien en de httpd boel opnieuw compilen.
Apache zit btw niet in de ports maar maakt deel uit van het basesystem van OpenBSD.

Ja i know, maar dan met patch recompilen en nachtje slapen . Geen cvsup gezeik. Ik draai stable niet current. Overigens draai ik momenteel (nog) geen Apache @ Open. Wist het niet zeker. PHP ed. staan iig niet standaard in de base maar Apache wel en staat standaard niet aan. Dus de 5 jaar blijven staan en de code is geaudit. Laatste is nog een rede om niet zelf te compileren vanaf de source.