Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Mozilla: 'Exploit werd toch niet veroorzaakt door Internet Explorer'

Mozilla heeft toegegeven dat een recent ontdekt browserlek in Firefox niet alleen via een bug in Internet Explorer misbruikt kan worden. De opensourcebrowser blijkt ook zelf niet goed om te gaan met uri's, ondanks een update die het gat moest dichten.

Firefox logoAanvankelijk kreeg Microsoft de wind van voren, omdat Internet Explorer links die beginnen met 'firefoxurl://' ongecontroleerd zou doorsturen. Wanneer een gebruiker een gemanipuleerde link aanklikt, wordt in de uri verborgen javascript-code zonder enige verificatie van Internet Explorer verzonden naar Firefox en daar uitgevoerd. Uit nadere analyse van onder andere beveiligingsonderzoeker Jesper Johansson blijkt dat een aanval met gemanipuleerde uri's ook binnen Firefox zelf mogelijk is. De bug blijkt ook nog aanwezig in de onlangs uitgebrachte versie 2.0.0.5, zo geeft Mozilla-beveiligingsbaas Window Snyder toe. Het opensourcebedrijf belooft beterschap en zegt het lek diepgaand te zullen analyseren. Kern van het Firefox-lek zou de manier zijn waarop de browser aanhalingstekens in een uri filtert. Mozilla's bladerprogramma zou dit niet in alle gevallen correct doen, waardoor het mogelijk is om kwaadaardige code op een pc uit te voeren. Een nieuwe release van Firefox moet het probleem definitief en fundamenteel gaan oplossen.

Door

Redacteur

47 Linkedin Google+

Submitter: Remco Kramer

Bron: BetaNews

Lees meer

Reacties (47)

Wijzig sortering
Zou het niet en-en kunnen zijn (zowel IE alsook FF fout)? Immers, Trillian had er ook last van (dus dan lijkt het erop dat het ook aan IE ligt).

http://pro.tweakers.net/n...evoelig-voor-uri-lek.html

[Reactie gewijzigd door Maestro.mosjuh op 25 juli 2007 10:41]

Of het ligt aan FireFox.

Waarom zou Internet explorer, of welk ander programma dan ook (Trillian), een url die voor FireFox bedoelt is gaan controleren?

Als Internet Explorer deze link naar zichzelf zou sturen, dan moet IE die controleren (op het moment dat deze binnenkomt).
Volgens mij heb je het niet begrepen of ik heb het niet begrepen. Wat voor een type service is firefoxurl:// in tegenstelling tot http:// ? Die http:// en https:// dingen zijn geregistreerd en worden apart afgehandeld. De firefox:// of fluppyduppy:// of foobar:// worden allemaal afgehandeld mits geregistreerd. Zijn ze niet geregistreerde service typen, dan krijg je dit probleem.

Dit gaat blijkbaar dus mis in IE, in Firefox, en misschien andere browsers die dat ook niet 100% controleren. Wellicht is dit nou juist een feature om het ongestoort door te laten, maar blijkbaar krijg je toch problemen, dus moet je de duidelijk foute situatie afschermen voor misbruik.
"firefoxurl://" is iets wat firefox tijdens de installatie in de register van windows schrijft. Als jij bv in IE begint met "file://" dan gaat IE die uri aan de windowsverkenner geven (wat weinig verschil geeft door de integratie van verkenner en IE maar als voorbeeld). Dit doet "firefoxurl://" ook, de uri wordt doorgegeven aan FF.
Het is dus iets dat van FF is en niet IE. FF zegt tegen windows als de uri begint met "firefoxurl://" dan moet IE of verkenner of wat dan ook die uri doorgeven aan mij. Als FF er dan geen controle op doet is volledig de schuld van FF. Maar dat is maar mijn mening.

Ik zie niet in waarom IE rekening zou moeten houden met andere browsers, ik neem aan dat de mogelijkheid moet bestaan om een andere browser toe te laten maar om ook nog eens te zorgen dat de beveiliging van die browser in orde is gaat wat ver denk ik.
o mijn god,

weer zo'n weisneus die erover begint....
dan maar WEER het zelfde antwoord,

