Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 89 reacties, 23.269 views •

Mozilla heeft de dinsdag geïntroduceerde nieuwe versie van Firefox alweer offline gehaald, vanwege een beveiligingsprobleem. De browsermaker belooft donderdag een gepatchte versie te uploaden. De Android-versie is al gepatcht.

Firefox-logoDe kwetsbaarheid die Mozilla heeft doen besluiten om Firefox 16 offline te halen, maakte het mogelijk voor kwaadwillende sites om te achterhalen welke url's zijn bezocht. Bovendien kunnen kwaadwillenden 'toegang krijgen tot de url en de url-parameters', schrijft de beveiligingscoördinator van Mozilla. Wat daarmee precies wordt bedoeld, is onduidelijk.

Huidige gebruikers van Firefox 16 worden niet automatisch gedowngraded, maar kunnen dat desgewenst wel handmatig doen. Bovendien krijgen ze automatisch een gepatchte versie zodra die beschikbaar is. Firefox hoopt die versie donderdag nog te kunnen uitrollen. Overigens is Firefox 16 nog wel te downloaden op een pagina met gelokaliseerde Firefox-versies. De Android-versie van Firefox was ook getroffen, maar is inmiddels al voorzien van een update.

Firefox 16 werd dinsdag uitgerold en biedt onder andere betere developertools en de mogelijkheid om webapps te 'installeren'. De Android-versie heeft daarnaast een leesbaarheidsmodus gekregen, waarbij onnodige interface-elementen van websites worden weggehaald, waardoor de tekst beter leesbaar is.

Reacties (89)

Reactiefilter:-189074+152+27+31
Moderatie-faq Wijzig weergave
Voor een Proof of concept van de vulnerability, zie https://news.ycombinator.com/item?id=4639491
2 voorbeelden met Twitter en Facebook.
Waar het dus om gaat is dat het in FF16 mogelijk is de actuele URL op te vragen van een vanuit javascript geopende window of iframe op een ander domein, waar mogelijk gevoelige informatie in voorkomt. Zoals het voorbeeld met twitter, de window wordt geopend voor twitter.com/lists/, maar die wordt uiteindelijk geredirect naar twitter.com/<jouw_username>/lists, waardoor het voor een willekeurige pagina dus mogelijk is om jouw twitter username te achterhalen. Dit probleem wordt uiteraard nog veel gevaarlijker op het moment dat er sessie-informatie in de URL komt te staan die op die manier gehijacked kan worden.

Normaliter wordt er gekeken of het domein van de pagina met de javascript en het domein van de andere pagina overeenkomen voordat dergelijke informatie uitgewisseld wordt. Zo geeft Chrome bij dat twitter voorbeeld doodleuk de volgende melding in de javascript console:
Unsafe JavaScript attempt to access frame with URL https://twitter.com/***/lists from frame with URL http://www.businessinfo.c..._did_last_summer/poc.html. Domains, protocols and ports must match.

[Reactie gewijzigd door .oisyn op 11 oktober 2012 10:46]

Wat mij verbaast is dat ze 1 privacy bug (hoe erg/vervelend die ook is) prefereren boven 21 ernstige beveiligings-bugs die ze opgelost hebben in versie 16 en dus adviseren naar een oude lekker versie terug te gaan.
Ook ik heb steeds meer het idee dat het spaak begint te lopen. Ik kan er geen vinger opleggen van 'daar zitten de bugs' maar ik heb het idee dat het sinds versie 9 steeds vaker crasht (ons monitor systeem). Thuis heb ik op twee systemen met FF15 dat tabs blokkeren. ik verlang wat dat betreft steeds meer terug naar de 3.6.x serie en naar toen het nog phoenix en firebird heette.
Om te testen of je kwetsbaar bent
http://www.businessinfo.c..._did_last_summer/poc.html

Zorg wel dat je inglogd bent op twitter.. als je een melding krijg van je user name ben je kwetsbaar.
Let wel op: de browser crasht..
Update binnen en nu doet die het inderdaad niet meer dus lijkt opgelost!
Bovendien kunnen kwaadwillenden 'toegang krijgen tot de url en de url-parameters', schrijft de beveiligingscoördinator van Mozilla. Wat daarmee precies wordt bedoeld, is onduidelijk.
Het lijkt me dat daarmee de parameters worden bedoelt die meegegeven kunnen worden in een URL. Voorbeeld: http://www.test.nl/index.php?test=1&token=83bca979&voorbeeld=ja.
Hier zou bij sommige websites wat gebruikersinformatie uit onttrokken kunnen worden.

Edit: URL aangepast, zodat de link naar Tweakers.net wijst.

[Reactie gewijzigd door Bux666 op 11 oktober 2012 12:46]

Intelligentie is niet hetzelfde als kennis, en als je denkt dat dat wel zo is dan getuigt dat niet van veel intelligentie ;)

