Eerste exploit voor nieuwste Firefox gepubliceerd

Nadat Firefox 1.5 afgelopen 29 november officieel is gelanceerd is nu de eerste exploit voor de browser gepubliceerd. Door een fout in de verwerking van het bestand 'history.dat' is het mogelijk om de browser te laten crashen en het opstarten ervan onmogelijk te maken.

De ernst van de fout is relatief beperkt aangezien het alleen een Denial-of-Service-aanval mogelijk maakt. De fout in de browser treedt op wanneer een webpagina wordt geopend met een te lange titel. Firefox slaat in het bestand history.dat de sites op die de gebruiker heeft bezocht, waarbij ook aanvullende informatie over de site wordt opgeslagen. De te lange titel zorgt ervoor dat Firefox crasht bij het inlezen van history.dat. Het vermoeden bestaat dat wanneer de titel van een pagina een specifieke vorm heeft, de fout in de browser een grotere impact heeft omdat het dan wellicht mogelijk is om een buffer overflow-exploit te maken waardoor programmacode kan worden uitgevoerd op de computer van de gebruiker. De ontwikkelaars van Firefox hebben nog geen plannen om een patch uit te brengen, omdat de gevolgen van de fout nu nog erg beperkt zijn. Zodra echter blijkt dat de veiligheidsfout grotere gevolgen heeft, zal er alsnog een patch worden uitgegeven. Een tijdelijke oplossing voor het probleem bestaat uit het uitschakelen van de geschiedenisfunctie van Firefox, zoals wordt beschreven op de site van het Internet Storm Center.

Reacties (57)

[woekele]

"De ontwikkelaars van Firefox hebben nog geen plannen om een patch uit te brengen, omdat de gevolgen van de fout nu nog erg beperkt zijn."

Dat is nou typisch de houding waardoor je browser een slecht imago krijgt en waar je populairiteit mee verliest.

Je moet juist vooraf gaten dichten, niet afwachten tot het kalf al verdronken is. Dit valt me echt zwaar van ze tegen. Hierdoor krijgen de pro-IE mensen alleen maar gelijk als ze zeggen dat Firefox net zo onveilig is en ook te lang wacht met patches.

Edit: en waarom wordt dit weggemod als first post? Ik geef gewoon een mening en maak een punt, wat heeft dat met first-post te maken? Alleen maar omdat ik toevallig de eerste ben, wil niet zeggen dat ik een post zonder inhoud heb gemaakt.

[H@rry]

ik vind het vreemd dat deze bug nog niet bij de beta naar voren is gekomen. Of ze moeten de code zodanig drastisch aangepast hebben dat dit erin geslopen is...

[Devil N]

Maar je wilt als gebruiker ook niet om de paar dagen weer een patch hoeven te installeren omdat er weer eens een klein lekje gevonden is. Dat maakt het up-to-date houden van je software alleen maar onoverzichtelijker, en dat is ook niet goed voor het imago van je browser.

[praseodymium]

Firefox heeft daarom een auto-update functie die bijna zonder dat je iets hoeft te doen de boel update.

[woekele]

Precies, het is toch juist gemaakt zodat er makkelijk wat kleine patches doorgevoerd kunnen worden? Gebruiken dus die handel en morgen een patch uitbrengen...

[Verwijderd]

Inderdaad, het maakt mij zelf niet uit als die functie elke paar dagen even een kleine nieuwe update binnenhaalt... Als het kleine patches betreft moet dit in een paar seconden gebeurd zijn.

[sebas]

Werkt dit wel altijd? Bij mij kan de gebruiker die firefox runt namelijk nooit naar de bestanden schrijven, de gerund worden ...

[Verwijderd]

Jij niet, ik wel.. En zeker diegene die in een zakelijk netwerk zitten.

[Verwijderd]

Beheerders in een zakelijk netwerk willen zekerheid hebben dat overal uniforme software draait. Patches moeten daar dus ook centraal worden uitgerold. Om nu elke dag zo'n patch te verspreiden is echt een ramp voor de beheerders.

[Verwijderd]

Je moet juist vooraf gaten dichten, niet afwachten tot het kalf al verdronken is. Dit valt me echt zwaar van ze tegen. Hierdoor krijgen de pro-IE mensen alleen maar gelijk als ze zeggen dat Firefox net zo onveilig is en ook te lang wacht met patches.

Ben het hier niet met je eens, deze bug kan in de meeste gevallen alleen een crash van firefox veroorzaken, niet interresant dus voor hackers om hier aandacht aan te besteden aangezien het merendeel IE gebruikt en iedere bug bij IE betekend in de meeste gevallen gelijk een remote rootexploit, dus IE is een veel gemakkelijker doelwit.

