Het is toch te triest voor woorden!

Uhmmm, was dit lek al niet veeeeeeeeeeeeeeeeeel eerder bekend?
14 Aug. 2005 -- http://www.securiteam.com/windowsntfocus/5EP0E15GKE.html

Greetingz,
Jacco

ehm..
noscript rules........

Tja, om noscript te gebruiken zul je gebruik moeten maken van Firefox.
Het beschreven lek had natuurlijk ook in FF kunnen bestaan, echter dan had het met noscript zeker worden tegengehouden (tot de gebruiker de pagina zelf actief had gemaakt).

-RB

Of gewoon een andere shell gebruiken voor IE.
Dan kun je javascript per pagina in/uitschakelen.

Veeeeeel beter dan Fire(the)Fox :P

Nu heb ik deze java-exploits uitgeprobeerd met IE-8, maar geen enkele javacode wordt uitgevoerd. Misschien een aanrader voor IE-7 gebruikers - indien mogelijk - te upgraden naar IE-8 RC1

Voor Windows XP nederlands
http://www.microsoft.com/downloads/details.aspx?FamilyID=821025fe-9adf-487e-b58c-561b7c8c25db&displaylang=nl

Voor Windows Vista en Windows Server 2008 Nederlands
http://www.microsoft.com/downloads/details.aspx?FamilyID=8e31391b-91b2-40c4-8643-7b70d1d5628b&displaylang=nl

Let op! Na installatie van IE-8 is deze niet meer te de-installeren.

Leuk om te weten dat IE8 hier heel goed mee omgaat. FireFox doet het ook hoogst redelijk, maar ik vind dat IE8 in het tweede voorbeeld uit het bronartikel het toch beter doet, Als de extensie, het mimetype en de signature niet allemaal met elkaar kloppen, dan wordt het plaatje helemaal genegeerd. Jammer als het een vergissing van de webdesigner betreft, maar veiligheid gaat voor.

Huh? Volgens de releasenotes is het verwijderen wel mogelijk!!

Toegegeven: het is niet altijd triviaal, maar er staat wel een recept in de releasenotes.

@Peter V:

DIt is natuurlijk niet echt een oplossing, Microsoft moet deze bug gewoon fixen.
Overigens is het geen java en javacode, maar javascript, dit is een zeer, zeer groot verschil

Dit is een veel ouder probleem die in Windows zit in gebakken. Verander je de extensie dan veranderd ook de functie van een bestand. Omdat dit vervelend is hebben ze IE inmiddels zo slim gemaakt dat deze het weer terug veranderd. Jammer dat minder goedwillende dan allerlei scriptje in een bepaald bestand kunnen stoppen. Oplossing is of de ene functie er uit haal of de andere.
Of IE weg gooien en verder gaan met FF

Het werkt alleen wanneer de url naar het plaatje rechtstreeks wordt gebruikt en niet via een html-tag. Hangt het uitvoeren van Javascript overigens niet af van de zone waarin de url zich bevindt?
Het automatisch uitvoeren van alles dat het binnenkrijgt, maakt Windows tot een makkelijk doelwit voor malware. Want malware werkt alleen als het eenmaal gestart wordt.
Als genoeg mensen linux of OS/X gaan gebruiken, gaan die systemen vanzelf spontaan zomaar opeens ook vanalles uitvoeren. Daarom dus.
Is Lamaar op vakantie trouwens, of is-ie eindelijk eens cklepels aan het zoeken?

Mjah en dat is nu juist zo jammer :-)

Peter (dit is al veel vaker tegen je gezegd), het gaat hier om JavaScript, het heeft NIETS met Java te maken.

