Mozilla en Firefox kwetsbaar voor user interface spoofing

Beveiligingsfirma Secunia komt met een security advisory voor Mozilla en Mozilla Firefox, die vergelijkbaar is met die voor Internet Explorer die het bedrijf een aantal maanden geleden publiceerde. De vergelijking zit hem in het gegeven dat zowel Mozilla en Mozilla Firefox websites niet hinderen in het includeren van zogenaamde externe XUL-code (XML User Interface Language) in webpagina's. Hierdoor kunnen beide browsers voor een groot deel overgenomen worden vanaf de webserver die de pagina serveert.

De security advisory noemt als voorbeeld een PoC (Proof of Concept) exploit voor Mozilla Firefox die al is gepubliceerd. De PoC simuleert een SSL-beveiligde PayPal-website. De kwetsbaarheid is voor versie 1.7 van Mozilla en versie 0.9.1 van Mozilla Firefox voor het Linux-platform vastgesteld. Voor Windows is het voor Mozilla 1.7.1 en Mozilla Firefox 0.9.2 vastgesteld en voorgaande versies kunnen ook gevaar lopen. De oplossing die geboden wordt is het niet klikken op links van onvertrouwde sites.

Reacties (85)

Of het nu een bug is of een feature, het is een security issue en dat moet gewoon opgelost worden. Out of the box! Dat zou gedaan kunnen worden door altijd de status bar en locatie bar te laten zien (zodat je dus ook weet op welke website je bent). De locatie bar heeft meer toegevoegde waarde dan de menu bar.

Het is in ieder geval geen XUL bug. De reden dat het met XUL genoemd wordt is omdat het makkelijk te prrogrammeren is. De Firefox interface wordt met XUL gerenderd. Met HTML kan het namelijk ook gewoon: http://www.pikey.me.uk/mozilla/test/spooftest.html

Ik geloof dat met het wil oplossen door een dialoog box aan de gebruiker te tonen als een website een XUL applicatie wil starten (dus bij elke remote XUL applicatie).

Verplichte leesvoer: http://bugzilla.mozilla.org/show_bug.cgi?id=252198

mja, denk je niet dat de kwetsbaarste mensen toch wel aldoor op OK zullen klikken zonder te lezen...?

Daar heeft Firefox tegenwoordig een mooie oplossing voor, de countdown button. Die wacht voor het instaleren van extensies 3 seconden.

En dat is misschien wel lastig, maar gezien je 3 seconden hebt en het niet erg vaak voorkomt. Lees je meestal toch een paar letters.

En als je zelf met extra bedenktijd nog stomweg op OK klikt, tja, das al net zo stom als lekker met je IPOD zwaaien om 1 uur 's nachts midden in een criminele buurt.

Je kan wel op cancel klikken in die 3 seconden, dus als je echt haast hebt is dat de "snelle optie"

Wat ik vooral interessant is hoe bedrijven een patch van Mozilla of Firefox kunnen uitrollen op pak-m-beet 1000 werkstations.

Dat is dus een kwestie van gymschoenen aantrekken en het pand doorrennen!

Fijn hoor zo een veilig en goed doordacht alternatief voor een webbrowser. Ik weet een betere: stoppen met Internetten (alleen jammer van Tweakers.net).

Dat kan heel simpel met een inlog script zo eentje uit de NT4 tijd bijvoorbeeld, simpel batch file die een zip file op de fileserver lokaal uitpakt. Klaar prefs, bookmarks etc blijven bewaard.

Moet de gebruiker daarvoor wel permissies hebben. Dat is eigenlijk niet gebruikelijk. Maar goed, startup policy oid kan ook

Dit is niet alleen een probleem van Mozilla maar van alle Niet Microsoft Windows software.

Bijvoorbeeld hoe update je Sun Jave voor hetzelfde aantal werkstations. Er zit gewoon een auto update in.

Ik denk dat tegen te tijd dat Firefox 1.0 uitkomt er wel iets als een Mozilla Auto update tool uitkomt. Of gewoon Msi bestanden.

Maar bij linux bijvoorbeeld is dit probleem er niet. Bij Debian komt hij gewoon mee met apt.

Eén keer aanpassen op je NetBoot image en al je workstations rebooten. Klaar...

Wat ik vooral interessant vindt is dat je een eigenschap van Windows probeert toe te schrijven aan Mozilla en Firefox.

Deze spoof is natuurlijk met hetzelfde gemak uit te halen met MSIE. Schakel een bar uit middels javascript, maak een nepper na in html/css etc., en spoefen maar.

Nee, in Firefox is het nog net iets makkelijker omdat de interface gebouwd wordt met XUL. Voor het immiteren van de menu's worden dus dezelfde bouwstenen gebruikt als voor de echte menu's: immiteren met scripts en plaatjes en html zal natuurlijk niet te voorkomen zijn, of je moet er al voor zorgen dat de standaard menu's altijd in beeld staan en niet uit te schakelen zijn voor bepaalde pagina's. Sowieso geen selcht idee, ik vind het nooit prettig als een pagina in een nieuw venster zonder menu- en adresbalk opent.