[d-snp]

Ja dat zeiden ze dus bij microsoft ook, totdat vorige week bleek dat die ene low priority IE crash bug toch wel exploit baar was, en iedereen in een keer boos werd op MS omdat ze de bug niet serieus behandelden. Dit is exact hetzelfde geval, er is geen enkel verschil tussen de exploitbaarheid van een bug in IE en een bug in FF. (gemiddeld dan he, de code is natuurlijk anders dus per bug is er wel degelijk een verschil, maar over de gehele linie niet.)

<edit reactie op Eric Oud Ammerveld

Jij snapt niet helemaal waar je het over hebt. Een LEK is een bug waarbij het mogelijk is om code uit te voeren. Deze lekken zijn meestal van het type het programma wil wat hebben van een bepaalde grote, en de gebruiker voert dan iets te groots in waardoor het teveel op een plek komt in het geheugen waar het uitgevoerd kan worden. Op dit moment weet men nog niet of dat kan, maar het programma loopt in ieder geval vast van een te grote input, dat is dus zoals gezegd werd veelal de voorbode van een exploit. >

[trogdor]

Het is nu nog een bug, maar:

Het vermoeden bestaat dat wanneer de titel van een pagina een specifieke vorm heeft, de fout in de browser een grotere impact heeft omdat het dan wellicht mogelijk is om een buffer overflow-exploit te maken waardoor programmacode kan worden uitgevoerd op de computer van de gebruiker.

[Stewie!]

IE6 crasht regelmatig door een dergelijk geheugenallocatieprobleem.
Om jouw redenatie kracht bij te zetten sluit je af met een verzinsel?

[Eric Oud Ammerveld]

Een exploit is een LEK waardoor veelal (root) access verkregen kan worden of je PC kan worden aangestuurd afwijkende dingen te doen (zoals een gerichte DDOS attack uitvoeren).

Dit is geen lek, dit is puur een bug en om daar nou ofhef over te maken....
IE6 crasht regelmatig door een dergelijk geheugenallocatieprobleem.

[Eric Oud Ammerveld]

Uhrm wat voor jou misschien een verzinsel is, is voor een hoop IE6 gebruikers dagelijkse werkelijkheid.

http://www.scorpioncity.com/mscrash3.html

[Verwijderd]

Wat een onzin. Ik stap echt niet van FF af omdat er een heel klein bugje in zit.

Geef ze groot gelijk de ontwikkelaars, ze kunnen beter de tijd besteden aan nuttige ontwikkelingen dan een klein foutje in de software.

Het argument dat IE voorstanders nu sterker in hun argumenten staan vind ik klinklare onzin, omdat de hele discussie welke browser de beste is, grote onzin is.
Dit omdat het voor iedereen een persoonlijke kwestie is en niet rationeel bekeken kan worden.
Alleen al omdat iedereen een ander gewicht geeft aan mogelijkheden in pakketten.

[xbassiex]

Zo werkt het nou eenmaal in de wereld. Als er iets fout gaat worden er pas verscherpingen en verbeteringen doorgevoerd (denk aan 11 september, of de schipholbrand).
Als je bij elk kleine dingetje relatief grote veranderingen door gaat voeren worden gebruikers ook niet blij...

[Verwijderd]

De ontwikkelaars van Firefox hebben nog geen plannen om een patch uit te brengen, omdat de gevolgen van de fout nu nog erg beperkt zijn. Zodra echter blijkt dat de veiligheidsfout grotere gevolgen heeft, zal er alsnog een patch worden uitgegeven. Een tijdelijke oplossing voor het probleem bestaat uit het uitschakelen van de geschiedenisfunctie van Firefox, zoals wordt beschreven op de site van het Internet Storm Center.

Ik weet niet waar de reviewer deze informatie vandaan heeft, maar op het forum van mozilla en op bugzilla staat hier helemaal niets over. Sterker nog er zijn al 2 eerste patches (3de misschien in aantocht) om de bug te fixen. Als ik de reacties lees zijn ze van plan om snel een fix uit te brengen en menen sommige mensen (net als hier) dat de PR van open-source en firefox een deuk kan oplopen als ze er niet snel iets aan doen. Dus de developers zijn IMHO zeker wel op de hoogte van de gevolgen als ze te laks hierop reageren en zullen het hier niet op aan laten lopen.

[Mars Warrior]

Daar heb je helemaal gelijk in (dat het niet te vinden is), maar als je in dat stuk FF door IE vervangt dan komt het stuk plotseling wel heel bekend voor...

Zou er iemand per ongeluk een copy/paste hebben gedaan uit een andere nieuwsposting???

