Mozilla 'herintroduceert' zeven jaar oude bug

Alle huidige browsers van Mozilla hebben opnieuw last van een inmiddels zeven jaar oude bug, die de browsers vorig jaar ook al lastig viel. Net als de vorige keer is deze bug bekendgemaakt door Secunia, een Deens beveiligingsbedrijf. Het betreft hier een frame-injectiebug, een variant van diegene die voor het eerst opdook in 1998. Wanneer er twee browservensters openstaan, kan kwaadwillende content van de ene site worden geopend in het andere venster. Dit wordt spoofing genoemd en is vooral gevaarlijk omdat de slechte content lijkt op een vertrouwde pagina. Wanneer de vertrouwde pagina bijvoorbeeld een bank of webshop is, kan de gebruiker per ongeluk zijn gegevens invoeren terwijl de kwaadwillende content geopend is en zo zijn wachtwoord of creditcardnummer vrijgeven. Het Deense bedrijf raadt iedereen aan om alle andere browservensters te sluiten, wanneer er een site bezocht wordt waarvoor persoonlijke gegevens moeten worden ingevoerd. Op de site van het bedrijf is een voorbeeldexploit te vinden waarmee getest kan worden of de gebruikte browser kwetsbaar is.

Reacties (89)

[Verwijderd]

Ik gebruik IE6 met SP2 maar bij mij krijg ik ook de "foute" website te zien.

[Theadalus]

Dat is een beveiligingsinstelling in IE, je kunt dit aan/uitzetten met de instelling: "Subframes door verschillende domeinen laten navigeren"

[Blokker_1999]

Maar het is niet zo slim om deze functie per default toe te laten.

[roalt]

Het probleem met beveiligingsinstellingen is dat ze vrijwel altijd functionaliteit beperken. Kijk maar eens naar je firewall: Heb je die wel eens uit moeten zetten omdat een programma anders niet werkte? Vast wel...

Dus het is altijd een spanningsveld: wat zet je aan en wat niet? Toch horen dit soort lekken niet voor te komen en is er op dit moment voldoende 'veilige' technologie zonder dat het direct de functionaliteit inperkt.

[BOOTZ]

Yep, zo te zien is IE6 ook vulnerable

[fondacio]

Klopt. De Secunia-advisory is hier te vinden.

Edit: dit heb ik overigens uit deze Slashdot-thread over hetzelfde onderwerp.

[Dreams]

Ik kan het ook niet vaak genoeg zeggen: "Gij zult geen frames gebruiken!".
<flame bait>
Als iemand beweert dat frames noodzakelijk zijn, dan is de logica achter de site niet goed opgezet. Ze zijn echt nergens voor nodig, behalve voor quick&dirty hacks.
</flame bait>

[Webdoc]

Echt ik wil niet moeilijk doen maar wat je hier zegt is gewoon nonsense. Frames zijn ontzettend handig voor heel veel dingen (zoals een menu dat altijd zichtbaar blijft, etc. etc.) dus om te beweren dat Frames slecht zijn, of, whats more, om te zeggen dat Frames van slecht design getuigen is totale onzin.

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

[srekaewt]

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

Slecht design dus.

Makkelijk op te vangen door aan de serverkant de pagina terug te serveren alsie niet valideert.

[Webdoc]

De pop up being a Javascrip alert. Server side controleren, daarna client side een Javascript alert tonen. Werkt uitstekend.

[EagleTitan]

Met JavaScript kan je ook gewoon onsubmit gebruiken, geen frames nodig hoor

[ShadowLord]

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

Slecht voorbeeld. Je kan beter een 'wijzig' knop maken die de data terugsubmit naar het invul form. Werkt minimaal even goed en, in mijn ogen, zelfs beter. En dat dat zonder frames!

Maar, het voorbeeld van een 'vast' menu gaat wel op en kan heel handig zijn. Aan de andere kant kun je hier voor ook heel goed een iframe gebruiken door de scrollbare data in de iframe zetten. Een iframe is niet gevoelig voor dit soort bugs.