Overigens ben ik het wel met je onderliggende punt eens, ik had een wat meer in-depth artikel verwacht op tweakers.net. Het kostte mij slechts 10 minuten voordat ik erachter was wat er nou precies aan de hand was en mijn post te tikken. De kennis zit bij t.net op kantoor, en je weet dat dergelijke interesse ook bij de lezers aanwezig is, dus het lijkt mee een redactoriële misser dat dit niet gewoon goed is opgepikt.

[Reactie gewijzigd door .oisyn op 11 oktober 2012 10:50]

Ik vraag me af of een externe partij dit probleem gemeld heeft of dat ze er zelf achter gekomen zijn.
Vandaag dus de update, lijkt me redelijk snel.
Eigenlijk telaat, maar FX wil op termijn hun updates door middel van een service te pushen (zonder interactie van de gebruiker). Ik weet niet of dat echt een goed idee is voor een bedrijf dat elke release binnen de 14 dagen moet voorzien van een update, veelal vanwege een security bug. Moest dit nu eens één keer gebeuren zou het niet zo een ramp zijn, zoals je zelfs aangeeft zijn ze snel met het patchen, maar het gebeurt bij elke release.

Er is een reden waarom ik even wacht met updaten.
"FX wil op termijn hun updates door middel van een service te pushen (zonder interactie van de gebruiker)"

Deze functie is al sinds updaten van Firefox 12 --> 13 aanwezig. Het updaten van Firefox 15+ gebeurt op de achtergrond, zodat de gebruiker er nog minder van merkt.

[Reactie gewijzigd door Coyote76 op 11 oktober 2012 13:08]

Overigens klopt het geciteerde ook op een ander punt niet: de service is niet verantwoordelijk voor het downloaden van updates en draait normaal gesproken ook niet. De service wordt alleen geactiveerd op het moment dat een update gedownload is en geïnstalleerd moet worden - om zo UAC dialogen en vertraging tijdens het opstarten van de browser (en nu ook Thunderbird) te voorkomen.

[Reactie gewijzigd door Mitsuko op 11 oktober 2012 18:04]

Eigenlijk telaat, maar FX wil op termijn hun updates door middel van een service te pushen (zonder interactie van de gebruiker). Ik weet niet of dat echt een goed idee is voor een bedrijf dat elke release binnen de 14 dagen moet voorzien van een update, veelal vanwege een security bug.
Voor bedrijven is er dan ook de Firefox Extended Support Release (ESR) die minder vaak geupdate wordt.
Niet geheel waar.
De ESR worden niet voorzien van feature, maar wel van de nodige patches, waardoor er bij elke nieuwe release ook een ESR update is. Het enige verschil is dat je, althans de theorie, enkel maar moet deployen, de praktijk wijst echter anders uit.
een patch een dag na het ontdekken van de fout noem jij te laat? Toegegeven, de fout had niet mogen gebeuren maar heeft zich toch voorgedaan. De snelheid waarmee Mozilla dit probleem aanpakt kan ik evenwel enkel aanzien als een voorbeeld voor andere softwarefirmas.

En ja, mensen maken fouten ... .
Iedereen maakt fouten, maar bij Mozilla is het een onderdeel geworden van het ontwikkelingsproces. Ze brengen een release uit en het duurt niet lang of er komt een noodzakelijke update uit. Als dat eens één keer gebeurt is er weinig aan de hand, als dat (bijna) altijd gebeurt dan moet je toch eens nadenken of je wel een goede strategie hanteert.
Wat ik alleen niet snap;

de voorgaande versies hadden dit probleem niet. Hoe kan een dergelijk probleem dan plotseling ontstaan ? Ik bedoel; als iets toch goed werkt hoef je daar toch niet aan gaan zitten rommelen ?

Los eerst eens alle andere bugs op alvorens aan bestaande functies te zitten prutsen ..
Los eerst eens alle andere bugs op alvorens aan bestaande functies te zitten prutsen
Het is niet heel ongebruikelijk dat het fixen van een bug weer een nieuwe introduceert. Ook kan het zijn dat de opzet van de code zo wordt omgegooid om nieuwe features mogelijk te maken, waarbij je ook weer het risico loopt dat bestaande funcionaliteit breekt.

Ja, natuurlijk moet dat goed getest worden, maar jij doet nu net alsof ze zonder meer aan het rommelen zijn met code die gewoon goed werkt, terwijl je over totaal geen enkele achtergrondinformatie beschikt.

Dat merk ik overigens sowieso vaak bij reacties van jouw hand. Een tip: lees je eens een keer in een onderwerp in voordat je begint te roepen hoe het wel moet :).

[Reactie gewijzigd door .oisyn op 11 oktober 2012 11:41]

Voor mij is dat gewoon logica; als iets prima werkt en na een update kuren vertoond, heb je het verprutst. Lijkt mij geen speld tussen te krijgen.

Ik word er de laatste tijd gewoon moe van dat ik na het updaten (vanwege een serieuze bug / security issue) vaak grotere problemen heb als voorheen.

Dat zie je bij JAVA, Adobe Flash en nu dus ook bij Firefox.

