Veiligheidsgaten in Apache Mod_Rewrite en IE5.5

Voor zowel Apache als Internet Explorer 5.5 zijn vandaag door WebWereld nieuwe lekken gemeld.

De Apache-lek is gevonden door Apache Week en blijkt te zitten in de rewrite module. Het gevolg is dat een cracker toegang zou kunnen krijgen tot elke file op de server. In Apache 1.3.13 die volgende week wordt verwacht zal dit gat gedicht worden:

Het gat zit in de veel gebruikte 'rewrite module' (mod_rewrite), die is geleverd vanaf versie 1.2. Met deze module kan de server een opgevraagd webadres (URL) omzetten naar een ander adres. Deze techniek wordt veel gebruikt bij doorverwijsscripts (redirect) en verplaatsing van een server, bijvoorbeeld naar een ander domein.

De module kan gebruik maken van zogenoemde 'regular expressions' (regex). Deze set letters, cijfers en symbolen wordt in combinatie met een regex-programma gebruikt om zoek- en vervangacties uit te voeren. Hierbij kan gebruik gemaakt worden van variabelen. Het lek ontstaat als de vervangopdracht eindigt op zo'n variabele. Een cracker kan zich toegang verschaffen tot elke file op de server, ook die buiten de server- en documentroot. [break]Het lek in IE5.5 heeft ook betrekking op Outlook Express en is volgens Security Focus niet echt een direct gevaar te noemen. Door de GetObject() JScript functie en het 'htmlfile' ActiveX-object zou een aanvaller toegang kunnen krijgen tot elk besand op een PC, mits de naam en locatie bekend zijn:[/break]Het lek in Internet Explorer 5.5 en Outlook Express ontstaat door de GetObject() JScript functie en het 'htmlfile' ActiveX-object. ActiveX is het onderdeel van Internet Explorer dat het verzenden en ontvangen van bestanden regelt. Al eerder werd aangetoond dat deze functie niet veilig is. Het uitzetten van Active Scripting biedt een oplossing.

Specialisten zien dit laatste lek niet als een groot gevaar, vooral gezien dat de exacte bestandsnaam bekend moet zijn. Elias Levy van SecurityFocus.com geeft het lek een cijfer 4,5 op een schaal van 10.

Microsoft studeert op het lek.

Wij danken Byteripper en The Ghost voor de tip.

Reacties (35)

[Verwijderd]

Microsoft studeert op het lek en van Apache is volgende week al een fix te downloaden. Voor serversoftware is open-source echt stukken beter!

Bullshit man. IE wordt toch eventjes door *iets* meer mensen gebruikt dan Apache (zeg maar iets van 10000x zo veel). Als er door een bugpatch nieuwe problemen ontstaan is dat in IE daarom een stuk erger dan in Apache. Bij Microsoft moet elke bugfix eerst een hele QA fase doorlopen, dat kost gewoon een dagje of twee extra. Maar zelfs dan nog heeft Microsoft waarschijnlijk gewoon voor het eind van de week een fix als ze het lek ernstig genoeg vinden. Ook bij Microsoft worden echt ernstige bugs gewoon dezelfde dag nog dichtgegooid.

[mth]

IE wordt toch eventjes door *iets* meer mensen gebruikt dan Apache (zeg maar iets van 10000x zo veel).

Apache is dan ook een webserver en IE een browser. Het komt wel vaker voor dat er meer clients dan servers zijn .

Maar zelfs dan nog heeft Microsoft waarschijnlijk gewoon voor het eind van de week een fix als ze het lek ernstig genoeg vinden.

Zoals iemand al eerder opmerkte: waarschijnlijk is dit dezelfde bug als die een tijd geleden al op Tweakers stond. Als dit waar is, dan is MS ofwel heel traag met fixen of ze vinden het niet belangrijk genoeg. In beide gevallen ben je als klant niet echt blij.

[Atmosphere]

Zoals iemand al eerder opmerkte: waarschijnlijk is dit dezelfde bug als die een tijd geleden al op Tweakers stond. Als dit waar is, dan is MS ofwel heel traag met fixen of ze vinden het niet belangrijk genoeg.

Euhm ze zullen het vast wel belangerijk vinden, maar zoals altijd bij M$.. ze zoeken er een oplossing eromheen. Ze zullen zelf die interfaces vaak genoeg gebruiken en hem daarom niet zomaar weg kunnen laten. Ook zal hun user-base (evenals een flink aantal Site-Admins) niet blij zijn als een hele berg www.paginas niet meer naar behoren functioneren.

Als ik het goed heb wordt die routine gebruikt voor het uploaden van bestanden naar een HTTP locatie vanuit een web-pagina (met scripting). Zoals tweakers b.v. (Femme misschien heb jij daar een reaktie op)

[mth]

