Browserlek veroorzaakt door combinatie IE en Firefox

Door een recent ontdekt lek in Internet Explorer is het voor kwaadwillenden mogelijk om via Firefox kwaadaardige code op een pc te draaien. Beveiligingsbedrijf Secunia bestempelt de bug als 'zeer kritiek', maar ziet ook Firefox als schuldige.

Voorwaarde voor het slagen van een mogelijke exploit is dat de gebruiker zowel Firefox 2.0 als Internet Explorer op zijn pc geïnstalleerd heeft. Het probleem zit onder andere in de manier waarop IE omgaat met het controleren van links. Indien een aangeklikte link begint met 'firefoxurl://', opent IE de concurrerende browser zonder enige verificatie van de uri. Met dergelijke uri's kan Mozilla's Chrome-framework misbruikt worden om zo via Firefox kwaadaardige code uit te voeren. Een gemanipuleerde link werkt niet wanneer deze in Firefox wordt aangeklikt, omdat de browser dan wel een controle op de meegeleverde parameters uitvoert. De fout is ontdekt door Thor Larholm. De beveiligingsanalist ontdekte vorige maand nog enkele kritieke fouten in Safari voor Windows. Volgens Larholm vertoont de door hem blootgelegde fout veel overeenkomsten met een inmiddels door Apple gedicht lek in Safari.

Ondertussen ruziën verschillende partijen over wie nu precies schuldig is aan de 'cross-browser-bug'. Microsoft ontkent dat Internet Explorer een fout bevat en ziet geen reden voor een patch, terwijl Larholm meent dat juist in IE de kiem voor een eventuele aanval reeds gezaaid is. Secunia ziet Firefox als de zwakke schakel, omdat de Mozilla-programmeurs niet goed nagedacht zouden hebben bij de ontwikkeling van de protocolregistratie. Daar lijkt een kern van waarheid in te zitten, want Mozilla heeft ondertussen laten weten dat het in de eerstvolgende update van Firefox de url protocol handler zal aanpassen. Een woordvoerder van het opensourcebedrijf benadrukte dat 'zonder patches voor IE' ook andere applicaties gevaar lopen. Daarnaast maakte Mozilla nog bekend dat de eerste bèta van Firefox 3 met zeker zes weken is uitgesteld tot 18 september.

Reacties (128)

[MMaster23]

het is GEEN fout van IE/windows want:

- developers mogen hun eigen protocols registreren. nuttige en vooral IM programma's doen dit: irc:// skype:// sip: etc etc

- microsoft kan nooit weten wat wel mag en wat niet in een protocol. bij eyebeam heb ik de sip: handler .. welke ongeveer zelfde werkt als bv mailto: .. de argumenten daarvan kan van alles zijn. dat is niet microsoft zijn taak. hoe kan hij het verschil weten tussen

skype://mijnnaam

en

irc://irc.tweakers.net/broodjeaap

welke is nou goed? de 1e .. 2e .. of beide ? ken nie ruike he


het is dus aan firefox om de input van hun firefoxurl:// protocol te controleren. SLECHT programmeerwerk van Firefox.

(/me heeft hekel aan FF fanboys die geen verstand van development hebben en gewoon meteen opkomen voor hun "in-kelder-gemaakte-****" en het liefste de "evil corporatie" de grond in boren. welke mongool ooit verzonnen heeft om IE bij deze fout te betrekken is ook niet al te snugger. populariteits act.)

Programming 101: check je input!

edit: typo

[Reactie gewijzigd door MMaster23 op 23 juli 2024 03:14]

[.oisyn]

Het vervelende hier is dat IE ongeldige URIs toelaat, zoals met spaties erin e.d.. Denk aan:
<a href='skype:" /shutdown'>shutdown skype</a>

skype:" /shutdown is geen geldige URI, maar omdat ze onaangepast door worden gegeven aan de ontvangende applicatie kun je er vervelende dingen mee doen, zoals extra commandline parameters meegeven zoals ik met de link hierboven al demonstreerde.

Echter, dit weet je van tevoren, dus hier kun je je voor indekken als je een dergelijke protocol handler maakt. Ook kan MS het niet nu even veranderen, omdat er allerlei applicaties kunnen bestaan die gebruik maken van deze "feature". Omdat Mozilla het had kunnen weten aangezien het al tijden zo werkt, hadden ze gewoon moeten zorgen dat het met de protocol handler gewoon niet fout kán gaan, wat betrekkelijk simpel is (denk aan: "firefox.exe /launch-uri %1" ipv "firefox.exe %1", waarbij je na de /launch-uri geen andere command-line parameters meer gaat parsen.)

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:14]

[SuperDre]

Dat is dus correct, want misschien WIL je er juist op deze manier gebruik van maken, omdat je bv programma's wilt starten vanuit een webpagina (denk aan intranet)..

[Little Penguin]

Gebruik maken van een mogelijkheid, waarbij zelfs Microsoft ontwikkelaars het niet eens zijn met de huidige Windows implementatie*, lijkt mij niet verstandig.

Ik blijf van mening dat MS alle embedded quotes in een URI moet escapen voor het aan de URI handler opgestuurd moet worden.