Los daarvan is het volgens de vinders van de exploit dus WEL mogelijk om dit uit te buiten en code uit te voeren die behoorlijk wat schade kan aanbrengen...

[TargetX]

Ik wil hiermee niet de makers van firefox onderuit halen, maar dit lijkt mij een vrije simpele (en ook redelijk domme?) bug.. Het is toch algemeen bekend dat voordat je data OPSLAAT, je de maxlengte en character-geldigheid etc checkt, en dat je dit bij het inlezen eventueel nogmaals doet. Deze regel geld voor PHP/SQL sites en voor programeren net zo goed. En dat er hiermee zelfs code op de client-computer kan worden uitgevoerd is helemaal ernstig..

Ik ben zelf een beginnend programeur dus alle respect voor de mensen van firefox, tis een topbrowser, maar ik vind dit toch echt een onnodige, slordige bug, of mis ik hier iets?

[Gerco]

Je mist dat FF helemaal niet crashed, maar alleen een erg inefficient O(n^2) algoritme gebruikt om dat bestand weer in te lezen. De buffer wordt steeds 512 bytes groter en de oude buffer wordt naar de nieuwe gekopieerd. Dit duurt voor lange strings zo lang dat het op een hang lijkt, maar dat is het dus niet!

Als je lang genoeg wacht gaat FF gewoon weer verder. Geen code execution, geen crash, alleen een tijdelijke hang. Natuurlijk moet het gefixt worden, maar met al twee patches klaar en een derde onderweg verwacht ik daar geen problemen.

Post op bugzilla:

I've also tried this with windows with a 15000*10000 string (150MB or so); we
baloon up to 300MB+ memory usage (UTF16), but no crash. On restart, though,
memory usage kept jumping between 68MB and 75MB, never really growing -- I
didn't have a debug build handy, but it looks like it's just mork being really,
really slow. The same thing on linux; I have it up in the debugger now, and
mork is happily getc()'ing and putc()'ing one character at a time.. it'll take
it a while to get to 150MB, malloc'ing 512 more chars at a time and memcpy'ing
the whole thing over.

Note that on windows I was a little worried that we may be overflowing some OS
buffer when setting the window title; however, the WM_SETTEXT message takes a
null-terminated string, so we're ok there. This is just a really crappy perf bug that we ought to fix.

[TaXaN]

Ook even opmerken dat ze al een tijdje bezig zijn om Mork definitief te begraven en een betere en uniforme storage backend te gaan gebruiken.

Mork is zo'n draak van een spec en implementatie dat niemand er nog aan durft te komen. Enkel vervangen is een optie en daar zijn ze dan ook mee bezig. Target is Firefox 2.0.

[Pwigle]

De oplossing lijkt me simpel: beperk het aantal karakters dat een website als titel kan gebruiken. Net even getest en Internet Explorer beperkt de titel tot 95 karakters.

[raptorix]

Dat is bij Firefox ook wel, maar hier wordt het op een creatieve manier gedaan, namelijk door in javascript een string op te bouwen van bijvoorbeeld een miljoen tekens, en vervolgens via document.title=delangestring de title gezet. Kennelijk heeft men bij Firefox hier geen rekening mee gehouden. Vervolgens wordt deze tekening in het Logbestand gezet wat weer voor mogelijke crashes zorgt. Via een andere site was de ervaring ook dat de lengte van de string nogal kon varieeren voordat firefox crasht.

[CrashOne]

Er is een mooie tijdelijke oplossing:

user_pref("capability.policy.default.HTMLDocument.title.set","noAccess");

Hierdoor heeft JS geen toegang meer tot de title binnen de html en kan deze bug ook niet worden "misbruikt" (al is het geen exploit).

[ytsmabeer]

Er is ook een betere opslossing van de Firefox problemen.
Gewoon Opera gebruiken.

Berend
Frisian translator

[A_L]

Totdat blijkt dat "de betere oplossing" er ook last van heeft.

[Verwijderd]

Dus is het beter om toch maar FF te gebruiken

wilco
Geen frisian translator (gelukkig)

[Verwijderd]

Inmiddels zijn er al twee patches ingezonden en getest, maar ze zullen vast nog wel meer opties uit willen proberen voor ze met een stabiele update komen.

Los van de exploit moet je echter ook bedenken dat het ook een fout in de window-manager van het besturings-systeem kan zijn, de titel wordt immers in de balk van het venster geplaatst, en als deze blijft hangen door de lange titel lijkt het net alsof alleen firefox de boosdoener is, terwijl het dus een combinatie is tussen applicatie en OS.

Maar goed, look at the bright side: als dit de ergste bug is die gevonden wordt vindt ik het nog een hele meevaller met al die nieuwe features

