Fout in PHP kan onder andere Apache laten crashen

Een van de meest gebruikte scripttalen op internet is wel PHP, en juist in deze taal is volgens CNet een behoorlijke fout geslopen. Aanvallers zouden via het beveiligingslek in alle versies van PHP 3.10 tot 4.1.1 een webserver laten crashen of in ieder geval behoorlijk in de soep laten lopen. Het is volgens een woordvoerder van het System Administration, Networking, and Security Internet Storm Center echter niet eenvoudig om gebruik te maken van het lek, zodat verwacht wordt dat er weinig mensen zullen zijn die ook daadwerkelijk iets kunnen doen via het lek. In totaal zouden miljoenen servers anders gevaar kunnen lopen.

Het betreft de manier waarop PHP zogenaamde 'multipart/form-data POST' aanvragen behandelt. Via de functie php_mime_split kan iedereen in principe elk willekeurig programma laten uitvoeren op de webserver, mits deze gebruik maakt van Apache-software. De fout kan namelijk alleen maar misbruikt worden bij webservers die op Linux of Solaris draaien, wat voornamelijk neerkomt op Apache. Microsoft's Internet Information Server bijvoorbeeld - die eerder nogal eens voor problemen zorgde - is in dit geval dus niet gevoelig voor het defect, dat voornamelijk bestaat uit een combinatie van vollopend geheugen en een probleem in het systeem dat dit hoort op te merken.

Met dank aan Verwijderd voor de tip.

Reacties (47)

[alt-92]

Er wordt nu wel gedaan of dit een show-stopper is, maar het blijkt uiteindelijk alleen bij file-upload functies een beperkt risico te kunnen vormen.

[arjankoole]

waarbij nog even vermeld dient worden dat een aantal hosters (okay, de hosters die verstand en kennis van zaken hebben) file_upload uitgeschakeld staat in php.ini

die kunnen dus ongehinderd doordraaien op 4.1.0 en 4.1.1 (of 3.0.18, waar het verschijnsel zich ook voordoet) en reken maar dat het niet exploitable is.

[Strebor]

De fout kan namelijk alleen maar misbruikt worden bij webservers die op Linux of Solaris draaien