Inderdaad lost IE8 dit probleem op doordat deze (bij het ontbreken van een Content-type specificatie door de server) niet meer stronteigenwijs op basis van de inhoud van een bestand het bestandstype vast probeert te stellen i.p.v. meteen naar de bestandextensie te kijken). Overigens, dat IE8 met standaard instellingen niet kwetsbaar is voor de hier genoemde aanvallen staat ook in de [url=http://www.heise-online.co.uk/security/Risky-MIME-sniffing-in-Internet-Explorer--/features/112589/1]tweede pagina[/url] van het Heise artikel.

Heise meldt ook dat mensen die niet naar IE8 willen, maar wel XP met minstens SP2 hebben (IE6 of IE7 neem ik aan), dit "sniffen" van bestandsinhoud kunnen uitschakelen: ga naar "Internet Opties", "Beveiliging", "Zone Internet", en scroll naar "Diversen". Daarbij staat "Bestanden openen gebaseerd op inhoud, niet op bestandsextensie": als je dat uitzet wordt wel naar de bestandsextensie gekeken. LET OP: Heise wijst er op dat dit best wel eens andere, oude, kwetsbaarheden zou kunnen her-introduceren (maar zegt niet welke). Het is dus de vraag of dit netto wel verstandige maatregel is.

Hoewel zeker ook niet feilloos hou ik het toch maar op Firefox + NoScript + FLashBlock...

Wat je precies bedoelt met die laatste regel weet ik niet, maar voor zover ik weet wordt er nooit iets terugveranderd. En bovendien begrijp ik niet wat er "slim" aan is dat IE ouder dan 8 bestanden snifft, want Microsoft heeft met MSIE8 kennelijk eindelijk ingezien dat dit geen goed idee was (dit is geen verwijt aan jou hoor, maar aan MS).

Ik snap het plan hiermee voor Internet Explorer sowieso niet, want Explorer doet dit niet: als ik "Blah.doc" hernoem in "Blah.txt" en dubbel-klik er op, dan opent het in Notepad en niet in Word. Dus het argument dat [url=http://msdn.microsoft.com/en-us/library/ms775147.aspx]dit[/url] zo handig zou zijn werkt niet of nauwelijks in de praktijk. Onbegrijpelijk dat het 4 versies van IE en allerlei exploits heeft moeten duren voordat MS het licht ziet.

Dat is niet zo moeilijk te raden: als Windows gaat raden wat het bestandtype is, dan zal het daarvoor code moeten gebruiken, bijvoorbeeld die van Office. Iedereen weet dat Office gatenkaas is.

In de advisory staat dat IE 6 en ouder "kwetsbaar" is. Nu is het ook nog eens zo dat scripting in IE standaard wordt uitgevoerd, dat beperkt het gebied tot die gevallen waar scripting uitgeschakeld zou moeten zijn. En daar lees ik niets over (ik heb ook geen zin om het te proberen).

Is hier wel sprake is van een vulnerability? Extensies zijn sowieso geen indicatie van de inhoud, dat is algemeen bekend. Script worden ook wel geladen zonder dat ze in bestanden met bepaalde extensies zitten. Het voorbeeld is overigens niet eens een script maar gewoon een stukje HTML dat een script bevat.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1 zegt:

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

Met andere woorden, als de content type aanwezig is dan is dat meteen definitief. In IE (<8) wordt dus ambiguiteit afgehandeld waar de HTTP/1.1-standaard geen ruimte voor biedt. Foute mime-types zijn gewoon fout, en dat moet aan de serverkant opgelost worden.

En kennelijk heeft iemand bij Microsoft het ook nog eens op een kromme manier geïmplementeerd. Als de signature (eerste paar bytes) de mime-type tegenspreken wordt naar de inhoud gekeken. In de voorbeelden is dat die signature (voor PNG en BMP), wat binaire data en commentaar met html-tags. Aangezien HTML niet met een signature voor PNG of BMP hoort te beginnen lijkt het mij duidelijk dat de signature leidend moet zijn. Er is geen ambiguiteit, maar het is afgehandeld alsof die er wel is.

Het 'file'-commando van Unix/Linux identificeert de files wel goed. Die kijkt naar signatures ('magic numbers') om binaire files te herkennen. Lukt dat niet dan wordt gekeken of het tekst is, door eerst te proberen een character encoding te herkennen, en als dat lukt te kijken of het type tekst herkend kan worden, bijvoorbeeld HTML.

Dit lijkt me een bug die eenvoudig te verhelpen is door domweg niet verder te kijken als een file een herkenbare signature heeft.

Dat wordt hier waarschijnlijk niet bedoeld, immers in de standaard instelling (van MSIE 4,5,6,7) kun je iemand een bestand via een URL met op het einde ".txt", met daarin MS Word inhoud, laten downloaden: MSIE zal dan ofwel op basis van het door de server meegegeven content type, ofwel op basis van de inhoud van het bestand, MS Word starten. Dit staat dus los van file extensies.

Heise suggereert dat je, door MSIE niet meer naar het content-type of de inhoud te laten kijken maar uitsluitend naar de bestandsextensie, oude bugs zou kunnen herintroduceren. Mogelijk dat ze hier op social engineering doelen. Denk bijvoorbeeld aan ".hta" files, de meeste gebruikers hebben er geen flauw benul van dat je daar net zoveel (kwaad) mee kan als met een .exe file.

Correctie, t/m IE7.

Naast ActiveX heeft met name het [url=http://www.heise-online.co.uk/security/services/browsercheck/adapt/iezones.shtml]MSIE Zone Model[/url] in het verleden voor veel ellende gezorgd, doordat telkens opnieuw [url=http://en.wikipedia.org/wiki/Cross-zone_scripting]Cross Zone Scripting[/url] attacks mogelijk bleken. Of bij de Heise demo de Javascript code in een meer vertrouwde zone wordt uitgevoerd (en dan meer mag, bijv. file-I/O op je schijf) weet ik niet. Microsoft heeft de laatste jaren wel steeds meer dichtgetimmerd in dit model, maar nog steeds niet toegegeven dat het, net als ActiveX, van het begin af aan een slecht idee was (in elk geval uit security oogpunt).