*: Als de Outlook ontwikkelaars hier wel mee eens zouden zijn, dan zou men er ook rekening mee gehouden hebben...

[Little Penguin]

Ook kan MS het niet nu even veranderen, omdat er allerlei applicaties kunnen bestaan die gebruik maken van deze "feature".

Microsoft pas t wel meer zaken aan waardoor ineens diverse andere applicaties niet meer werken - de onwil van MS nu verdedigen vind ik persoonlijk erg kortzichtig.

Verder als je gebruik maakt van een bug die er voor kan zorgen dat je/een applicatie mogelijkerwijs misbruikt kan worden dan moet je niet gaan klagen als de bug gefixed wordt.

Uiteraard is het wel zo dat, nu men bij Mozilla weet hoe Windows en Microsoft hier mee om gaan, er wel een oplossing voor het probleem gemaakt moet worden in Firefox.

Het is overigens niet de eerste keer dat er door browserfabrikanten een "fix" gemaakt moet worden voor een ontwerpfout in Windows... (zoals het onmogelijk maken van het aanroepen van de shell: URI-handler van Windows)

...maar omdat ze onaangepast door worden gegeven aan de ontvangende applicatie kun je er vervelende dingen mee doen...

En dat is een goede zaak, onaangepast doorgeven van de URI?
Het is nu alleen nog maar het wachten op een lek in Windows waardoor het mogelijk wordt om via de URL handler arbitraire commando's uit te voeren...

[Reactie gewijzigd door Little Penguin op 23 juli 2024 03:14]

[THAiSi]

Sorry maar het is dus nog steeds een beveiligings probleem van IE.

Want:

Ik kan in windows protocollen registreren aan een command line. dit is vragen om problemen. de vermelding van

[HKEY_CLASSES_ROOT\FirefoxURL\shell\open\command\@]
C:\\PROGRA~1\\MOZILL~2\\FIREFOX.EXE -url “%1″ -requestPending


is gewoon erg makkelijk om te misbruiken. Aangezien windows ook toelaat om via een ander soort call (ben ff naam kwijt) een programma te starten en parameters als berichtje naar die applicatie te kunnen sturen kan er geen misbruik worden gemaakt van de commandprompt en quotes.

Laat dan als je graag een protocol wil implementeren zoals ftp:// of skype:// of unreal:// of whatever alleen toe dat het via de parameter message gaat ipv 1 commandregel. Dat firefox het in dit geval ook niet goed checkt is idd jammer, maar er zijn meer protocoll listeners naast firefox die net zo goed hier problemen mee kunnen hebben.

En er is 1 iemand altijd de dupe, namelijk de gebruiker die tegen wil in ineens toegang verschaft tot zijn pc. Microsoft zou dus ook zijn verantwoordelijkheid moeten nemen en zeggen: eigen protocol implementeren is geen probleem, maar dat kan alleen op die message manier en niet via commandline. omdat commandline gewoon niet veilig is.

[comecme]

Die andere methode is DDE (Dynamic Data Exchange).

Maar MS start ook gewoon een executable hoor. Als je mailto:<emailadres> gebruikt wordt feitelijk
"C:\Program Files\Microsoft Office\Office11\OUTLOOK.EXE" -c IPM.Note /m "<emailadres>"
gestart.
Klik je op een link waarin mailto:a.a" /a "c:\windows\system32\cmd.exe staat, dan wordt dus
"C:\Program Files\Microsoft Office\Office11\OUTLOOK.EXE" -c IPM.Note /m "<emailadres>" /a "c:\windows\system32\cmd.exe"
uitgevoerd. dan geef je opdracht aan Outlook om een mailtje te creëren met Cmd.exe als attachment. Overigens gaat dit fout omdat outlook deze combinatie van argumenten niet accepteert.

Edit: Zie net dat als je /a weglaat het wel werkt.

[Reactie gewijzigd door comecme op 23 juli 2024 03:14]

[HarmoniousVibe]

Het is de schuld van beide, maar voornamelijk van Firefox. Het is volgens mij algemeen bekend dat je de inputvalidatie altijd zelf moet doen, en niet moet laten afhangen van de invoerders (bijv: gebruiker, ander proces, andere browser)

[SuperDre]

Ok, dan ligt de schuld ook bij Opera, en welke andere browser dan ook want daar gebeurd hetzelfde. Dan ligt de schuld ook aan de gebruiker, want die zou het zowaar zelf kunnen intikken via de commandprompt..

[Verwijderd]

Het is volgens mij algemeen bekend dat je de inputvalidatie altijd zelf moet doen, en niet moet laten afhangen van de invoerders (bijv: gebruiker, ander proces, andere browser)

Inderdaad. IE fixen is maar symptoombestrijding.
Je kunt dan nog steeds via andere methoden dezelfde bug in Firefox uitbuiten (bv door Firefox met de betreffende url vanaf de commandline te laten starten via een of ander scriptje).
Pas als de bug in Firefox zelf aangepakt wordt, heb je alle mogelijke situaties ondervangen.