[Verwijderd]

een menu dat altijd zichtbaar blijft is makkelijk te doen met de css tag position:fixed;

[sarcasme]of werkte deze nou niet in IE?[/sarcasme]

[MadEgg]

Je kan 'm natuurlijk ook laten submitten náár die popup, heb je de frames ook niet meer nodig.
Frames zijn onnodig, onveilig en lelijk. Ik sluit me volledig aan bij wat Dreams zegt.

[Verwijderd]

Je kan 'm natuurlijk ook laten submitten náár die popup, heb je de frames ook niet meer nodig.

Popup? Owwww, die dingen die geblokkeerd worden behalve als ik toestemming heb gegeven.

Ja, erg vriendelijk

[StainlessSteel]

@rklapwijk: Als je <form onsubmit="javascrtipt:popup();"> doet (de functie popup moet wel dan die popup maken), en je klikt op 'Submit', dan is dat toestemming geven.

En heb je liever niet een popup dan een miniscuul frame waar een geheime pagina inzit?

[Verwijderd]

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

[evenmoreflamebait]
Hiermee sloop je dus de navigatie zoals de gebruiker het wel gewend is, die wil bij een fout terug gaan. Tevens is het net zo makkelijk om naar dezelfde pagina te posten en daar je check in te maken, het is maar net hoe moeilijk je wilt doen, persoonlijk vind ik jou manier moeilijk...

Laat me gokken je gebruikt ook vaak frames om te zorgen dat je URL niet vreemd word voor de gebruiker maar gewoon 1 enkele frameset met een enkele frame zodat je altijd www.blaat.org houd?
Bedenk je dan maar alvast wat dat doet voor mensen die een linkje naar iemand anders willen sturen.

Lees het er maar op na: frame zijn zo gebruikersonvriendelijk als het maar kan zijn!


Ter illustratie:
http://www.google.nl/search?q=why%20frames%20are%20bad
[/evenmoreflamebait]

[Verwijderd]

Echt ik wil niet moeilijk doen maar wat je hier zegt is gewoon nonsense. Frames zijn ontzettend handig voor heel veel dingen (zoals een menu dat altijd zichtbaar blijft, etc. etc.) dus om te beweren dat Frames slecht zijn, of, whats more, om te zeggen dat Frames van slecht design getuigen is totale onzin.

Met 'layers' of '<div>'-tags is hetzelfde te bereiken, daarbij komt dat als je hiermee werkt je site nog steeds retesnel is en ipv voor (aantal frames+1) requests aan de server te zenden om te laden wordt dat (ex plaatjes) precies 1. Menu kan je ook netjes op de plaats houden, en je hebt het voordeel dat je alles mooi overzichtelijk in 1 bestand hebt staan.

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

+

De pop up being a Javascrip alert. Server side controleren, daarna client side een Javascript alert tonen. Werkt uitstekend.

Waarom laat je het niet clientside mbv javascript controleren? Een 'hidden frame' puur om alleen maar wat zooi in te gooien is in mijn ogen prutswerk. Forms controleren mbv javascipt moest ik pas nog voor een vak op school. Scheelt ook weer in werk voor de server.

[YaPP]

Waarom laat je het niet clientside mbv javascript controleren? [...] Forms controleren mbv javascipt moest ik pas nog voor een vak op school. Scheelt ook weer in werk voor de server.

Ik hoop niet dat je daarmee wilt zeggen dat je de server check achterwege laat.. Clientchecks zijn alleen nuttig om communicatie-overhead te verkleinen, niet om checks op de server uit te sparen.. Lekker veilige site

[Verwijderd]

Een menu dat zichtbaar blijft (bij een scrollende website) is in mijn optiek alleen maar irritant en niet meer van deze tijd.

Als je bijv. op een website naar beneden scrollt, dan onthoud je onderbewust waar het menu zich bevind. Je verwacht dat dat wegscrollt samen met de rest van de content. Dit gebeurd ook als je een krant of een boek leest, toch?