Ik dacht dat de locatie van een bepaald stukje code ten onrechte op "lokaal" werd gezet en daarom toegang kreeg tot de lokale harddisk. Dat zou te fixen zijn zonder dat legitieme programma's niet meer werken.

[Atmosphere]

Het lek in Internet Explorer 5.5 en Outlook Express ontstaat door de GetObject() JScript functie en het 'htmlfile' ActiveX-object. ActiveX is het onderdeel van Internet Explorer dat het verzenden en ontvangen van bestanden regelt.

Euhm.. lees

[EfBe]

de twee lekken hebben niets met elkaar te maken. ze in 1 posting neerzetten snap ik wel, maar de mensen die de 2 lekken gaan vergelijken welke het meest erg is snappen niet echt waar het om gaat.

Anyway: de IE flaw is een activeX misusage. Zet in IE de activeX security op 'prompt' overal en niet meer vurnerable.

[servies]

De twee lekken heben in zoverre iets met elkaar te maken dat ze beide met internet te maken hebben.

Anyway: om je argument voor IE iets te ontkrachten,het klopt wel maar... 99,9% van de normale gebruikers zal dat niet doen omdat ze het onhandig vinden dat ze de hele tijd op zo'n button moeten drukken om iets te bevestigen... of omdat ze niet weten dat dat uitgeschakeld kan worden. Ik heb zelf dat soort security features wel aanstaan maar ik heb er zelf ook een bloedhekel aan om continue vragen te moeten wegdrukken. Mensen zijn gewoon erg gemakzuchtig.

[Verwijderd]

Nog beter: zet activeX op "disable" Je hebt het toch nooit nodig. Elke site werkt wel zonder, en als ze niet zonder werken vraag ik me altijd af waarom en is het voor mij een reden om juist activeX "disabled" te zetten, gezien de bug...

Misschien ligt het aan mij, ...maar misschien moet MS anders de bug maar eens fixen in plaats van erop studeren. Hoe moeilijk kan het zijn? De bug is bekend sinds 7 september, da's al 3 weken.

(leuk die nieuwe gezichtjes)

[LuCarD]

Here are some example RewriteRule directives. The first is vulnerable, but the others are not

RewriteRule /test/(.*) /usr/local/data/test-stuff/$1
RewriteRule /more-icons/(.*) /icons/$1
RewriteRule /go/(.*) www.apacheweek.com/$1

Volgens mij valt het probleem wel mee, zolang je ervoor zorgt dat je rewrite via de HTTP root en niet via de server-root.

[Verwijderd]

heheh. Microsoft studeert op het lek en van Apache is volgende week al een fix te downloaden. Voor serversoftware is open-source echt stukken beter! veiligheidshol? nix niet kijken of het economisch wel uitkan om het te fixen! Gewoon een bugmelding doen bij de auteur en twee dagen later de fix downloaden of desnoods zelf het gat dichten!

[Atmosphere]

Ik denk niet dat je er rekening mee hebt gehouden dat het lek in Apache behoorlijk wat erger is dan die in IE. Is dus niet zo vreemd dat Apache meteen gefixt wordt (ook niet als je ervan uitgaat dat dat Apache 1 van de meest gebruikte web-servers is). En om dan te zeggen dat Open-Source, door het snelle fixen van bugs, beter is .. nee, een security-hole wordt ondekt omdat iemand de source doorbladerd opzoek naar bugs of gaten in de beveiliging, maar dit hoeft niet altijd een goed-willend (hacker)persoon te zijn, dit kan ook een cracker zijn die er alleen maar op uit is om je server te doen crashen of je data te mishandelen

[deef-]

Dat is echt onzin..

Opensource is beter voor de security omdat Iedereen de veiligheidsgaten kan ontdekken, wordt er een veiligheidslek ontdekt dan wordt er vaak gelijk melding van gemaakt, zoals nu!

In microsoft's software kunnen wel tig gaten zitten, die alleen ontdekt worden door bepaalde mensen en als iemand een gat ontdekt, dan zal de kans klein zijn dat andere mensen dit gat ook ontdekken!

"een security-hole wordt ondekt omdat iemand de source doorbladerd opzoek naar bugs of gaten in de beveiliging"

Laatst een artikel gelezen over bug-hunters die weken achter elkaar random pakketjes naar microsoft server-software sturen, en dan wachten tot de boel crasht....

[Verwijderd]

de patch is er al, en de datum van het ding is 23 september. Applausje voor de apache developers!

overigens vind ik dat het nogal meevalt met het *veelgebruikt* van de module. Het enige waar de module veel voor gebruikt wordt is om sites die verplaatst zijn door te sturen. En de providers die dat doen hebben hopelijk mensen in dienst die de non-vulnerable rules gebruiken. En dan heb je geen enkel probleem.

[mavink]