Verder vraag ik me af of je uberhaupt van IE kunt verwachten dat deze een Firefox-url kan valideren. IE weet toch niet precies wat geldig is voor Firefox, en wat niet (of welk ander protocol je ook in een url kunt zetten)?
Is dat niet het idee van een URL/URI? IE moet alleen weten dat een firefoxurl:// naar Firefox toe moet, en de rest moet ie maar as-is meegeven, lijkt mij, want dat zou wel eens applicatie-specifiek kunnen zijn, en een IE-urlfilter is misschien anders dan een Firefox-urlfilter.... dus misschien dat ook goede urls dan niet meer gaan werken.

Ik vind het op z'n minst 'apart' dat men IE probeert te betrekken bij dit lek dat duidelijk in Firefox zit.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:14]

[Atmosphere]

maar as-is meegeven

Ja precies, als 1 parameter dus en niet als extra console parameter.

IE weet toch niet precies wat geldig is voor Firefox

Idd, en dat zou ook helemaal niet uit moeten maken waar het niet dat ze het langs hun eigen console sturen. En dat is dus eigenlijk het hele probleem in deze: Microsoft zet 'de deur open'

Firefox moet daarintegen ook gepatched worden daar deze dus gewoon ook niet checkt.

Samenvattend: Firefox heeft een behoorlijke security-bug echter deze kan uitmuntend benut worden dankzij deze 'feature' IE .

[DrBOB101]

Voorlopige oplossing (schakelt simpel weg de "firefoxurl" uit):

- Open "Explorer"
- Ga naar "Tools" > "Folder options"
- Selecteer het tab-blad "File Types"
- Zoek en selecteer "(NONE) Firefox URL"
- Klik op "Advanced"
- Selecteer "open" in de "Actions:"-lijst
- Klik op "Remove"
- Klik op "OK"
- Klik op "Apply"

[elect-ron]

Zeg DrBOB101, ik heb gedaan wat jij schreef....
Maar kan het daardoor zijn dat youtube het nauwelijks meer doet? (in FF)

[Despen]

Ik snap niet precies wat er zo gevaarlijk is aan deze "bug". Als ik vanaf IE een firefoxurl link klik, opent firefox met een vrolijke melding van: an external application must be launched en dan kun je alnog op cancel klikken.

Ben zelf geen programeur maar als iemand even kan vertellen hoe er precies code kan worden gedraaid via firefox op deze manier, be my guest.

[Verwijderd]

Ik weet niet wat voor bijwerkingen het heeft, maar voorlopig kun je beter de protocol handler deregistreren door de key weg te halen.
Zie: http://msdn2.microsoft.com/en-us/library/aa767914.aspx

*Zucht* : Voor de mensen die beweren dat firefox maar alle input moet controleren: dit kan niet, omdat de URI wordt omgezet naar een commandline aanvraag, waarmee firefox wordt opgestart. Firefox denkt dus dat het opgestart is door een gebruiker via de command line. Zie link hierboven voor hoe Windows protocol handlers afhandelt.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:14]

[.oisyn]

*Zucht*: voor jou nog een keer dan: commandline optie is niet de enige manier om je protocol handler te installeren, en bovendien is het dan nog steeds te controleren. Waar het om gaat is dat je andere commandline opties voor Firefox via de URI op kunt geven. Dat is toch echt een fout van firefox omdat ze niet goed controleren of dat gedeelte bij de URI hoort of niet. Door bijvoorbeeld scheidingstekens te gebruiken of een firefox URI alleen als laatste argument op de commandline toe te laten, kun je dit voorkomen.

Maar wat ook kan, is gewoon een shell object registreren wat de URI afhandelt, zodat er gewoon een functie wordt aangeroepen met de betreffende URI als parameter.

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:14]

[Verwijderd]

Het eerste gedeelte van je verhaal kan ik niet echt volgen(volgens mij ken ik maar een soort commandline opties, ik snap niet precies wat je bedoelt), maar volgens mij kun je best gelijk hebben dat het de fout van firefox is. Want de firefoxurl: gedeelte wordt als argument meeverstuurd. Dus firefox zou alle 'gevaarlijke' commandline opties kunnen negeren als het firefoxurl: ziet als protocol in zijn argument.

[Webgnome]

Zoals ik al eerder heb gereageerd :

Als firefox een commandline optie kan interpreteren kan firefox deze ook zeer zeker verifiëren..

[Verwijderd]

Verifiëren tegen wat? In dit geval heb je toch gelijk aangezien firefoxurl:huppeldepup wordt meeverstuurd(wat ik eerst niet had gedacht), maar zonder de firefoxurl: erbij zou firefox geen onderscheid kunnen maken tussen gebruiker die via cmd.exe typt of IE die firefox via een protocol handler aanroept. Dus ja je kan idd cmd argumenten interpreteren, maar dat je ze ook meteen kan verifiëren is een beetje onzin tenzij je bepaalde criteria meegeleverd krijgt om de verificatie te doorstaan(en die kun je niet altijd uit de commandline argumenten halen).

[roy-t]

maar firefox ziet wel wat het volgens de commandline moet doen, bijvooorbeeld

ga naar www.eenleukewebsite.nl

maar het kan ook zien dat er staat, Format C:

Ik denk dat het niet uit maakt of een programma weet of het zo door een gebruiker wordt uitgevoerd of niet, Firefox moet gewoon alleen internetsites e.d. afhandelen via de commandline en geen programmas kunnen runnen, (en al helemaal geen Format C: )