Inderdaad. Daarom is het nogal twijfelachtig of dit echt een bug te noemen is. Het valt een beetje in de categorie misleinde URL's en cross-site scripting. Je mag van gebruikers ook wel verwachten dat ze een beetje opletten en niet blind vertrouwen in wat ze voorgeschoteld krijgen.

Natuurlijk is het wel de bedoeling dat er dan ook verschillen zichtbaar zijn, maar dat zal altijd ten koste van de usability gaan. (De Java VM heeft bijvoorbeeld een waarschuwingsregel in door applets gegeneerde dialogs staan; dat zou met XUL componenten ook kunnen.)

Als praktische oplossing kun je natuurlijk gewoon instellen in Firefox dat 'ie altijd de toolbars laat zien; dan weet je zeker welke onderdelen van het venster bij Firefox horen en welke bij de website.

Ik vind het trouwens erg sterk dat ze zelfs de dialog met de SSL certificate hebben vervalst (klik maar eens op dat slotje linksonder); als ik twijfel aan een website is dat het eerste waar ik naar kijk. Dat is dus onmogelijk in Internet Explorer; hoewel je met HTML/CSS/JavaScript wel de statusbalk kunt vervalsen, kun je er nooit een echte dialog mee bouwen!

Wel gek dat die spoof een heel andere theme gebruikt
Ook is de sidebar niet open

Inderdaad, ik heb bovendien ook een custom toolbar die niet wordt weergegeven. Maar hoezo is dit een kwetsbaarheid? Ik bedoel er is toch geen beveiliging omzeilt? Dit is toch geen bug !

Bovendien kan dit verholpen worden door in de user.js hetvolgende te zetten:

// Always display the menu in pop-up windows:
user_pref("dom.disable_window_open_feature.menubar", true);
// Always display the Navigation Toolbar in pop-up windows:
user_pref("dom.disable_window_open_feature.location", true);

je kan het ook makkelijk doen door in je adresbalk: about:config
te tikken en dan kan je gemakkelijk deze settings aanpassen, ipv het zoeken naar user.js
Maar idd dan zie je gelijk dat het fake is.

Thx voor die tip!

staat ook in die PoC die hier is gepost, men kan je prefs niet uitlezen, en dus niet alles precies mimic-en

dank @ penguinpower.

Ziet er komisch uit zo :-)
http://www.vankoperen.nl/temp/moz.gif

Grappig feit dat er nu weer aangeraden word om niet op onbetrouwbare links te klikken. Daar hadden de vorige keer (toen het lek in IE bekend was) de firefox en mozilla aanhangers nog zo'n commentaar op.

Wel vreemd dat de kwetsbare versies voor Linux / Windows verschillen. Lijkt me dat het om de zelfde sourcecode gaat?

Het is niet mozilla die dat zegt over niet op links klikken. En nee, de sourcecode voor windows anders dan voor linux is iets anders (compiler directives), dus de uiteindelijke code ook. Daarnaast geven ze aan dat het de versies zijn die ze getest hebben, en zo te lezen hebben ze voorgaande versies niet getest.

De Linux versies lopen wat achter qua ontwikkeling, niet dat 0.9.1 en 0.9.2 nu zulke grote verschillen zijn. (Lees dus net hierboven bij Thanatos dat er ook verschillen zitten in de source code)

Ik (firefox gebruiker) vind het niet klikken op links ook maar een waardeloze oplossing hoor Waar ik nu benieuwd naar ben is hoe snel, en of er een bugfix komt.

Mjah, het enige verschil tussen 0.9.1 en 0.9.2 is het oplossen van een probleem dat alleen in Windows bestond dus achterlopen met de ontwikkeling? echt niet.

Ik dacht, misschien hebben ze relatief lange tijd nodig om het te porten naar Linux. Maar als dat het geval is, is ook direct uit de doeken gedaan waarom de Linux versie nog steeds 0.9.1 betreft

Er is met andere versies getest. De fout kan in meerdere versies zitten (en zit daar dan ook hoogstwaarschijnlijk ook in)

Alleen werd het lek in IE door Advisory met licht-rood aangestempeld, terwijl het bij FireFox op geel blijft hangen..(zie link naar Advisory in origineel artikel versus link naar Advisory in doorlink naar IE-bug)

Wel vreemd dat de kwetsbare versies voor Linux / Windows verschillen.

0.92 was alleen een windows update, de nieuwste versie voor linux is nog steeds 0.91

