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.

Aanvankelijk 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.

Reacties (47)

[Maestro.mosjuh]

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 24 juli 2024 21:13]

[frankvdtillaart]

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).

[VisionMaster]

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.

[kluyze]

"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.

[i-chat]

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

[aikebah]

De echte wijsneus zou hier ff verwijzen naar http://www.ietf.org/rfc/rfc2396.txt; Daar staat precies hoe een URI er uit MOET zien... onder andere staat daar te lezen dat het dubbele aanhalingsteken dat hier de problemen veroorzaakt valt onder de 'excluded characters'.

Overigens staat daar ook te lezen dat IE nooit en te nimmer mag escapen cq. unescapen. Maar dat hoeft IE ook niet.... IE hoeft alleen maar te valideren dat de URI voldoet aan de minimumeisen die RFC2396 stelt.... en dan zou het de gewraakte URI afgekeurd en niet verder verwerkt hebben....

Voila.... weg de exploit

URI is en blijft nu eenmaal URI en kan (zij het minimaal) gevalideerd worden.

Een schrijver van een programma dat aan windows vertelt dat een programma aangeroepen mag worden op een bepaalde manier als het protocol van de URI een bepaalde waarde heeft (firefoxurl / winamp / skype). Mag er rustig van uit gaan dat windows controleert dat de URI een valide URI is voordat windows de URI aan het programma aanbied.

Het programma dient zelf te valideren dat de URI voor het overige ook aan de verwachtingen voldoet (en dus voor het betreffende protocol een geldige URI is)

[Verwijderd]

voila, weg exploit een weg internet.
Stapels URI's op webpagina's voldoen niet aan die RFC.
Als IE of Mozilla die allemaal zou afkeuren omdat ze niet voldoen aan de RFC dan is er een groot probleem

[Kixtart]

Hoe ik het lees is het en-en, want IE stuurt het ongecontroleerd door en in firefox is de bug ook op een andere manier te misbruiken.

[Verwijderd]

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 Verwijderd op 24 juli 2024 21:13]

[Yoeri]

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

[Webgnome]

Zullen we het er dan maar op houden dat externe programma's zowel third-party als gewoon eigen dit probleem veroorzaken?

[Little Penguin]

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...

[chaos.be]

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)

[Olaf van der Spek]

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.

[Wim-Bart]

Net getest met Opera. En...... Zelfde bug. Opera zegt alleen "We moeten c:\......\firefox [parameters]" starten. Daarna gaat FF gewoon de fout in.

Dus gezien de reacties ligt het dus nog steeds aan Internet Explorer...... Dus niet.

[Verwijderd]

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.

[YaPP]

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 24 juli 2024 21:13]

[abeker]

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".

[ATS]

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 24 juli 2024 21:13]

[SuperDre]

maar blijkbaar staat dat dus niet in de specs voor een URI...

[.oisyn]

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.

[abeker]

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 24 juli 2024 21:13]

[.oisyn]

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.

[abeker]

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....

[svenk91]

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

[angelina]

de 'heer' is een mevrouw: http://en.wikipedia.org/wiki/Window_Snyder

[SuperDre]

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..

[Verwijderd]

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.

[elmuerte]

Misleidende headline. De exploit was toe te rekenen aan zowel IE als Firefox.

This morning, Snyder was forced to concede the point. "We thought this was just a problem with IE," she wrote. "It turns out, it is a problem with Firefox as well. We should have caught this scenario when we fixed the related problem in 2.0.0.5. We believe that defense in depth is the best way to protect people, so we're investigating it now."

Dankzij misbruik via IE zijn ze er achter gekomen.

[Tees]

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.

[Verwijderd]

IE geeft URI's door met karakters die er volgens de RFC niet in horen te zitten. IE zou deze URI's niet door moeten geven omdat het geen valide URI's zijn. Dit is een fout van IE, niet van Firefox. Firefox houdt zich blijkbaar óók niet aan de betreffende RFC. Dat is een fout van Firefox.

Conclusie: IE heeft een URI-bug waarvoor het verantwoordelijk is, en Firefox heeft een URI-bug waarvoor het verantwoordelijk is. De bug van IE heeft niets te maken met Firefox, en de bug van Firefox heeft niets te maken met IE.

[Verwijderd]

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 ????

[Wim-Bart]

Het doorgeven van URI's moet ongevalideerd. De client applicatie die de URI ontvangt moet dit afvangen.