[BastiaanN]

Niet dat Format C: werkt op een standaard windows installatie, waarbij windows op die C: schijf staat, dan krijg je altijd nog een foutmelding dat het station ingebruik is en dat het niet geformateerd kan worden

C:\Users\Bastiaan>format c:
Het type bestandssysteem is NTFS.
Voer de huidige volumenaam in voor station C: Vista

WAARSCHUWING:
ALLE GEGEVENS OP HET NIET-VERWISSELBARE
STATION C: ZULLEN WORDEN VERWIJDERD!

De systeempartitie mag niet worden geformatteerd.

[mashell]

Firefox denkt dus dat het opgestart is door een gebruiker via de command line.

En sinds wanneer is dat een goede reden of geen controles uit te voren?

[Webgnome]

Het is volgens mij overduidelijk. Internet explorer forward het verzoek van een pagina naar Firefox/Mozilla dat deze dan slordig omspringt is niet meer Internet Explorer zijn probleem anders kan deze browser wel overal rekening mee gaan houden (en daar is geen beginnen aan).

Met andere woorden. Firefox devs: Bouw de verificatie van firefoxurl links zo dat het ook in dit scenario zijn werk doet en alles is opgelost.

[Niemand_Anders]

Les 1 bij development. Controleer ALTIJD alle externe input! Dit is inderdaad geen IE probleem. Firefox dient bij het uitvoeren van elk request (remote of lokaal) te controleren of de uri wel is toegestaan.

Maar zoals gewoon wijzen programmeurs altijd eerst naar een ander. Pas als er onweerlegbaar bewijs is, geven ze heel erg zachtjes hun fout toe. In mijn ontwikkel team heb ik daar een goede oplossing voor gevonden. Iemand die direct de verantwoordelijkheid afschuift en later toch de verantwoordelijke blijkt te zijn, wordt aan de virtuele schandpaal genagelt op het intranet voor twee weken.

Niemand zal boos worden omdat er iets fout gaat. Echter je verantwoordelijkheid uit de weg gaan zal door niemand worden getolereerd.

Dat andere applicaties dezelfde fout kunnen hebben, is nog geen excuus om het zelf niet op te lossen..

[Freee!!]

Dat ben ik niet helemaal met je eens. Internet Explorer geeft de URL zonder verificatie door. Dit betekent dat ook andere applicaties (voornamelijk concurrerende browsers) met dit soort problemen te maken (kunnen) krijgen.

[.oisyn]

IE hoeft de URI ook niet te verifieren want hij kan nooit weten wat voor een applicatie schadelijk is en wat niet. Hij kan hoogstens controleren of een URI aan de regels voldoet, maar als dat gedrag nu ineens verandert wordt betekent dat dat er mogelijk allerlei andere applicaties die rekenen op wat meer vrijheid bij URIs niet meer fatsoenlijk werken.

En in principe is het ook helemaal geen probleem - als app moet je gewoon sowieso altijd je input controleren, en als je dat niet doet dan is het je eigen schuld als het fout gaat.

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:14]

[Verwijderd]

Verdiep je er nou eens in. Miscrosoft dient dit te doen:

firefoxurl://ditiseen+"url

En dan moet er zoiets gebeuren:

firefox.exe -url "ditiseen \"url"

Zie je dat de strings escaped zijn?
Dit is wat MS doet:

firefox.exe -url "ditiseen" url

Tada. Microsoft staat toe dat je willekeurige argumenten aan firefox.exe meegeeft, terwijl de url protocol dat gedrag niet suggereert. Het is een security bug in IE.

Niet alleen firefox, maar ook andere applicaties die URL protocols registeren kunnen hier problemen mee krijgen!

[bazkar]

Met je laatste statement ben ik het eens. Het is slordig van UIE dat ze dit niet doen. Maar het is de verantwoordelijkheid van de maker van een protocol om te controleren of de input valide is.

Ik kan je laatste argument nl. ook makkelijk omdraaien: Niet alleen Internet Explorer, maar ook andere applicaties die het firefoxurl protocol doorgeven aan Firefox kunnen hier problemen mee krijgen.

Ik ben het met .oisyn eens dat je als maker van een algoritme te allen tijde je input dient te valideren.

[.oisyn]

Verdiep je er zelf eens in.

Stel Firefox registreert z'n url handler als "firefox.exe %1" (ik heb geen firefox dus ik kan het niet controleren). Mozilla wéét dat er mogelijk spaties inzitten, zo werkt die functionaliteit nou eenmaal. Dus kunnen ze zichzelf beschermen door "firefox.exe -url %1" te doen, zoals jij al zegt, en vervolgens de rest van de commandline te interpreteren als url, en niet als extra command line parameters als er toevallig een spatie in staat.

[humbug]

IE hoeft (in mijn ogen) de URI niet te controleren. Deze URI is een firefox eigen URI waarbij het gebruikte protocol door Firefox wordt gedefinieerd. Dit protocol (en dat van de x aantal andere) custom URIs kan veranderen. Je kan niet verwachten dat MS voor elk van die URIs complete parsers gaat maken (en bijhouden) terwijl het ontvangende programma (wat er alsnog niet vanuit kan gaan dat de zender het al gecontroleerd heeft) het toch nog een keertje moet doen. Controle door het zendende programma is dus zinloos en vragen om problemen

