Beveiligingsfout in recentste Apache-releases

Op de site van Apache is te vinden dat de bekende webserver een beveiligingsfout bevat. Het probleem kan er in het ergste geval voor zorgen dat een kwaadwillend persoon toegang krijgt tot de server, waarbij hij de rechten krijgt waarmee Apache draait. Deze ergste situatie treedt alleen op bij gebruik van Apache 1.3 op bepaalde 64-bit platforms. De fout is zowel door Apache zelf als door beveiligingsbedrijf ISS ontdekt. ISS heeft de fout bekend gemaakt en een patch meegeleverd, maar inmiddels is bekend dat deze patch geen oplossing voor het probleem vormt. De Apache-ontwikkelaars melden zelf bezig te zijn met een oplossing.

Het probleem ontstaat zodra er bepaalde foute aanvragen naar de server worden gestuurd. Deze aanvragen kunnen ervoor zorgen dat het proces dat de verbinding afhandelt crasht. Aangezien dit proces alleen die enkele verbinding afhandelt is dat niet heel erg, maar de algemene Apache-server zal het proces na een crash weer opstarten. Door zo vaak mogelijk subprocessen te laten crashen kan een aanvaller een website slecht bereikbaar maken. Voor sommige versies van Apache is het probleem groter: als er geen gebruik wordt gemaakt van verschillende processen maar van verschillende threads, dan zorgt een enkele crashende thread ervoor dat de hele server zichzelf opnieuw initialiseert. Dit duurt langer dan het opnieuw starten van een proces en zorgt er bovendien voor dat niet alleen de verbinding met de aanvaller, maar ook de andere verbindingen verbroken worden. Een stukje uit het security-bulletin:

Versions of the Apache web server up to and including 1.3.24 and 2.0 up to and including 2.0.36 and 2.0.36-dev versions contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. This bug can be triggered remotely by sending a carefully crafted invalid request. This functionality is enabled by default.

Het was DPCquatar die ons dit nieuws bracht.

Lees meer

Reacties (31)

Verwijderd 18 juni 2002 16:13

een van de opmerkelijke dingen in dit geval was, dat ISS geen waarschuwing naar Apache heeft gegeven, en de exploit zomaar heeft gepost.

Dit klinkt normaal, maar is het niet. Dit soort bedrijven geven de makers altijd een aantal dagen de kans een patch uit te brengen, en daarna de exploit pas publiek te maken.

no respect voor ISS dus, zeker niet aangezien zij NIET de eerste waren, en zij GEEN goede patch hadden gemaakt, en NIET apache group op de hoogte hadden gesteld.

ennehm, op linux/unix is het gevaar vrij laag, eventuele code word toch alleen op user nobody uitgevoerd. Windows en 64bit platvoren is het een ander geval (dit begreep ik dan tenminste )

Ronald @Verwijderd • 18 juni 2002 16:33

Inderdaad zeer slordig van ISS, betreurenswaardig, omdat Apache er al van af wist en bezig waren het op te lossen.

Verder kan het alleen op windows en 64bit unix leiden tot remote code execution, op 32bit unixen slechts een DoS doordat de http kindjes gaan segfaulten en vervangen moeten worden.

Volgens een advisory van CERT, gepost op bugtraq@securityfocus.org zou apache al releases gedaan hebben met de oplossing voor het lek: 1.3.25 en 2.0.39.
Deze vind ik echter nog niet op de site van apache

sharky_ @Ronald • 18 juni 2002 20:03

2.0.39 is inmiddels te downloaden op de servers van apache. De 1.3.25 versie laat nog even op zich wachten zo te zien.

edit:

ook even linkje dan maar:
http://www.apache.org/dist/httpd/apache_1.3.24.tar.gz

of om het zelf te bekijken:
http://www.apache.org/dist/httpd

Ronald @sharky_ • 19 juni 2002 00:38

Hoppa: De fixes :-)

Apache 1.3.26 Changelog
en

Apache 2.0.39 Changelog

kodak @sharky_ • 19 juni 2002 00:14

Wat aardig, een linkje naar de Apache 1.3 versie MET de door ISS gevonden bug.

Mark @Verwijderd • 18 juni 2002 16:46

Lees maar eens hoe Slashdot denkt over de manier zoals ISS het aangepakt heeft.
Dit is natuurlijk weer een goede reclame voor ISS....

jp 18 juni 2002 15:30

(...)contain a bug in the routines
which deal with invalid requests which are encoded using chunked encoding.
This bug can be triggered remotely by sending a carefully crafted invalid
request. This functionality is enabled by default.

Dus als je die functionaliteit uit zet, ben je als nog save?

edit:

Zucht.. een post die er toevallig als eerste staat krijgt niet automagisch de classificatie 'first post' hoor.....

Verwijderd @jp • 18 juni 2002 16:18

Nee, die functionaliteit kan je niet zomaar uit zetten. (is geen switch).

Meestal hoeft je niets te doen, want alleen wanneer je 64bits UNIX of een Microsoft OS gebruikt is de kans groot dat de bug problemen kan veroorzaken.

De patch staat op www.iss.net

[code]
- len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
+ len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz : r->
remaining;
[/code]

Ronald @Verwijderd • 18 juni 2002 16:27

Die patch werkt NIET volgens de jongens van apache zelf.

jp @Verwijderd • 18 juni 2002 15:33

Dat zullen ze er niet bij zetten omdat het niet waar is