Stel je maakt een webportal met één of ander wazige functie, een zeer doelmatige functie die wat dan ook doet. De gebruiker dient een toepassing te installeren (zoals bijvoorbeeld de citrix client).

In jouw webportal heb je URIs staan met de volgende syntaxis:

<A HREF="wordprocessingapp://opendialog?filefilter=*.docu">Open een bestand</A>
<A HREF="wordprocessingapp://savedialog?filename=Bestand nummer ëën.docu">Sla huidige bestand op</A>

Dan wil je niet dat de browser de uri gaat verminken en ben je zelf verantwoordelijk voor de controle op de doorgegeven URI.

URI handlers zijn namelijks niks meer en niks minder dan URI handlers. Zij bieden de functionaliteit om een eigen urihandler te koppelen waarbij de uri verwerking gedaan moet worden door de handler en niet moet worden aangepast door de toepassing die de uri moet doorgeven.

Dit zou namelijk neerkomen op een Console app die gestart wordt en dat de commandline interpreter zelf gaat bepalen welke letters er wel en niet mogen.

[Verwijderd]

Het geval dat je hierboven beschrijft mag niet, je URI voldoet dan niet aan de standaarden die gelden voor URI's. Een site met bovenstaande HTML zal dan ook niet door de betreffende W3C validator komen. Waar het hier om gaat is hoe de twee applicaties omgaan met dingen die niet zouden mogen volgens de standaarden - wat IE doet en doorgeeft kan dus vanalles zijn, en FF heeft hier maar mee om te gaan. Als FF iets verkeerds doet aan de hand van input die het krijgt, of dat nou rechtstreeks van een server is of van een andere applicatie - is dat een probleem van FF en niet van de zendende applicatie. In dat opzicht ben ik het dus wél met je eens.

[HANC]

Mozilla ontwikkelaars lijken niet zo blij te zijn met de componenten van IE waar Mozilla kennelijk gebruik van maakt.

Als dat zo is, waarom maken ze dan Mozilla niet zodanig dat het totaal onafhankelijk kan functioneren los van IE?

Is dit wellicht niet mogelijk ivm de integratie van IE en het Windows OS ofzo?

[edit: type foutjes]

[Reactie gewijzigd door HANC op 24 juli 2024 21:13]

[mars]

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).

[SunnieNL]

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..

[RHochstenbach]

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).

[i-chat]

blijkbaar is dit een designe keuze die door veel mensen anders gemaakt zou worden nu ze de nadelen van een ZO een open kanaal hebbe ondekt...

en misschien is het nu wel aan de DEV van vista SP1 of SP2 en later window nt7 ...
om het escapen - mee te nemen (omdat daar blijkbaar nu vraag naar is)...

op den duur zullen dan ook FF ... en alle andere app daar rekening mee (moete) gaan houden...

maar een IE fout is 't zeker nie...

[roy-t]

Het is geen open-kanaal, het komt bij een programma terecht, netzoals WMP kan controleren of een .wmv wel echt video inhoud bevat (en het dus afspelen kan) kan firefox controleren of een firefoxurl:// wel echt een firefox link bevat.

Om de postbode-bom vergelijking maar is door te trekken: de postbode brengt een pakketje met een bom naar een kantoor, bij het kantoor staat een agent die het pakketje aanneemt en controleert wat er in zit. (zo zou het moeten)

(ik vind het dus ook absoluut geen IE fout, URI's zijn eigenlijk het door programmas intypen van iets, IE typt in de balk van Firefox in wat er in de firefoxurl:// staat.. waarom de firefox devs nu zo raar doen dat als je zef format C: intypt dit niet gebeurt, en als IE dat voor je doet het wel gebeurd is mij een raadsel.

Een goede dev zou de afhandeling altijd via het zelfde weggetje moeten laten gaan, en geen afkortingkjes als de url toevallig ergens anders vandaan komt dan van de gebruiker.

[Neko Koneko]

Netjes dat ze zelf toegeven dat ze fout zitten Hoop dat ze het probleem snel oplossen.

[QubicX]

Volk wat maakt het in godsnaam uit,ik lees hier alleen dat jullie een zwarte schaap zitten te zoeken.In plaats daarvan wees gewoon eens happy dat ze de lek hebben gevonden voor allebei de browser,En dat de profs het gaan oplossen voor jullie.

Er is 1 ding wat ik zeker weet en dat is dat er vandaag of morgen weer een lek word gevonden voor allebei de browser en dat blijft nog wel voor eeuwen.