Vergeet niet dat we het niet enkel over browsers hebben ook bv soap en sip zijn geldige URIs. Nee, programma's moeten hun invoer parameters gewoon correct parsen en dat heeft firefox hier niet gedaan

[Verwijderd]

Nee, ze hoeven het niet te controleren. Ze dienen het CORRECT door te geven. Dat doen ze niet.

De bedoeling is dat de parameter in de url als string wordt meegegeven. IE escaped die string niet zodat je nog andere parameters aan firefox kan meegeven. Dat is voor lokaal gebruik de bedoeling. Het is MS die zich niet aan het URL protocol houdt.

[Webgnome]

Dan nog blijft het een zaak van de tweede browser om die aanvraag goed te behandelen (en dus eerst een security verificatie uit te voeren ). Waarom controlleerd een browser, firefox in dit geval, de link wel als deze in firefox zelf wordt ingetikt?

[Verwijderd]

Omdat firefox het niet kan controleren, omdat de URL wordt omgezet in een commandline aanvraag, waarmee firefox kan worden aangeroepen met een -chrome optie, waarmee javascript kan worden uitgevoerd.

[.oisyn]

Firefox kan het wél controleren - ze kiezen namelijk zélf de manier hoe het wordt doorgegeven. Dat kan via de commandline, waardoor ze met bijv. afscheidingstekens kunnen zorgen dat er niet ineens andere parameters via de URI binnen kunnen komen. Maar ze kunnen er ook voor kiezen om het niet via de commandline, maar via een shell object te laten gaan, zodat je precies weet wat de doorgegeven URI is.

[Verwijderd]

Ook via de commandline zou er gewoon ge-escaped moeten worden!

[Webgnome]

Als firefox kan omgaan met commandline aanvragen kan het deze aanvragen ook checken.

[BramT]

Checken waarop? De commandline die firefox binnen krijgt is volstrekt legaal (volgens hun parameters). Dit is een o-zo bekende bug die in meerdere talen (mysql injection anyone?) terugkomt. Je parameters afbakenen met (dubbele) quotes werkt niet als je je invoer niet controleert. En de controle kan hier NIET door firefox gedaan worden. Ze kunnen het slechts zo maken dat je via commandline bepaalde (veiligheidsgevoelige) commando's niet meer mag gebruiken, of geen quotes meer in de url-handler maar andere manieren om dit veilig door te geven te implementeren.

Hoewel het natuurlijk niet erg handig is dat je kwaadwillende code's kan uitvoeren met een simpele commandline (commandline attacks worden zooo vaak gebruik), leg ik de fout toch ook bij microsoft. En dan niet bij de IE-tak, maar bij de manier waarop deze shell-commando's doorgegeven worden. Het lijkt me een ernstig kleine moeite om: indien een %x (parameter) tussen (dubbele) quotes staat, moeten evt (dubbele) quotes IN die parameter ge-escaped worden. Da's (gvd) 1 regel code!

[Verwijderd]

Eindelijk iemand die daarwerkelijk door heeft wat er aan de hand is.

[Verwijderd]

Nee! Het is volstrekt legaal. Ik moet in staat zijn firefox via de command-line een willekeurige chome uit te voeren.

Wat niet zou moeten gebeuren is dat microsoft via een url protocol TOESTAAT dat je een chrome-parameter kan doorgeven. Microsoft dient de quotation tekens in de url te escapen.

[Freee!!]

Dan nog blijft het een zaak van de tweede browser om die aanvraag goed te behandelen (en dus eerst een security verificatie uit te voeren ).

Dat ben ik volkomen met je eens. Mijn punt was slechts dat het probleem niet uitsluitend bij Firefox ligt, maar dat Internet Explorer zich er wel heel gemakkelijk vanaf maakt.

[i-chat]

en terecht, - in principe kan MS niet eens die check uitvoeren omdat ze 'in principe' helemaal niet eens 'kunnen' weten waarop ze moete checken,
elk programma dat links binne krijgt het zei via een klik of via een commandline of via <voeg zelf iets toe> dient gewoon te zorgen dat ze afdoende foutcorrectie uitvoeren,

[Countess]

implementeer dan heel die firefoxurl functie niet als je er geen tijd in wilt stoppen om het degelijk te maken.

[RM-rf]

msie heeft niks 'geimplementeerd' aan firefoxurl .....

het instellen van 'firefoxurl' als geregisteerd protocol gebeurt bij het installeren van firefox2.0 in het windows Registry... de explorershell is zo ingesteld dat het URI's die gebruik maken van een bepaalde geregistreerde URI doorgeven aan de betreffende applcatie volgens de rules die daarvoor in de Registry staan en welke door de registrerende applicatie ingevoegd zijn ...

in het geval van firefoxurl: is het Firefox welke die registry-entry schreef:
[HKEY_CLASSES_ROOT\FirefoxURL\shell\open\command\@]
C:\\PROGRA~1\\MOZILL~2\\FIREFOX.EXE -url “%1″ -requestPending