URI is een volledig openstaand protocol waarin ELK willekeurig programma ongehinderd z'n eigen manier van conecties enzo mag toepassen),
daarvoor is het natuurlijk NIET de bedoeling dat MS of wel ander bedrijf dan ook, gaat bepalen of jouw protocol goed is of slecht...

dat 't voor DE MEESTE URI's wel 'gemakkelijk' zou kunne zijn als MS de input data al even voor ze escaped, van quotes, en/of '<' danwel '>' danwel andere (veelzeggende) tekens, omdat ze nu eenmaal zelf te lui zijn dit op te vangen. Wil niet zeggen dat 't op een bepaald moment een obstakel zou kunne zijn, en een belemmering voor een of andere al dan niet toekomstige URI ...

zo zou ik 't ook niet op prijs stellen dat de verzekerings maatschappij mij gaat verplichten om, 50sloten op m'n voordeur te doen, omdat zei vinden dat het voor mij beter is dan een bewakings bedrijf inhuren... ' ik wil echter zelf wel bepalen - hoe ik m'n huis beveilig, - laat zei alleen maar zeggen of 't wel of nie veilig genoeg is,

kortom, laat IE de zooi gewoon open houden, en iedereen voor zich bepalen hoe ze hun input, veilig verwerken... JOUW protocol == Jouw verantwoording, == jouw keuze
Ja maar dat is nu net waar ik dus problemen mee heb: als ik van IE iets doorkrijg wŪl ik niet eens dat IE daar nog aan gaat lopen prutsen. Wat als IE alles dat IE niet vertrouwt eruit gooit, en ik nou juist net ergens gebruik van wil maken dat IE niet vertrouwt? Het is aan mij, de applicatie die de URL van IE ontvangt, om die URL niet te vertrouwen en te controleren, niet aan IE. IE dient de URL gewoon verbatim aan mij door te geven. Daarnaast: als IE die URL aan mij kan doorgeven kan iedere willekeurige andere applicatie dat ook. Ligt het dan ook aan de command prompt als die "onveilige" urls aan mijn applicatie doorgeeft?

Ik vraag me ook sterk af hoe er gereageerd zou worden als het andersom zou zijn: als FireFox URLs doorgeeft aan IE en IE dat niet zou controleren. Zou dan de eerste conclusie nog steeds zijn dat het de schuld is van FireFox? Ergens vermoed ik namelijk van niet...

[Reactie gewijzigd door Bugu op 25 juli 2007 11:42]

Yep, maar nu is dus bekendgemaakt dat Firefox die url's ÚÚk ongecontroleerd (naar zichzelf) doorstuurt, zodat je IE niet als 'dŤ oorzaak' kunt aanwijzen :)
Met gelukkig 1 verschil: Firefox laat de URL zien en vraagt of je 'm wilt uitvoeren.

Nu is het helaas zo dat veel mensen gefocussed zijn op een instemmend antwoord, veel meer veiligheid krijg je er dus niet door.

Wat ik overigens niet begrijp is dat men niet ook in de eigen code is gaan kijken, voordat men een uitspraak deed over de veiligheid van die code...
IE is hier niet in de fout. Microsoft kan moeilijk elke URI gaan controleren op fouten of blokkeren, want dan beslissen zij wat mag doorgestuurd worden naar andere programmas.

Stel wanneer IE regels begint op te stellen van wat mag doorgestuurd worden en wat niet, dan staat de opensource gemeenschap op zijn kop!

Nee, dit is duidelijk een fout in Firefox. (en Trillian)
Immers, Trillian had er ook last van (dus dan lijkt het erop dat het ook aan IE ligt).
Eh, nee. Dat iets ergens bij betrokken is betekent niet dat het ook de oorzaak ervan is.
Als je een URI handler op windows registreert dan weet je niet vooraf welke programma op basis van die handler je applicatie opstart als het een URI tegenkomt dat jou geregistreerde handler vereist.