... altijd spannend die eerste 2 maandjes van een nieuwe release

[Room42]

Los van de exploit moet je echter ook bedenken dat het ook een fout in de window-manager van het besturings-systeem kan zijn, de titel wordt immers in de balk van het venster geplaatst, en als deze blijft hangen door de lange titel lijkt het net alsof alleen firefox de boosdoener is, terwijl het dus een combinatie is tussen applicatie en OS.

Hallo, heb je wel gelezen, of probeer je 1st post te scoren ofzo?
Het gaat niet om het weergeven, maar het opslaan en/of lezen in/van het history.dat-bestand.

[densoN]

hier valt nog mee te leven, zolang het maar niet op gatenkaas begint te lijken.

[PWM]

Dit is het begin van gatenkaas.

Als dit soort dingen blijven liggen, gaat het vanzelf een keer fout. Firefox blijkt gewoon niet zonder fouten te zijn. Iets wat de gemiddelde tweaker heus wel weet, maar bij het grote publiek wat gehoord heeft van Firefox is dat niet bekend. Die denken dat het een 100% safe browser is.

Hoewel dat niet mogelijk is, moet Firefox dat imago proberen te behouden.

[PatMan]

Volgens mij is er hier weer sprake van een storm in een glas water. Bij http://isc.sans.org/index.php?on=diary wordt het volgende gezegd:

This seems to be more of a denial of service than a true buffer overflow. It looks like Firefox just chokes on page topics that are too long. Some people it hangs, other people it crashes.

Ook bij CNET is er al een correction toegevoegd dat er geen sprake is van een security vulnerability.

Een exploit zou ik deze bug dus zeker niet willen noemen.

[Bor]

Sinds wanneer is een denial of service geen security vulnerability

[i-chat]

omdat je systeem, en de data op je systeem, er doorgaans niet aan kapot gaan, - en zeker op een DOS, tegen een webbrowser, is mijns inziens niet meer dan Verd*md lastig,
maar dan nog steeds, krijg je er geen virussen van, en/of 'remote code execution' mogeljkheden,

niet geheel onlogisch dat het dus, wel als 'sirious', maar niet als 'high risk' zou worden bestempeld. - en dan eigenlijk ook alleen nog maar 'sirious' omdat de goede naam van je product in het geding is.

[Bor]

Onzin om een denial of service niet mee te rekenenen. Bij security gaat het om 3 zaken : Confidentiality, Integrity en Availability. Erg available is de info via de browser niet na een exploit van dit gat. Nou is dat voor een simpele consument misschien niet zo erg maar als je erg afhankelijk bent van een browser voor je werk word het al anders.

Het niet aangeven van een DOS vulnerability als risico is niets meer dan het (eventueel expres) onderschatten van het probleem.

[PatMan]

Sinds wanneer is een denial of service geen security vulnerability

Die 'denial of service' kwalificatie komt van SANS, niet van CNET, en blijkt ook onterecht. De Mozilla Foundation heeft aangegeven dat het geen crashes of denial of services heeft kunnen reproduceren. Ik heb de probleemcode zojuist ook op mijn computer uitgevoerd, en Firefox ging bij het opstarten na 1 of 2 minuutjes weer gewoon door.

Los van dit alles: een denial of service is in het algemeen inderdaad een security vulnerability. Als Firefox inderdaad niet meer zou willen starten, zou dit
strikt genomen een denial of service zijn.

Toch zou ik het in dit geval veel minder ernstig dan andere DoS-en vinden, omdat er zoveel eenvoudige workarounds zijn (IE staat standaard nog op iedere Windowsmachine, als je history.dat wist is het probleem opgelost, een nieuw profiel biedt ook uitkomst).

[progster]

lees de commentaren nog is, het is geen dos...

edit: dubbelpost

[Plankje]

Ik heb net getest of het werkte (FF 1.5 Win XP SP2) en deze bug werkt niet alleen bij javascript, maar ook als je op de normale manier een abnormaal lange titel invoert. (dus <title>helelangetitel</title>). Na een reboot vertikte FF ook om op te starten. Gelukkig wist ik zelf wel de history.dat file te vinden:)

[Verwijderd]

Ik krijg altijd een error als ik naar de site www.nederland.fm en een zender kies (Veronica).... Een windows media player error. En daarna kan ik FF niet meer gebruiken. Kan alleen door het in processes (ctrl alt del) te verwijderen. Zijn er meer mensen die dat ook krijgen?

[Sjah]

Net geprobeerd, gaat uitstekend hiero, met FF 1.5 en wmp10 installed.

[Verwijderd]

Lukt mij ook gewoon met wmp9.