Investigation by the
Apache Software Foundation showed that this issue has a wider scope, which
on some platforms results in a denial of service vulnerability, while on
some other platforms presents a potential a remote exploit vulnerability.

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.

(En Linux is AFAIK een UNIX variant

)

deadinspace @jp • 18 juni 2002 18:25

Due to the nature of the overflow on 32-bit Unix platforms this will cause a segmentation violation and the child will terminate.

De apache child die die request afhandelt sterft dus. Dat is geen exploit, dat is hoogstens een denial of service.

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.

Op Unices op 64 bits platformen is het dus wel een exploit.

Als je een Unix (incl GNU/Linux) draait op een 32 bits-platform, dan hoef je je dus behoorlijk minder zorgen te maken. Dat betekent niet dat je er geen aandacht aan moet schenken, maar je bent -als het goed is- niet exploitable.

Als je een Unix op een 64 bits platform draait of als je Windows draait, dan kun je maar beter maatregelen treffen.

Merk op dat in het geval van een Unix op een 64 bits platform de attacker alleen rechten krijgt waaronder apache draait (dus gelukkig geen root-rechten).

OddesE 19 juni 2002 00:23

nu ja het moet niet steeds microsoft zijn dat we in zulke berichten te lezen krijgen.

-1 flamebait...
Ja ik zal dan maar even vergeten dat zo'n 40 procent van alle postings op Tweakers.net over Microsoft...eh sorry Micro$oft zo'n toon aanslaat.

Dit is naar mijn oordeel gewoon het bewijs dat alle ontwikkelaars, dus ook Apache, fouten maken.
Zometeen krijgt MS alsnog de schuld, omdat het probleem op Windows groter zou zijn....Zucht.
Overigens begrijp ik dat niet goed, want onder Windows 2000 e.d. heb je toch ook gewoon 'guest' achtige accounts? Waarom zou de hacker toegang op Administrator niveau krijgen? Websites draaien toch hopelijk niet onder Windows 98?

RG @OddesE • 19 juni 2002 13:53

Je moet wel naar de ernst van de bugs kijken. Deze Apache bug kan weliswaar vervelende dingen veroozaken, maar stelt eigenlijk niet zoveel voor. Zeker niet in vergelijking met gaten die Microsoft wel eens in zijn software heeft zitten.
Ik weet niet hoe het bij jou zit, maar al die Nimda en CodeRed wormen heb ik ondertussen al enorm vaak binnen gekregen (51837x nimda en 4273x codered). Zulke ernstige dingen heb ik nog nooit gezien bij Apache.

Fouten maken is menselijk, maar Apache heeft toch wel bewezen dat het behoorlijk degelijk in elkaar steekt en problemen die optreden door bugs zijn altijd erg klein.

Aetje 18 juni 2002 15:35

Morgen is er dus versie 2.0.37-dev waar dit bugje niet meer in zit. Gotta love open source...

Koffie @Aetje • 18 juni 2002 16:07

Dus als er een soortgelijk probleem in IIS had gezeten, en Microsoft had aangekondigt morgen een update te verspreiden die het probleem fixxed dan had je gepost:
"Gotta love open source... "

(en dat terwijl er al een patch is uitgebracht die niet eens werkt).
(Hmm.. de patch komt dus NIET van apache zelf lees ik net)

freaky @Koffie • 18 juni 2002 17:15

De dag dat MS met een bug uitkomt met de mededeling dat er morgen een patch is was de bug al 3 maanden bekend in de ondergrond.

Zonique 19 juni 2002 06:14

Even een waarschuwing voor degenen die PHP graag als module willen draaien en denken de Apache versie even te installeren: Deze 2.0.39 release is dus niet compatible met de Apache SAPI uit de laatste PHP-release (4.2.1)

Jimbolino 19 juni 2002 09:14

Users of Apache 1.3 should upgrade to 1.3.26, and users of Apache 2.0
should upgrade to 2.0.39, which contain a fix for this issue.

las ik op http://httpd.apache.org/info/security_bulletin_20020617.txt

dus toch snel opgelost...

Verwijderd 19 juni 2002 13:58

Het is wel mogelijk om PHP te draaien met de nieuwe versie. Het klopt dat apache 2.0.39 niet draait met php 4.2.1. Van http://snaps.php.net is echter een development versie van 4.3.0 te downloaden. Met deze versie van php werkt apache 2.0.39 wel!

Verwijderd 18 juni 2002 16:15

Dit is een fenomeen dat zich enkel voordoet op zware of druk bezochte webservers. Het poces wordt dan trager gestart op een Pentium 3 1000 Mhz is de gemiddelde start tijd 4ms dus die tijd gaat een hacker echt niet kunnen benutten tenzij hij heeel veeeeeel geluk heeft en de serverowner veel pech. Bij zware servers kan dit een probleem vormen dan zijn er vaak start tijden (zeker als er ook een druk bezochte mysql databse op staat) tot een 15 seconden.

Olaf van der Spek @Verwijderd • 18 juni 2002 19:24

Wat heeft de MySQL DB met de opstartsequence van Apache te maken?

Verwijderd @Olaf van der Spek • 19 juni 2002 10:10

Wat heeft de MySQL DB met de opstartsequence van Apache te maken?

omdat de enige theoretische exploit die er is bedacht alleen maar werkt indien je de machine gekraakt hebt in de tijd die het kost om een nieuw apache proces te starten. Op een niet-zo-drukke server moet je de machine dus in 4ms gekraakt hebben. Op een wel drukke server kan die tijd oplopen, en een database voegt zeker wel wat toe aan die tijd.