Maar hey; ik schijn "fans" te hebben. Is ook wat waard ;-)
Aan wat Cronax zegt wil ik nog een paar dingen toevoegen.

Ten eerste dat sommige delen van Firefox nog uit de Netscape tijd stammen - vaak weet men dus niet meer goed waarom iets geschreven is zoals het geschreven is, of stamt een functie uit een tijd toen het web nog vooral uit tekst en gifs bestond. Vaak kan je die code wel uitbreiden - maar als er ingrijpende veranderingen nodig zijn, bijvoorbeeld om iets wat statisch is dynamisch te maken, dan is het soms handiger om overnieuw te beginnen. De nieuwe code voldoet dan aan moderne programmeerconventies en is vaak een stuk makkelijker te onderhouden.

Ten tweede is het niet zo dat nieuwe code zomaar zonder testen in gebruik wordt genomen. Zo heeft Mozilla een geautomatiseerd test framework wat uit een aantal lagen bestaat - Reftests, Mochitests, Peptests, Talos, en vast nog een paar die ik hier vergeet - waarin letterlijk honderdduizenden tests worden uitgevoerd die verschillende delen van de code testen. Daarnaast doorloopt de browser voor de Release versie eerst nog het Nightly traject (~95 duizend actieve gebruikers), het Aurora traject (~125 duizend actieve gebruikers) en het Beta traject (een paar miljoen actieve gebruikers), samen goed voor 12-18 weken (afhankelijk van wanneer in de cyclus een verandering in de browser wordt aangebracht). Als er met al die tests toch iets doorheen glipt - tsja, dat kan gebeuren. Maar het gaat niet zomaar.
Heel leuk dat het voor jou logica is maar zo werkt het bij code nu eenmaal niet. Bij een stuk software werkt men bijvoorbeeld vaak volgens het 'DRY' principe, of "Don't Repeat Yourself'. Dit houd in dat je een bepaald stuk code één keer schrijft en dan zo vaak mogelijk hergebruikt door naar diezelfde code terug te verwijzen. Als je dus een bug fixt in zo'n stuk code kan dit invloed hebben op andere delen van je software omdat het initiele stuk code gewijzigd is.

Sowieso werken veel delen van code samen met andere delen dus als er in het ene deel iets wijzigt kan dat invloed hebben op hoe het andere deel werkt. Dit kan je vantevoren niet altijd weten en zeker niet als alleen de developer zijn eigen werk test, die testen namelijk over het algemeen op een vrij elementaire wijze: ze testen ieder stukje code op zichzelf en niet het geheel.

Als voorbeeld, stel je hebt een stuk software waar de hoofdfunctie is dat je een waarde in kan geven voor X en dan de uitkomst Y word berekend. Vervolgens doet de code het volgende:

A = 3 x X
B = 5 x A
C = B / 2
Y = C - 2

Bij het soort testen wat veel developers zelf doen testen ze ieder van deze regels opzich en kunnen er voor A B en C uitkomsten uitkomen die correct lijken, maar pas als je daadwerkelijk X hebt ingevoerd en er de juiste Y uit komt heb je echt zekerheid dat alles werkt. Hiervoor neem je dus een software tester in dienst, die vervolgens ook nog gaat kijken wat er gebeurd als je voor X waardes invoert die eigenlijk niet voor komen of waar vaak niet aan gedacht wordt.
Wel een beetje vreemde volgorde, eerst de veel minder gebruikte android app updaten en daarna pas de desktop versie.
Hoeft niet vreemd te zijn, wellicht was de Android app makkelijker te patchen, was er sneller een kundige developer beschikbaar, of was de patch sneller uit te rollen.
Misschien was de Android versie van een latere build, waarin de patch al verwerkt zat. Daarom is misschien een nieuwe versie met patch van de desktop versie zo snel te bakken. (@ pfranze).
misschien is Mozilla Android guy wel heel erg snel of het heeft minder tests nodig om uit te rollen.
Dat is al vaker gebeurd. Hebben ze sinds het opgevoerde release-schema geen tijd meer om major bugs (zoals deze) na te kijken voor de release de wereld in te sturen?

[Reactie gewijzigd door Petervanakelyen op 11 oktober 2012 10:32]

Nee, er is niet met het nieuwe release schema niet getornd aan (unit) tests en triaging. De updates hebben veel meer een incrementeel karakter en het is nu mogelijk juist de minor bugs aan te pakken binnen het release schedule.
Vrremd, maar op FileHippo.com staat de download nog steeds online.
http://www.filehippo.com/...ad088e136b66dc85a294ce18/
Ik krijg 'm net binnen via de Ubuntu updates. Ook niet echt handig...
Plugin container probleem is ook nog niet opgelost in 16, zoals een andere gebruiker in de eerdere nieuwspost zich afvroeg.

zojuist weer vastgelopen...
Ik gok dat je last hebt van een gare plugin, addon of profiel. Ik kan me niet herinneren wanneer Firefox voor het laatst is vastgelopen op mijn machines.

Ja, Facebook spelletjes misschien. Maar die crashen in elke browser even vaak.

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True