Als je dus een URI handler installeert voor een bepaald protocol dan moet je rekenen op willekeurige ongevalideerde input omdat ieder willekeurig programma de handler kan activeren en niety slechts browsers. Ook instant messengers, email clients of Office prodcuten kunnen URI's tegenkomen in berichten, emails of documenten en op basis van ee ngeregistreerde handler voor die URI een ander programma opstarten. Omdat je niet van te voren weet welk programma de handler gebruikt kun je ook geen zekerheid hebben over welke validatie dat programma toepast en moet je dus zelf de URI valideren en natuurlijk niet zo maar willekurige scripting via een parameter toestaan.
Helemaal correct.

Stel je eens voor dat Internet Explorer alle html <script> tags eruit haalde, maar de gekoppelde applicatie helemaal geen browser applicatie is. Dan filter je dus invoer die de applicatie misschien wel wil hebben. In dat geval waren er evenveel reacties geweest hoe Microsoft zoiets kon doen. In dit geval is het inderdaad triest dat er zoveel commentaar is op het ongecontroleerd doorsturen.

[Reactie gewijzigd door YaPP op 25 juli 2007 11:31]

Je moet er echter wel van uit kunnen gaan dat een URI die doorgegeven wordt in ieder geval geen karakters bevat die niet in een URI mogen zitten, en dŠt is juist waar IE de mist in gaat. IE zet het karakter " niet om naar %22 als bv het protocol firefox:// is (maar wel weer bij http...) en dat levert problemen op als de URI handler de commandline gebruikt.

Bijvoorbeeld met firefoxurl://test">updater.exe kun je updater.exe overschrijven omdat de commandline wordt: firefox.exe "test">updater.exe in plaats van: firefox.exe "test%22>updater.exe".
Nee, dat is onzin. Het is input van buitenaf, en die moet je altijd valideren. Je mag er niet van uit gaan dat input correct is, of zelfs maar het correcte formaat heeft. Als de URI handler de commandline gebruikt, dan is hij zelf verantwoordelijk dat de input naar de commandline voldoet aan de eisen. De commandline interpretter op zijn beurt moet zorgen dat hij niet iets doet op basis van een commando dat nergens op slaat, want op zijn beurt is de input vanuit die handler natuurlijk input van buitenaf.

Je kan het leuk vinden of niet, maar de realiteit is gewoon dat je te maken hebt met hackers, en dat je dus je input moet valideren.

Overigens wil dit niet zeggen dat een programma als IE geen "nette" URI door zou hoeven geven als dat mogelijk is.

[Reactie gewijzigd door ATS op 25 juli 2007 11:49]

maar blijkbaar staat dat dus niet in de specs voor een URI...
Dat staat wťl in de specs van de URI, en inmiddels staat ook gewoon in de MSDN dat URI's as-is naar handlers worden gestuurd, en dat je dus de nodige maatregelen moet nemen om misbruik te voorkomen.

@abeker: dat is een domme, foutgevoelige oplossing. Je kan niet gewoon maar even de URI nog een keer gaan escapen, een geldige URI bevat namelijk mogelijk al geŽscapete karakters. Wou je dan de "%" in een URI die "%20" bevat nog een keer gaan escapen? Het enige wat IE zou kunnen doen is de URI valideren en 'm gewoon niet doorlaten als ie niet aan de regels voldoet, maar daar is het nu te laat voor.
URI's worden niet as-is doorgegeven, een spatie wordt wel geŽscaped maar " wordt niet voor alle protocollen geŽscaped (voor http wel, maar voor firexurl niet). Programma's moeten dus al om kunnen gaan met geŽscapete karakters, als ze dit goed doen is er ook geen probleem als IE wťl alles correct zou escapen.

En je hebt gelijk dat het het beste (of eigenlijk veiligste) is als IE foutieve URI's helemaal niet zou doorgeven, aan de andere kant zou je kunnen zeggen dat voor het gebruiksgemak IE zoveel mogelijk moet proberen te escapen. Of bij foutieve invoer eerst een melding geven dat de invoer niet klopt, een geŽscapete alternatief aanbieden en vragen om daar mee akkoord te gaan.

Maargoed, aangezien externe programma's niet altijd te vertrouwen zijn is het maar beter om protocollen helemaal niet meer via de commandline af te laten handelen.

[Reactie gewijzigd door abeker op 25 juli 2007 14:04]