[Verwijderd]

Inscribed by Webdoc:
Echt ik wil niet moeilijk doen maar wat je hier zegt is gewoon nonsense. Frames zijn ontzettend handig voor heel veel dingen (zoals een menu dat altijd zichtbaar blijft, etc. etc.) dus om te beweren dat Frames slecht zijn, of, whats more, om te zeggen dat Frames van slecht design getuigen is totale onzin.

Frames = Bah, punt.
Probeer eens wat anders zoals bijvoorbeeld PHP's "require()" en wat losse bestanden (bijvoorbeeld het menu), je zou zelfs het menu dynamisch kunnen maken, de links in het menu ook, whatever, het kan met wat creativiteit. Ikzelf gebruik nooit frames Ik ontwikkel nu een fixed menu dat meereist met elke pagina die ik op een site hang, simpelweg door het op te roepen met require(), hetzelfde doe ik met de headers van elke pagina. Pagina zelf kan weer ingedeeld worden met bijv. tabellen die meerekken met de grootte van het browservenster, etc.
Het is maar wat je ervan maken wilt.

[RobIII]

Je kunt ook een XMLHTTP Request gebruiken. Niks frames. Stukkie javascript, dat dan weer wel
Overigens is dat alleen voor de wat modernere browsers weggelegd, maar IE5.5+, FF en Opera ondersteunen het allemaal prima.

[assembler]

bedoelde je niet per ongeluk:

<frame bait>

?

[kidde]

"Gij zult geen frames gebruiken!".

Helemaal eens! D'r houdt verdorie nooit iemand rekening met Lynx gebruikers, en frames zijn echt k*t in lynx! (Gelukkig heb ik nu links).

[YaPP]

Helemaal eens! D'r houdt verdorie nooit iemand rekening met Lynx gebruikers, en frames zijn echt k*t in lynx! (Gelukkig heb ik nu links).

Ik heb geprobeerd mijn site [codingdomain.com] in links weer te laten geven. Het gaat tot zo heel aardig dankzij het gebruik van XHTML. Maar het onderstaande geeft toch een idee waarom er bijvoorbeeld geen rekening gehouden wordt met Links:

Links liep in mijn site vast op de <dd><pre>...</pre></dd> opmaak. De hele marge wordt daarmee verpest. Mijn site heeft een heldere interne structuur en zaken als <dt>..</dt> (een definition-title) hadden eenvoudig door Links gehighlight kunnen worden. Nu heb ik er speciaal voor links een extra <em> ingezet om het een beetje overzichtelijk te houden. Tabellen op mijn vim-reference pagina werken ook totaal niet goed weergegeven, dat wordt een lange stroom van letters.

Toen heb ik het dus opgegeven. Links is leuk maar dus niet zaligmakend. Voortaan vind ik het leuk meegenomen als Links nog wat van normale XHTML code kan maken, maar besteed er niet teveel aandacht aan.

[Shaka]

Eh... en wat is het voordeel van lynx verder voor normale surfers? Ik was eigenlijk onder de indruk dat alleen blinden lynx gebruikten i.c.m een brailleprinter.

Maar ik kan me vergissen, dus als iemand het me kan vertellen?

[PanMan]

Ik heb zelf een site gebouwd met een fotostrip met thumbnails. Als daar op een foto geklikt wordt wordt die groot geladen, en blijven de thumbs openstaan in een ander frame. Als ik dit zonder frames had gedaan, werden die thumbs elke keer opnieuw geladen (los van caching). Of had ik een constructie moeten maken met layers en JS, die zeker bij minder mensen had gewerkt dan deze frames oplossing... Ik ben ook geen groot fan van frames, maar er zijn toch echt wel plaatsen waar ze een goede oplossing bieden.
Bovendien, ontopic, zijn frames zo veel gebruikt dat een browser er natuurlijk gewoon mee om moet kunnen gaan, en geen rare bugs gaat vertonen.

[comecme]