hierin zit de bug dat je een url mee kan geven met dubbele aanhalingstekens, waarna je de -chrome-flag oproept om lokaal bv javasscripts uit te laten voeren

[DJohn001]

Ik heb hier onder ook al ergens aangegeven dat er bij mijn niets gebeurde toen ik een paar tests had uitgevoerd. Nu las ik dit over die registery sleutel die door firefox toegevoeg word bij de installatie deze is ook bij mij toegevoegd. Maar voor de zekerheid heb ik het nog maar eens geprobeerd en ben naar de pagina gegaan waar het lek omschreven word http://www.xs-sniper.com/sniperscope/IE-Pwns-Firefox.html en heb de link geprobeerd te openen in IE 6 die zei dat hij de pagina niet kon openen en bij FF kreeg ik een venster zoals deze http://xs217.xs.to/xs217/07283/firefoxurl.jpg dus ik zie het probleem niet en zelfs als ik alles accepteer krijg word CMD.EXE nog niet uitgevoert.

Edit

ik gebruik FF2.0.0.4

[Reactie gewijzigd door DJohn001 op 23 juli 2024 03:14]

[Verwijderd]

Hier hoort er dus een string ge-escaped te worden!

[Verwijderd]

Ja, microsoft dient alleen netjes de url als een ge-escaped string door te geven. Helaas doen ze dat niet.

In principe is het bloedlink wat ze doen. Firefox zal niet de enige zijn die hier door compromized is.

[bazkar]

Nogmaals, dit is NIET het probleem van IE. IE is slordig, granted, maar het is een probleem van FF die zijn input behoord te controleren. Als ik een stuk software schrijf die dezelfde functionaliteit bied als IE (het doorpasen van een URL met firefoxurl protocol) dan blijft het probleem bestaan.

Het is algemeen good practise in de programmeerwereld om in principe alle soorten input te accepteren en hier zelf de foutafhandeling en validatie voor te doen in een algoritme. Je kunt nu eenmaal niet vertrouwen op het feit dat andere algoritmes of user-input altijd voldoet aan je verwachtingen.

[Ras]

Waarom controlleerd een browser, firefox in dit geval, de link wel als deze in firefox zelf wordt ingetikt?

Omdat het een protocol van firefox zelf is. Lijkt me vrij raar als ze er dan zelf geen rekening mee houden.

Ik kan het me overigens goed voorstellen dat microsoft ontkend dat IE een fout bevat op dit gebied, omdat ze niet elke keer als ze bij Mozilla iets nieuws hebben bedacht, zich daar op aan kunnen gaan passen.

[Reactie gewijzigd door Ras op 23 juli 2024 03:14]

[Webgnome]

Omdat het een protocol van firefox zelf is. Lijkt me vrij raar als ze er dan zelf geen rekening mee houden.

Waarom controleerd firefox de link dan niet als deze via een andere applicatie wordt door gegeven.

[Hero of Time]

@Webgnome:
Dat is nou juist het probleem, dat gebeurt dus niet.

Ik leg ook de fout bij FF. Als ik informatie zou hebben over een bepaald onderwerp en dat via een koerier naar mijn baas laat sturen, zou de koerier dan moeten kijken of de informatie wel klopt of moet mijn baas dat doen? IE is niets meer dan een messenger, en het spreekwoord zegt al, don't kill the messenger. Schuif dus niet alles af op MS, maar begin eerst eens bij jezelf te kijken. Want als je intern wel een check doet, waarom dan niet wat je extern krijgt.

[Reactie gewijzigd door Hero of Time op 23 juli 2024 03:14]

[Verwijderd]

Wel als de messenger het bericht VERKEERD door geeft. MS dient de url te escapen zodat het als 1 argument meegegeven wordt.

[Fiander]

dus jij verwacht dat microsoft van ELK programma wat eventueel opgestart word via IE, dat ze de mogelijke opstart parameters kennen ?

IE weet niet wat FF wel en of niet kan, en geeft gewoon het bericht door aan FF, aan FF om dan te kijken ofdat het geen onzin is.

[MrE]

Wat zou je er van denken dat jij controleerd of het bericht goed is?
Jouw baas mag er toch van uit gaan dat jij je werk goed doet? Of moet jouw baas iemand inhuren die controleert of jij geen fouten maakt?

Het probleem zit 'm niet in FF, want FF behandelt de link wel correct (dat wil zeggen er gebeurt niets).
Het probleem zit 'm niet in IE, want IE geeft de boel keurig door zoals gevraagd wordt.

Het probleem zit 'm in een afspraak tussen browsermakers. Daar lijkt zo te zien een verschil van mening te zijn over wie de controle doet.
Microsoft denkt blijkbaar dat de einduitvoerende de verantwoordelijke is, en Firefox gaat er van uit dat Microsoft zijn werk goed doet, en dit niet nog eens hoeft te controleren.

Een afspraak over afhandleing van dit soort zaken is wellicht meer op zijn plaats dan het roepen van eins schuld dit is.

[Verwijderd]

FF moet gewoon niks vertrouwen wat niet van hem afkomt... IE moet behandeld worden als een 'untrusted application'. Daarom moet alles worden gecheckt. FF's schuld dus..