Enne... de BSD of FreeBSD (en andere unix'en) Apache varianten dan Het lijkt me niet dat alleen de Linux en Solars builds last zullen hebben van de bug.

[Verwijderd]

zoals je al zegt, de "andere" unixen

als deze big op linux van toepassing is, kan je er kwadraat op zeggen dat ie ook in de andere *nixen zit.

[arjankoole]

Absoluut waar, hoewel het soms wel in de platform afhankelijke include files kan zitten hoor, en die (hoewel ze exact hetzelfde functioneren) verschillen per OS flink. Dus in theorie kan het wel zo zijn dat een dergelijk security leakje alleen op bijv. Linux en Solaris uitbarst, of alleen op Windows en FreeBSD. (very unlikely, maar de theorie en de wet van Murphy....enfin, je kent het wel )

maar in dit geval bestond zat het 'm in specifieke PHP code, die op ieder OS dezelfde uitwerking heeft.

[TumbleCow]

Hierbij zijn het dus wel alleen linux en solaris, daarom wordt het er ook expliciet bij vermeld.

[Ashe]

Finally I want to mention that the boundary check vulnerabilities are only exploitable on linux or solaris. The heap off by one is only exploitable on linux(maybe solaris)x86 and the arbitrary heap overflow in PHP3 is exploitable on most OS and architectures. (This includes *BSD, Windows, Linux, Solaris)

Moesten sommige mensen de advisory zelf eens lezen dan zal men zien dat er verschillende vulnerabilities zijn gevonden.
Sommige zijn enkel toepasselijk op Linux/Solaris, anderen daarentegen zijn weer toepasselijk op nog andere platformen (waaronder de BSD's en Windows).

[rjeggens]

Wij van tweakers.net spelen goed op elkaar in, vandaar dat de patch hier beschikbaar is

[_JGC_]

Damn, gisteren net PHP+Apache gecompileerd op mn Dual Pentium 100, kan ik weer

Nou ja, had toch al zin om SSL support toe te voegen, dusseh

edit:

Het wordt nog grappiger: ik heb mn L2 cache CELP module gesloopt, mag ik nog langer wachten

[Verwijderd]

Misschien moet je dan nog maar effe wachten omdat in SSL ook een lek is gevonden.

[TumbleCow]

geen paniek, dit security-leak is namelijk wel *heel* lastig exploitable.

Je moet namelijk een *trusted* client vertificate hebben, dat zo groot is dat het een overflow veroorzaakt.

De enigste manier om aan een trusted certificate te komen is via een 'certificate authority' (een bedrijf dat certificates uitgeeft), en die geven helemaal niet zulke grote certificates uit..

edit: Kwootje uit het linkje van rjeggens:

HOWEVER, these
routines are only called AFTER SUCCESSFUL VERIFICATION of the client
cert, which would mean that a CA *TRUSTED BY THE WEB SERVER* would have
to issue the certificate in question.

[RobT]

Laat de reacties maar komen over hoe brak linux is en hoeveel beter M$

En voor de linuxfreaks: start de stopwatch om straks te stoppen als het lek gedicht is, lijkt me een leuke benchmark: hoe goed gaat deze tijd worden?


[edit]
Ha! binnen 5 minuten 4 reacties dat het al gefixt is.
Lijkt me een nieuw record.
En alle replyers bedankt voor de medewerking...

Ps overbodig? Ik denk dat ik hier een hoop aantoon tav de respons van de linux/open source community
Naja, beter dan 'first-post'

[Marcel van Veen]

Jammer RobT, versie 4.1.2 heeft de bug al niet meer
Gefixed. Tijd: 0 minuten

LinuxMan > de bug is pas uitgekomen toen de patch er was. Dus de tijd is 0 minuten, en geen 4

[The Source]

Nee hoor, de bug was gister ook al bekend.

[Marcel van Veen]

En toen was de fix (versie 4.1.2) ook al

[luc]

Kan die stopwatch ook negatief tellen ?
http://luc.hostservices.nl/info.php

Verder vind ik het wel erg slordig dat deze bug al sinds een van de 3.x versies aanwezig is zonder opgemerkt te worden..
Maar goed, er is bij het bekend worden van deze bug al wel
meteen een bugfix beschikbaar. Netjes, zo hoort het imho.

[arjankoole]

ik geloof dat ie ook maar bij toeval ontdekt is

en toevallig stond in de CVS versie van 4.2 al een complete re-write van die code klaar, even een kleine backport en klaar is PHP-Core.

maar euh, petje af, ik doe ze het echt niet na.

[LinuxMan]

En voor de linuxfreaks: start de stopwatch om straks te stoppen als het lek gedicht is, lijkt me een leuke benchmark: hoe goed gaat deze tijd worden?

het is nu 17:33, 4 minuten na de posting, en je kunt nu de path en een nieuwe PHP versie downloaden van www.PHP.net

is 4 minuten snel genoeg?

[Verwijderd]

Er hoeft in dit geval geen stopwatch te worden gestart, omdat dat al een dag te laat is

Op php.net valt te lezen: "Due to a security issue found in all versions of PHP (including 3.x and 4.x), a new version of PHP has been released. Details about the security issue are available here. All users of PHP are strongly encouraged to either upgrade to PHP 4.1.2, or install the patch (available for PHP 3.0.18, 4.0.6 and 4.1.0/4.1.1)."

[Remco2001]

SHIT! Ik dacht dat je dan een ECHTE Apache kon laten crashen c.q. neerstorten

[DeTeraarist]

Huh, vliegende Apaches? Ik heb veel over Winnetou gelezen, maar dat ze konden vliegen wist ik nog niet

[Scorpion]

Windows XP zal inmiddels ook wel bij de apache's bekend zijn

[Verwijderd]

Please notice, that you are not only vulnerable if you run scripts that use uploaded files. You are vulnerable if you run any script! If you have PHP only installed but there is no script on your server you are not vulnerable.

Zie http://security.e-matters.de/advisories/012002.html

Trouwens, in de scene (klinkt eng zeg) was dit al langer bekend, maar sinds 27 feb is het officiel bekend gemaakt door een lid van het developersteam van PHP. Vandaar dat ook nu pas op nieuwssites wordt over bericht.

Trouwens, niet alleen Apache is vuln. maar alle webservers volgens mij. Het ligt aan de PHP module en niet aan de webserver..

Daarnaast is PHP3 zodanig lek dat het betrekking heeft op *BSD, Windows, Linux en Solaris. Dus daar gaan de anti-linux opmerkingen

[SED]

<<in alle versies van PHP 3.10 tot 4.1.1>>
<< al maanden bekend bij HaCKERS>>

En dan dit:

< binnen vier minuten een patch>

Ik krijg sterk de indruk dat de objectiviteit hier ver te zoeken is.
Bij een MS product was de gehele lin community erover gevallen. Ik mis zelfkritiek hier.

[Cruz]

Er zijn ook voor Windows *tig bugs die alleen bij H4X0R5 bekend zijn, maar omdat ze die bugs niet doorgeven aan de coders, kunnen de coders ze niet fixen.

Bij het bepalen van de responsetijd voor een bugfix kan je dit dus niet meetellen.

Ik vraag me alleen af hoeveel mensen daadwerkelijk hun webserver met de patch/update uit gaan rusten. Bij IIS zie je aan CodeRed dat ("windows lusers" ) lang niet alle bugfixes worden uitgevoerd. Stel dat binnen een paar weken iemand met een werkende exploit komt, krijgen we dan een nieuw CodeRed verhaal of denken jullie "De mensen die PHP draaien zijn (in dit geval) linux/solaris gurus en patchen alles meteen"?

[leonardo1504]

Bij een MS product was de gehele lin community erover gevallen. Ik mis zelfkritiek hier.

Ga voort, maak mijn dag! Blame on me!

[Verwijderd]

Mag 't ook eens een keertje....

We zijn helemaal niet gewent dat er een fout zit in Linux software.. dus ja.. nou is 't ff schrikken he...
maarja.. als je IIS hebt ken ben je inmiddels al gewent aan dat gevoel!

[Dennizz]

ik heb er niet reteveel verstand van, maar wat ik eruit opmaak is dat de fout in PHP zit, en niet in de linux kernel fzo

[gomaster]

Ik draai xitami van imatix. Mooi dat dat dan niet crasht. ik heb altijd gedacht dat apache beter was.

[veldmuis]

NOFI, maar Xitami is voor windows, en het is een best n00bservertje zeg maar, een gevorderde gebruiker zal eerder Apache gebruiken als Xitami

[jvreuls]

FYI, Xitami is er ook voor andere platformen:

It runs on all UNIX platforms, OS/2, OpenVMS, Windows 3.x, Windows 95, and Windows NT.

Blijft natuurlijk wel dat je eerder Apache gebruikt idd

[arjankoole]

Als in je Xitami een bug zou zitten zou ie dat waarschijnlijk ook wel doen.... Apache heb ik het ook alleen onder 'extreme omstandigheden' zien doen...