URI's worden wťl as-is doorgegeven. Als jij een link maakt in de vorm van <a href="myuri:hier staan spaties in">click</a>, dan worden de spaties niet geescaped. Probeer het zelf maar. Start regedit, en maak onder HKEY_CLASSES_ROOT een nieuwe key genaamd "myuri". Geef die een lege string genaamd "URL Protocol". Maak daaronder de keys shell\open\command, met als default waarde voor command "cmd /K echo %1". Als je nu vanuit start->run of de adresbalk in explorer of IE tikt: "myuri:een uri met spaties", dan krijg je dat ook letterlijk te zien, zonder escapes.
Ah idd, je hebt gelijk. Ik typte die uri's gewoon in IE in en veronderstelde dat IE de URI doorgaf zoals hij werd weergegeven zodra je op enter drukt. Dus hij geeft een niet-geŽscapete versie door en laat een geŽscapete versie zien in de adresbalk (waarbij " dus soms wel en soms niet geŽscaped wordt).

Firefox geeft de URI trouwens precies hetzelfde door als IE, maar laat wel eerst een melding zien dat het mogelijk om een exploit gaat (tenzij een keer aangevinkt is dat het vertrouwd mag worden). Ben benieuwd hoeveel mensen dat echt lezen, snappen en niet domweg op OK klikken....
je zou bijna denken dat de heer window s. niet objeectief is mnet zo'n naam.

maar ff OT:

je hoort toch gewooon alle links te controleren die je binnen krijgt als browser? ik vind het aardig dat IE uberhaupt wil doorsturen naar firefox
niet alleen via een bug in Internet Explorer misbruikt kan worden
Het is alleen helemaal geen bug in IE, dit is gewoon een algemeen 'probleem' mbt URI handler, een ander programma kan niet weten wat wel en niet mag worden doorgegeven via URI dus moet die gewoon alles doorgeven. Het enige hoe dit opgelost kan worden is als er bij een URI handler specificaties worden doorgegeven van wat wel/niet mag worden doorgegeven. ofwel bij het registreren van een URIhandler zal er ergens ook info opgeslagen moeten worden wat wel/niet mag..
volgends RFC1738 is het VERPLICHT om karakters die mogelijk "onveilig" zijn of niet-standaard karakters te encoden, in dat geval is IE dus wťl schuldig.
Dat bestreft de originele URI op het moment dat deze samengesteld wordt. Eenmaal bestaande URI's mag je niet meer escapen omdat ze dan semantisch kunnen wijzingen.
Ik vind de uitspraak van Snyder eigenlijk ook misleidend...het probleem is en blijft een probleem van Firefox. IE heeft er zelf geen problemen mee, maar stuurt de firefoxurl:// vrolijk door naar Firefox. Het probleem kan aangezet worden door IE, maar het probleem an sich is een Firefox-probleem.
Veel van de URI'sop het internet zijn niet valide met niet gescapete karakters. Misschien moeten Microsoft en Firefox ook maar gewoon alle invalide uri's negeren en stapels internetpagina's onbereikbaaar maken ????
Zo zit het niet in elkaar, Mozilla werkt volledig los van IE, alleen heeft IE de mogelijkheid om code door te sturen naar andere applicaties (bv FF).
Als ik mijn post laat doorsturen door de TNT dan doen zij dat ook zonder in de inhoud te kijken. Ik ben verantwoordelijk voor het controleren wat ik binnenkrijg.

Als er een media-stream wordt doorgestuurd, kijkt IE ook niet of het wel goed is en stuurt dit gelijk door naar mijn mediaplayer. Die controleert of het ok is.

Ik denk dan ook dat IE niet echt blaam treft. Die is niet degene die moet controleren of het allemaal wel juist is. De ontvangende partij voor wij het bedoelt is hoort dat te doen.
In dit geval zou ik dan ook zeggen dat het probleem vooral bij Firefox ligt..
Totaal mee eens. Als je een pakketje krijgt met een bom erin en die ontploft, dan is de postbode het niet schuld.

Maar dit probleem zal je dus ook hebben met andere programma's die URI handlers gebruiken (inclusief onderdelen van Windows zelf).
Netjes dat ze zelf toegeven dat ze fout zitten :) Hoop dat ze het probleem snel oplossen.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*