Een menu in een apart frame heeft als voorbeeld dat het met simpele html-code mogelijk is om een menu te maken. Natuurlijk kan je ook php gaan gebruiken of zo, maar bij het gebruik van frame's heb je gewoon één html-file met de frameset, één met het menu, en per pagina een html-pagina. Geen serverside scripting of wat dan ook, geen redundante gegevens, puur html.

[Garyu]

Ik weet het fijne er niet van, maar als deze bug al twee keer opgelost werd, hoezo zit ie er nu dan weer in? Is dat onoplettendheid van de ontwikkelaars, worden bugs zo slecht verwerkt, of is dit weer een nieuwe variant die er altijd al in zat maar nu pas aan het licht komt?

[Verwijderd]

Het betreft hier een probleem met communicatie tussen de vensters onderling. Aan de ene kant wil je sommige communicatie verbieden (zoals in artikel omschreven) maar aan de andere kant wil je andere communicatie weer wél toestaan.
Het is een beetje lastig om dat onderscheid te maken en daardoor kan het gebeuren dat bij een wijziging aan code een dergelijk gat weer op de een-of-andere open komt te staan.
Uiteraard wel slordig dat zoiets niet in geautomatiseerde test wordt opgevangen, aangenomen dat de exploit nog op dezelfde manier werkt als eerst.

[MBV]

Waarom hebben ze voor dit soort dingen geen geautomatiseerde regressietesten? Zeker als die bug al tig keer is opgedoken lijkt me dat erg handig...

[Stacium]

even een versimpelde test gemaakt:

www.xs4all.nl/~stacium/injecttest/

werkt hier met FF1.0.4

[red_indian]

Dat werkt want het draait allemaal op hetzelfde domein. Dat hoort dus zo te werken.

[veldmuis]

Dat firefox die pagina met vreemde tags sowieso laat zien zeg .
2x de head afsluiten, en de body en html gewoon niet? .

[Verwijderd]

raar, hierop gaat ook galeon in de mist, maar bij de originele test van secunia niet...

[RobIII]

Nogmaals: Omdat ze in hetzelfde domein zitten is het niet eens verkeerd, maar zo bedoeld.

[_JGC_]

Waarschijnlijk is jouw galeon gelinkt tegen een oudere mozilla build, die dit probleem nog niet had.
Op Archlinux bakken we al sinds een tijdje alles tegen firefox, waarbij alle embedded browsers dus ook last van deze bug hebben, inclusief galeon en epiphany.

De testcase van hierboven is blijkbaar niet geldig omdat XSS niet van toepassing is als slachtoffer en dader op dezelfde hostname gehost zijn.

[kidde]

Ook die werkt niet op m'n (Gentoo Linux) Ffox 1.0.4. Balen zeg!

[Verwijderd]

