Gepubliceerd: Woensdag 30 december 2009
Het puntkommalek in Microsofts webserver IIS 6.0 is geen kwetsbaarheid, maar slechts een 'inconsistentie', stelt het softwarebedrijf. Er komt dan ook geen noodpatch.
Toon volledig artikel
the IIS server must already be configured to allow both "write" and "execute" privileges on the same directory.
Dat is inderdaad wel een sterk punt. Ook al is het feit dat de puntkomma geïnterpreteerd wordt als deel van de bestandsnaam slordig, met een goede achterliggende configuratie zou het geen kwaad kunnen.
Ik dacht dat Windows gemaakt was voor domme lompe gemakzuchtige gebruikers die standaard alle rechten toekennen aan alle mappen en altijd als administrator werken? Nu gaat MS plotseling zitten verkondigen dat men dat eigenlijk maar beter niet zou kunnen doen!
IIS wordt echter meestal niet ingericht door 'domme lompe gemakzuchtige gebruikers'. Een beetje beheerder heeft meestal wel wat gezond verstand.
En toch verwacht ik dat het (Microsoft kennende) wel standaard aan staat.
Overigens zijn niet alle beheerders experts van IIS. Er zijn nog voldoende mensen die het out-of-the-box gebruiken. En dan blij zijn dat ze het draaiende hebben.
Een beheerder van zo'n IIS doos kan gewoon ergens een superuser zijn in een (klein) bedrijf. Dat wil niet zeggen dat hij er echt verstand van heeft.
De "out of the box" installatie staat niet op deze manier geconfigureerd. Standaard heeft IUSR_machinenaam (het account waaronder anonieme gebruikers binnen komen) alleen read-only toegang www mappen en alleen de administrators meer rechten. Om tot een kwetsbare configuratie te komen zul je de autorisaties van IUSR moeten verhogen en daar is meestal geen enkele reden voor. Andere mogelijkheid is als je anoniemen gebruikers onder een ander account laat werken, maar dan moet je dat account ook weer expliciet rechten gaan toekennen. Om dit te kunnen doen moet je IIS echter behoorlijk goed kennen en dan ken je (als het goed is) de consequenties.
Dank je voor je toelichting. Ik gebruik IIS zelf niet.
Ik ging eigenlijk meer in op de opmerking van Peter dat een beheerder automatisch een expert is.
Mijn ervaring is dat er genoeg gebruikers van IIS of MS producten zijn, die het werkend hebben maar de eigenlijke werking niet snappen en ook niet de behoefte of capaciteit hebben om zich er verder in te verdiepen.
Ik weet nog een betere: heel veel pakketten zijn geschreven met een shared hosting environment op het oog, en adviseren dus maar chmod 777 (win-equivalent weet ik ff niet maar is vast iets met rechtsklik > advanced ;)) te doen op uploadmappen enzo. B.v. woordpers (wat ik ook echt een afgrijselijk stuk duivelsgebroed vind) adviseert dat meen ik standaard voor z'n hele wp-content map (dus zeg maar, je weblog zelf).
Ergo: dit is hoe dan ook niet handig. Sws snap ik niet helemaal hoe die upload dan ge-execute zou moeten worden, da's vast iets windowerigs. Heb je daar execute-rechten per map ipv per bestand? Nee toch? Peter, weet jij dat misschien?
Peter, weet jij dat misschien?
Niet echt met zekerheid. Volgens mij draait het er om dat je een asp bestand kan uploaden en dat vervolgens via de browser kan laten uitvoeren. Op dat moment wordt het door de server geïnterpreteerd en zou je dus informatie van de server kunnen trekken waar je normaliter geen recht toe hebt.
Ah zo. Maar dan vind ik het ueberhaupt een vreemd verhaal, want het lijkt me aan de site zelf om te besluiten of een upload geaccepteerd wordt. Stel dat ik een CMS bouw en ik wil dat de beheerder ook custom PHP kan toevoegen...
Als dit idd het geval is gaat het er dus alleen om dat IIS (kennelijk?) dergelijke uploads standaard tegenhoudt (for fsck's sake, why???) en dat hier dus misgaat. Dan is het in elk geval een crappy feature die gevaarlijk buggy is, want de meeste programmeurs zullen hierop vertrouwen en ervan uitgaan dat de upload veilig was.
Maar wanneer leren ze daar in Redmond nou eens dat je naar het mime-type moet kijken, niet naar een (volstrekt arbitraire) extensie?
Stel dat ik een CMS bouw en ik wil dat de beheerder ook custom PHP kan toevoegen...
Ik neem aan dat je dat niet wil toestaan aan een gewone user. Als je vanaf buiten dingen wil kunnen toevoegen doe je dat of via een script die de input controleert en interpreteert, of je gebruikt een ander user account met hogere rechten.
Ook met PHP kan ik me niet voorstellen dat je willekeurige custom PHP wil laten uploaden en uitvoeren door je bezoekers.
Mag ik vragen hoe je aan een betrouwbaar mimetype komt? Het content type in multipart/form-data wordt door de browser geleverd en is dus manipuleerbaar door de eindgebruiker.
Velen grijpen terug op content sniffing. Helaas is het zeer wel mogelijk een bestand te maken dat voor meerdere interpretaties vatbaar is: zo kun je eenvoudig een valide plaatje maken dat toch nog door de PHP interpreter kan worden uitgevoerd.
Content sniffing in IE6 en 7 is zelfs de bron van een hoop XSS lekken.
IIS wordt echter meestal niet ingericht door 'domme lompe gemakzuchtige gebruikers'. Een beetje beheerder heeft meestal wel wat gezond verstand.
Haha, ik moest hierom lachen, want er zijn helaas ook voldoende beheerders die ook dom, lomp en gemakzuchtig zijn.
Microsoft heeft gratis tools die je kunt gebruiken om de veiligheid te scannen (Exchange Best Practices Analyzer, SQL Best Practices Analyzer, Baseline Security Analyzer, etc).
Veel beheerders gebruiken dit helaas nooit, terwijl ze dit juist na elke change zouden moeten doen.
Haha, ik moest hierom lachen, want er zijn helaas ook voldoende beheerders die ook dom, lomp en gemakzuchtig zijn.
Misschien. Ik ben ze gelukkig nog niet tegen gekomen. Maar goed, als je als beheerder de adviezen van de software negeert en bewust je systeem open zet, dan kan ik het geen securityprobleem van de software meer noemen. Dan is het een 'User error'!
Microsoft heeft gelijk. Een bestand is een bestand. En of je dat mag uploaden of downloaden hangt niet van de naam af. Executeren is iets anders, maar dat is aan de serverhost om te beslissen. Iedereen toestaan om executables te uploaden in een voor de server executeerbare directory lijkt me geen goed idee.
Blijft over de vraag waarom ze uberhaupt de filenaam scanden.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