[Verwijderd]

Firefox controleert de link niet. Firefox geeft de link alleen CORRECT door, ge-escaped en al! Microsoft doet dat niet. En laat dus (tegen alle bedoelingen in) toe dat je alle programma's die via URL-handlers openen elk willekeurige command-line optie mee kunt geven. Dat was nooit de bedoeling.

MS vergeet te escaped. Firefox niet. Er wordt niks gecontroleerd. Er wordt ge-escaped. Zoals het hoort volgens de specificatie van MS zelf.

[Kjoe_Ljan]

Zo begrijp ik het ook. Uiteraard zou FF net zo goed moeten controleren op URLs/sites die worden doorgestuurd door een andere applicatie, maar ik vind het ook erg slordig van IE dat ze niet eerst de URL verifieren.

[Verwijderd]

Volgens mij is dat inherent aan het systeem. Als Firefox een protocol handler installeert, en IE (Windows) reageert daarop, dan lijkt het me niet meer dan logisch dat IE er niets aan controleert, aangezien het ook niet zijn protocol is.

Hetzelfde zie je btw gebeuren met mms:// en skype://

[Verwijderd]

Ook voor mss:// en skype:// geldt dat de strings ge-escaped dienen te worden en als 1 geheel argument dienen worden meegegeven.

De bug zit in IE.

Vergis je niet. Het is niets firefox specifiek. Het is IE, die tegen zijn eigen specificaties in, strings niet escaped, waardoor je willekeurige argumenten kunnen toevoegen.

[Emielio]

Wat een zinloze bullshit discussie. Ze doen het gewoon samen verkeerd en moeten er iets aan doen. Wie zijn schuld het is, is totaal irrelevant en een zinloze discussie.

[witte1985]

dat deze dan slordig omspringt is niet meer Internet Explorer zijn probleem anders kan deze browser wel overal rekening mee gaan houden (en daar is geen beginnen aan).

Dus microsoft devs moeten er geen rekening mee houden, maar mozilla dev's wel. Dat slaagt toch op niets...

[jp]

Als het andersom zou zijn, zouden de mozila dev's er geen rekening mee moeten houden, maar de ms devver's wel.

Zoals al aangegeven: All external/user input is evil (tot je bewezen / gecontroleerd hebt dat t veilig is).

[Verwijderd]

Reactie van Mozilla: http://blog.mozilla.com/s...ocol-handling-on-windows/

Een patch zal dus hoogstwaarschijnlijk in Fx 2.0.0.5 zitten, waarvan de release rond 31 juli wordt verwacht.

Nou nog maar wachten op IE...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:14]

[Firefox]

Eig'k nie. Als IE checks gaat loslaten op dergelijke URI's wordt de functionaliteit van sommige tools waarschijnlijk gesloopt. Den aan bijvoorbeeld links om games automatisch te launchen met een auto connect naar de juiste server met de juiste game MOD (Halflife Counterstrike om maar iets te noemen)

Het is en blijft zaak van de applicatie die hiervoor gestart wordt om de boel goed af te handelen. Vanuit IE is het eigenlijk niets meer dan een documented feature waar andere apps gebruik van kunnen maken. Het alternatief is volgens mij gewoon te voorkomen op dergelijke protocollen te reageren, en dat komt de integratie weer niet ten goede..

(pff, is het een keer geregeld qua samenwerking, krijg je weer commentaar op het feit dat je er misschien meer mee kan )

[R-J_W]

Ik vraag me af waarom Internet Explorer hierbij genoemd wordt.
Want er zijn ook andere browsers die naast FF gebruikt kunnen worden.
En het lijkt me dat andere browsers dit soort links ook kunnen verwerken.
Is het nu zo dat FF dan de inkomende verzoeken wel controleerd, of controleren die browsers de uri's wel.

Wanneer dat zo is is IE wel degelijk medeschuldig, doordat ze een beveiliging die andere software wel levert niet toepassen.
Omdat IE zo specifiek genoemd wordt en de ontdekker gelinkt wordt met de ontdekking van beveiligingslekken in andere browsers, krijg ik de indruk dat dit probleem alleen met IE op treed.

Dus de mogelijke oorzaken:
1 IE is de enige browsers die dit soort URI's niet controleerd en Firefox controleerd geen op deze manier binnenkomende uri's
2 De Firefox developers hebben erg veel vertrouwen in IE en controleren hiervan binnenkomende verzoeken niet, maar andere wel.

Feit blijft dat FF een grove fout heeft gemaakt door deze input niet te controleren.

[roy-t]

Hier geeft mozilla aan dat het hun eigen fout is, dus waarom wachten op IE? :)\

Mijns inziens doet IE precies wat het moet doen, namelijk het door Mozilla in IE geinstalleerde stukje software uitvoeren op het moment dat het een firefoxurl krijgt.

[XIU]

En IE moet ook alle ftp:// urls checken of ze niet naar verkeerde servers linken voor deze doorgegeven worden aan een externe applicatie, en natuurlijk ook skype:// links etc

[hugoy]