bij mij werkt het niet
(nieuwe pagina's worden automatisqch in een neiuwe tab geopend) maar als ik zelfs expliciet de pagina in een nieuws venster lukt je test niet
(Ubuntu Linux build)

[darkrain]

Met tabs en de links openen in nieuwe tabs heb ik er geen last van. FF 1.0.4

[brtdv]

In nieuwe vensters ook niet, met firefox 1.0.4...

[Keeper of the Keys]

Helaas is Firefox wel gevoelig, als je 'gewoon' op beide links op de test-site klikt, dus niet voor elke link een niewe tab afdwingt of voor elke link een nieuw venster afdwingt dan wordt de test-page in het frame van msdn geladen.

* 786562 Keeper
[edit: net iets te laat sorry]

[kidde]

Toch krijg ik deze bug niet zover te doen wat hij moet doen op Ffox 1.0.4 voor Gentoo Linux, en ik heb gewoon op de twee links geklikt (maar dan nog openen ze in twee verschillende tabs en in de MS-site staat niks van secunia).
Iemand een idee hoe ook ik deze bug aan de praat krijg? Ik gebruik al zo lang geen IE meer, ik wil ook wel eens exploits en virussen!
De vorige Ffox bug/exploit werkte samme wel bij mij!

[MikeN]

Ik wel met openen in nieuwe venster, niet in tabs. Ook met ff 1.0.4

[Verwijderd]

Als ik beide paginas "gewoon" open (MSN komt in een nieuw venster) dan werkt deze bug nog gewoon onder Firefox 1.0.4., maar sls ik MSN open in een nieuwe tab, dan maakt het niet uit hoe ik de Secunia pagina open (tab of venster) en werkt de bug niet.

*edit* heh, net te laat

[farlane]

MSDN = MicroSoft Developer Network

[progster]

Firefox/1.0 (Ubuntu package 1.0.2 MFSA2005-44) is niet kwetsbaar lijkt me (gebruik wel singlewindow extension)

[Shaidar]

Nee, hoe ik het ook probeer, ik heb er geen last van ... FF 1.0.3 hier

hah!

[Dreamvoid]

"Gebruikers wordt aangeraden om voorlopig te downgraden naar Netscape 3"

[Hodgesaargh]

Zijn er nog mensen die NIET met Lynx werken dan?

[seweso]

Ja probeer dáár maar eens mee te bankieren...

[Oceria]

Och, het inlog systeem van oa de postbank is toch ook al gedateerd, dus dat zou niet uit mogen maken qua compatibiliteit


Maar serieus, het is toch wel een kwalijke zaak dat deze bug weer terug is geslopen in de code van 1.0.4.
Ik verwacht toch zeer snel een update hiervoor, aangezien men de oplossing al heeft.

[kidde]

Lynx is zooo 2004. In 2005 gebruik je toch links!

[daft_dutch]

links2 -g
pwns

[Verwijderd]

Galeon is heeft er ook geen problemen mee. Voor mij is da nog altijd de beste gnome browser die er is .

[lvh]

Galeon is Mozilla met een ander schelpje errond...

[Verwijderd]

Ja ik, ik gebruik ELinks (of gewoon `links`)

[xces]

Deze bug is ook in Deer Park Alpha 1 terug te vinden de alpha versie van firefox 1.1 (zie meuktracker). Heb eergisteren deer park alpha 1 gedownload en ben er vanaf toen mee aan het browsen..

[buzzin]

The Secunia database currently contains 0 Secunia advisories marked as "Unpatched", which affects Opera 8.x.

Tja wat zal ik eens zeggen

Maar inderdaad wel vreemd dat de bug ´terug´ komt natuurlijk....beter opletten daar bij mozilla

[N0stradamus]

Dat Secunia de firefox exploit laten zien met een microsoft site...

[Verwijderd]

Ik heb voor Firefox de NoScript-plugin geinstalleerd. En die geeft meteen aan dat Secunia een script wil uitvoeren... Mij foppen ze niet

[RSpliet]

Het lijkt erop dat deze bug niet werkt bij mensen die gebruik maken van de tabbrowser extension, zo ook bij mij. Een mooie remedie (voorlopig) is het gebruiken van tabs en de tabbrowser extension .
Zonder TBE kan ik deze bug trouwens ook bevestigen in Deer Park Alpha 1, de bug zit er dus wel.

[TtL8e7ay]

Ik gebruik hier de TBE en ben wel vulnerable. Hoe doe jij dat precies?

[RSpliet]

Hmm... nu ik erover nadenk, ik ben waarschijnlijk wel vuln. Ik open alleen links by default in dezelfde tabs. Wil ik een andere tab, dan middel-klik ik op de link. Zo krijg ik de kans dus niet de tweede link aan te klikken, of opent die in wederom een nieuwe tab. Zo lukt het injecteren natuurlijk niet
Hij is dus idd met TBE ook vuln ja

[brammus]

Bij mij is IE wel kwetsbaar, maar met de Maxthon schil weer niet

Mits de "venster ID toewijzing in frames negeren"-optie is aangevinkt, dan kan de aanvallende pagina zijn 'slachtoffer'-pagina niet meer vinden, lijkt het.

Geen verkeerd idee om dus een dergelijke optie in te schakelen, dunkt me...