Ik vind dit maar een spoof van niks. De default lay-out laat de bookmarks links bar zien, die in de "spoof" pop-up niet getoond wordt, omdat de bookmarks niet correct ingelezen worden. Ik heb mijn lay-out altijd aangepast, dus ik zie het zowieso meteen. Het browser venster is ook niet maximized, dat valt ook op, en iedere extension die je geïnstalleerd zou kunnen hebben zou de spoof verraden.

Al met al dus een zeer beperkt aantal users zullen hierdoor voor de gek worden gehouden, en dan moet de attack nog worden geïnitieerd vanuit een kwaadwillende website, met code specifiek voor Mozilla/Firefox ipv het veel meer gebruikte en makkelijker voor de gek te houden IE.

Het kan ook gespoofed worden met je huidige theme, die proof of concept doet het echter niet

In de bugthread staat er een voorbeeld van normaal gezien

Bij een Proof of Concept is het nooit de bedoeling om het concept perfect uit te werken maar enkel om een idee te geven wat met het concept mogelijk is.

direct linkje naar de PoC: http://www.nd.edu/~jsmith30/xul/test/spoof.html

goeie oplossing voor IE en Firefox:
Spoofstick - http://corestreet.com/spoofstick/

direct linkje naar de PoC: http://www.nd.edu/~jsmith30/xul/test/spoof.html

Nee dank je....

De oplossing die geboden wordt is het niet klikken op links van onvertrouwde sites.

hmm je zou kunnen zien of je browser het wel/niet doet op die site en de juiste maatregelen nemen het is maar een idee dan weet je meteen of je "openstaat"

en nu hoor ik iedereen zeggen hahaha ik draai lekker MIEX? sorry maar laat dat ff achterwegen ik draai het wel ja .. maar draai ook firefox

En bij mij zegt ie "XML parsing error" (moz 1.7.1).

En bij mij zegt ie "XML parsing error" (moz 1.7.1).

Dat klopt:

This particular demo does not work in the Mozilla Browser, but I know of no reason one could not be created.

wel cynisch die site, hey kijk deze browser is lek, indien je deze browser niet hebt, download hem dan nu

Met de NightlyBuild van Mozilla zou je dus een kersverse (misschien soms wat buggy) browser kunnen downloaden die al een oplossing bevat voor het probleem. Die update cycli van Mozilla is erg kort.

In de Trunk wordt nieuwe functionaliteit ontwikkeld, en ontstaan er nieuwe bugs. In de Branch worden zoveel mogelijk bugs geplet. Dus als er een bug opgelost wordt en je wilt geen buggy browser, moet je een branch versie downloaden

"Het ene denken of zeggen, maar het andere doen."

Dat noem je hypocriet.

Ik vraag me af hoeveel Mozilla-mensen die altijd "IE is lek!" (is het ook) nou gaan posten ""aaaaaach, dit wordt toch wel snel gefixed". Mozilla is ook lek, al zij het misschien minder lek dan IE, of er zijn nog veel lekken niet ontdekt. Elke software heeft wel zijn problemen.

(En oh ja, ik surf met Mozilla 1.71.)

http://bugzilla.mozilla.org/show_bug.cgi?id=244965

hmmm lijkt erop dat ie al gefixed is...
Bugzilla geeft aan dat het probleem gevonden is en dat die verholpen is

Het gaat niet alleen om die bug, zoals onder meer op de Proof of Concept-pagina is te lezen. Bug 22.183 is veel belangrijker, aangezien daar al het hele punt van UI spoofen via een eigen chrome-applicatie aangehaald wordt.

Daarom heb ik ook zo'n hekel aan popup windows die menubars en buttonbars niet laten zien. Zou willen dat er in iedere browser een feature zat waarmee dat uitgezet kan worden (zonder heel javascript en zo uit te zetten natuurlijk).

Volgens mij kom je in eender welke browser een eind met wat bitmaps en zo'n popup window zonder statusbar, knoppen en menu's...

Je kunt in Firefox een optie activeren dat Javascript niet met de statusbar mag rommelen. Die staat standaard echter uit (zie artikel). Deze spoof is zonder een dergelijke vorm van beveiliging inderdaad mogelijk op iedere browser, niet alleen op Mozilla (Firefox).

Apple Safari heeft zo'n mogelijkheid... Ik las ook dat de Mac versie niet vatbaar was voor dit XUL probleem. Allemaal aan de Mac

Het hele idee is juist DAT je remote webapplicaties kan bouwen met XUL. En het is al zo erg gelimiteerd dat wat betreft exploits er niets mogelijk is zonder dat de user z'n preferences in about:config aanpast. Dit lijkt wmb meer op een fake hotmail pagina.

Inderdaad, ik snap het probleem niet echt eigenlijk... Je kan hetzelfde doen in *elke* browser, gewoon met wat creatieve HTML, javascript en afbeeldingen.

Wat ze mss wel zouden kunnen doen is, zoals reeds aangehaald, een waarschuwingsregel onder remote XUL-apps zetten zoals java dat doet.