Daar zit ik dan, met IE en Firefox, die ik allebei gebruik, en voorlopig nog geen oplossing Firefox toch maar deïnstalleren omdat IE breder ondersteund wordt? Wel een goeie zet van Microsoft

EDIT: ik heb het zojuist zelf geprobeerd, maar ik krijg alleen maar errors dat het misschien een zwakte in het systeem kan benutten (heb overigens dus gewoon niet de mogelijkheid om iets in firefox te openen in IE) zou dit misschien te maken hebben met het feit dat ik IE 7 heb?

[Reactie gewijzigd door hugoy op 23 juli 2024 03:14]

[FlowDesign]

Firefox komt inderdaad met een vraagschermpje voordat het iets raars uitvoert.

http://xs217.xs.to/xs217/07283/firefoxurl.jpg

[Verwijderd]

Zo te zien geeft Firefox niet die melding, maar IE. Dat zou betekenen dat IE er wél rekening mee heeft gehouden dat dit kon gebeuren. Meer dan zo'n foutmelding kunnen ze volgens mij redelijkerwijs niet doen. Alleen een beetje jammer dat firefox vast opgestard wordt voordat de gebruiker bevestigd heeft...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:14]

[lennartkocken]

En als je hebt ingesteld dat elke link naar een nieuw tabblad moet, krijg je oneindig veel meldingen

[erkje]

Ik heb eigenlijk nog nooit een link gezien die begint met firefoxurl://
Dus je moet expliciet zoiets aanklikken in internet explorer en dan moet het ook nog eens kwaadaardig zijn. Hoe groot is de kans dan? Voor dat kansje hoef je je hele systeem niet over de kop te gooien vind ik. laat FF lekker staan en zorg dat je'm binnenkort bijpatcht

[Verwijderd]

En als je de URI auotmatisch in een onzichtbare iframe wordt geladen?

[Fiander]

Dan krijg ik keurig netjes een melding dat de pagina een virus probeert op te starten.

[.oisyn]

Voorlopig?

Mozilla heeft ondertussen laten weten dat het in de eerstvolgende update van Firefox de url protocol handler zal aanpassen

Ik ben geen firefox gebruiker, maar zo lang zul je hier toch niet op hoeven wachten, of wel?

[TERW_DAN]

FF krijgt regelmatig updates, dus wat dat betreft zul je idd niet lang hoeven te wachten.

[Verwijderd]

Ik heb het net ook geprobeerd, er wordt mij om toestemming gevraagd en dan opent IE een Firefox sessie die weer om toestemming vraagt voor een volgende firefox sessie enzovoorts, enzovoorts. Er wordt uiteindelijk geen enkele site geopend.
Ik heb inderdaad ook IE7 en FF2.

[brobro]

't is toch alleen zo als je een link in IE opent die wordt doorgestuurd naar Firefox? Waarom zou je IE gebruiken als FF hebt geinstalleerd?

[R-J_W]

Moet ik dit serieus nemen?
Nou ja, Dus ...
Omdat je nog altijd sites tegenkomt die alleen goed worden weergegeven in IE.
Dit is meestal geen probleem, maar wanneer je het wel nodig hebt, zoals bij mijn studie om de roosters te kunnen bekijken. Omdat FF de pagina gewoon weg niet kan openen of verwerken.

Zolang er sites worden gemaakt die gebaseerd zijn op IE specifieke technieken zul je deze erbij moeten hebben en moeten gebruiken.

Daarbij moet je niet vergeten dat er ook mensen zijn die liever hun vertrouwde IE gebruiken. Terwijl iemand anders FF op die computer heeft gezet.

[Reactie gewijzigd door R-J_W op 23 juli 2024 03:14]

[timonb]

waarom zou je FF2 gebruiken als je IE7.0 hebt geinstalleerd. Uberhaubt waarom zou je FF2 installeren?

[EIo]

Omdat FF2 überveilig is

[jj71]

zou dit misschien te maken hebben met het feit dat ik IE 7 heb?

Nee hoor, ik heb hier een PC met IE 6 en FF 2.0.0.4 en ik krijg ook een schermpje met de
melding dat er een externe toepassing moet worden gestart om "firefoxurl:" koppelingen te openen, en dat dit misschien gevaarlijk kan zijn.

De bewering dat IE het zomaar zonder controle opent lijkt dus niet helemaal waar te zijn.

[R-O-Y]

Geldt dat voor alle versies van internet explorer? Ik heb namelijk niks geinstalleerd maar ik krijg 'm er wel standaard bij

[Red-Front]

Staat niet in het verhaaltje.. maar het is een screenshot van IE 7.

[Verwijderd]

Dit werkt ook onder IE6 net getest.

Firefox geeft inderdaad oneindig veel nieuwe tabs/vensters

dit is een bug in FF en niet in IE

[i-chat]

wat mij overigens op valt is dat men hier dus echt spreekt over een IE bugg (omdat de betreffende figuur toevallig in IE zat toen ik de bug vond, -

mijn vraag is: werkt deze exploit ook vanuit opera lynx of safarie, (waarschijnlijk wel) dus hoe men - bij IE bugg komt.....

[XIU]

Yup, zelfs gewoon rechtstreeks van de Run prompt... Heeft echt niets met IE te maken.