En de providers die dat doen hebben hopelijk mensen in dienst die de non-vulnerable rules gebruiken. En dan heb je geen enkel probleem.

Maar aangezien niemand tot een week geleden wist welke rules wel of niet vulnerable waren... Ik heb net een paar servers zitten fixen.

[arjenk|IA]

Veiligheidslekken op een server worden zoiezo als veel ernstiger gezien als een lekje in de browser. De potentiele schade die Apache hierdoor op kan lopen is veel groter dan bij IE.

[Verwijderd]

Ik denk dat de schade miniem is. Een slecht CGI script op een webserver is veel kritieker, en ook die heeft minimale rechten op files.

Bij de explorer bug kun je *altijd* bij *alle* files, bij de Apache bug kun je *soms* alleen bij files die leesbaar zijn voor apache. Dus nooit een password, een bookmarks file, een belangrijk document of wat er nog maar anders gevoelig ligt.

[Ritch]

euh, ik vind een bookmark file nou niet echt boeiend en geloof ook niet dat je die op een server aan zult treffen

[Verwijderd]

stel je voor dat jij een zutje roze sites in de bookmarks file van je baas terug kunt vinden. Kun je toch mee gaan chanteren...

[ACM]

Daarom zal die baas het ook niet op zijn server neerzetten...

[Reinier]

Hey, is die tweede bug niet dezelfde als Anton een paar weken terug noemde? Hij had toen zelfs een voorbeeldje op z'n server staan...

[AntonT]

Inderdaad heeft deze bug al eerder op Tweakers.net gestaan. Namelijk in deze posting van 7 septemer.

Daar kon je ook testen wat er gebeurde via mijn eigen server. Let wel op dat je test.txt niet een zero-length-file maakt, anders blijven er vensters geopend worden.

Het is normaal dat je als je op de link op mijn pagina klikt, na de popup nog 2 nieuwe vensters geopend worden.

[Verwijderd]

Een cracker kan zich toegang verschaffen tot elke file op de server, ook die buiten de server- en documentroot.

Dit vind ik vreemd. Bij elke ietwat serieus te nemen webserver (lees: bijna elke standaardinstallatie) draait de Apache http daemon niet in rootmode, maar als gebruiker wwrun o.i.d.
Die gebruiker heeft ongeveer dezelfde rechten als een normale gebruiker (minder zelfs, hij heeft geen shell, geen homedir, etc.).
Dus kan Apache nooit bij bijv. passwordfiles komen, zoals Valium beweert (bij shadowed passwords, ook standaard bij bijna alle installaties).

Het lijkt mij dus niet juist om te zeggen dat je zo bij elke file kan.

Neemt natuurlijk niet weg dat het een bug is die eigenlijk niet voor mag komen. Maar goed dat er zo snel een fix is.<div class=r>[Reaktie gewijzigd door [TCT]Nexus]</div><!-- end -->

[ACM]

Euhm, in principe heeft die gebruiker wel een shell en homedir (meestal default gelijk aan de documentroot) en bij gebrek aan shell wordt "/bin/sh" meestal gebruikt.
Belangrijkste is dat die user geen password heeft staan, of disabled is oid...

En er zijn nog steeds unix installaties die het passwd file gebruiken (die "altijd" in /etc/passwd staat en world readable is) voor hun encrypted passwords.
Maja, je moet natuurlijk wel die mod_rewrite gebruiken etc etc...

Dat die fix er zo snel is is wel wat toeval... lijkt mij meer dat de bug vrij laat bekend gemaakt is... of ontdekt is.

apache 1.3.12 bestaat tenslotte alweer een paar maanden.
't Was gewoon weer tijd om een nieuwe te lanceren.

edit:

Humm even gecheckt. mod_rewrite draait blijkbaar standaard...

[Verwijderd]

Veiligheids lek bij IE5.5 niet zo errug??? Alleen als naam en locatie van bestand bekend is?? Goh, 80% gebruikt toch C:\WINDOWS of C:\WINNT als windir? ...

Kunnen ze zo bij je registry... En waar zijn de wachtwoorden ook al weer in bewaard? Juist. Gecrypt? Gooien we een woordenlijst tegenaan...

* 786562 bijl

[_JGC_]

Nog leuker:
windows directory staat in %windir%
dus als je ff een pwl bestand nodig hebt:
get %windir%\jandegroot.pwl
Leuk is dat. het maakt helemaal niets uit waar je het installeert, ze vinden die windir toch wel door die variablele.

[TumbleCow]

maar, het is wel een keertje dat de apache-lek stukke ernstiger is dan de ms-lek..

maar idd, hier komt het voordeel van open-source wel weer duidelijk naar voren, nog geen week later is het gat alweer gedicht..

[Verwijderd]

Als je je apache al in een chroot jail draait, ben je al pakken minder kwetsbaar voor deze bug.