Google Chrome crasht bij invoer van sommige url's

In Google Chrome blijkt een fout te zitten die ervoor zorgt dat de browser crasht bij het invoeren van bepaalde url's. Dat gebeurt als er een null-karakter in de url zit. Het gaat ook mis als de gebruiker een mouse-over doet op een dergelijke url.

De bug in Chrome werd ontdekt door Andris Atteka, die de vondst op zijn blog uit de doeken deed. Atteka ontdekte dat het invoeren van een url met daarin een zogenaamde null character ervoor zorgt dat de browsertab vastloopt. In sommige gevallen crasht zelfs de gehele browser, zo meldt Venturebeat. De bug is gerapporteerd bij Google, en die lijkt bezig te zijn met het oplossen ervan. Het probleem lijkt zich voor te doen bij de desktopversies van Chrome, maar sommige gebruikers van de Android-browser melden ook crashes.

Als voorbeeld gaf Atteka de url http://biome3d.com/%%30%30. Opvallend is dat zelfs een mouse-over op de bewuste link ervoor zorgt dat de browsertab niet meer werkt. Het moet overigens wel gaan om een klikbare link, waardoor de url in dit artikel de browsertab van Chrome-gebruikers dus intact zou moeten laten.

Een technische verklaring voor de bug is te vinden in oude code die nog dienst doet in de Chrome-browser, zo wordt uitgelegd op de Chromium-code-website van Google. De fout zorgt waarschijnlijk niet voor veiligheidsproblemen.

Reacties (142)

[jvdmeer]

Jammer dat deze in september pas het nieuws haalt, terwijl de bug in mei al is aangemeld door iemand anders.

[kwakzalver]

Kon ook niet veel eerder, de thread was hiervoor restricted.
Maar nu begrijp ik waarom chrome op iOS crashed. Was al overgestapt op Firefox omdat bij mij Chrome steeds dichtklapte of Aw snap antwoorde...
Van wat ik begrijp is het eigenlijk een bescherming die iets te strak is ingesteld.

I think tsepez was doing some related security work in the past. Adding him.

This is annoying and we should fix it. The thing breaking here is we're trying to protect the browser process from malicious URLs containing NULLs and being a little too overaggressive.

Either we need to be more careful about unescaping here and never generating something that the browser process would unescape to a null, or we need to relax the security checks. Without looking at the code, I suspect the former will be a losing battle of edge cases and I think we should probably do the latter if it can be done cleanly.
Cc: [e-mail]
Today (3 hours ago) #17 [e-mail]
Removing restrictions since this is public.

[Reactie gewijzigd door kwakzalver op 22 juli 2024 17:15]

[Garma]

daarnaast, dit is een bug report die als nieuws wordt gepubliceerd.. ik begrijp de nieuwswaarde niet zo.

[kaneter]

Er staat geen NULL character in die URL. Het gedeelte "%%30%30" bestaat uit een foute escape ("%%" is ongeldig"), de tekens 3 en 0, en vervolgens een juiste escape ("%30"). "%30" staat voor het teken "0" (het getal nul dus, of zero in het Engels, niet "null"). Om een NULL character te maken in een URL, gebruik je "%00".

[Gyske]

Zoals te lezen in de bugtracker:
%30 = 0
%00 = null
Wat er gebeurd is dit : "%(%30)(%30)" -> "%00" = null -> boem!

[Reactie gewijzigd door Gyske op 22 juli 2024 17:15]

[Laloeka]

URL decoding zou eigenlijk niet meer dan ééns toegepast moeten worden. Het zou dus gewoon bij "%00" moeten stoppen, als in, het echte karakter % gevolgd door twee 0 karakters. Dit zou niet meer gezien moeten worden als een gecodeerde 0-byte.

Ik kan ook geen andere dubbele codering werkend krijgen met Chrome, dus het lijkt erop dat er gewoon echt een foutje zit in het decoderingsalgoritme van Google.

[EpicEraser]

Ik heb even in het bug report gekeken en dit is hoe ik het begrepen heb:

Het probleem lijkt te zijn dat ze bij het extraheren van de username:password een extra unescape doen (per abuis). Waar de URL van tevoren valid was, wordt hij daarna invalid (null character mag niet). Deze situatie wordt niet netjes afgehandeld, en leidt tot een crash.

Hier is de echte uitleg (uit het bug report):
Looking into the DCHECK failure, this arises because of the following sequence:
* An input string "http://a.com/%%30%30" is unescaped to "http://a.com/%00" and considered a valid GURL.
* This GURL is eventually sent to GURLToDatabaseURL(), which calls ReplaceComponents() on it to strip the username and password.
* ReplaceComponents() re-canonicalizes the URL.
* Canonicalization of the path hits the "%00" sequence, unescapes, sees this is a 0 char which is invalid in URLs, leaves it escaped, but marks the resulting URL as invalid.
* Once we return back to GURLToDatabaseURL(), it calls .spec() on the new URL, expecting it to be valid, since the input URL was guaranteed to be valid and we merely removed the username and password. This DCHECKs.

[geertdo]

% + 2 x '0' = '%00' (NULL). Url decoding kan meermalig uitgevoerd worden.

[kaneter]

Ah, je kan 'm inderdaad ook zien als %(%30%30). Dan zou er "%00" staan. Maar "%00" zelf veroorzaakt geen crash.

[.oisyn]

Zou niet moeten. Als dat zo is kun je dus nooit fatsoenlijk de % escapen, want die kan altijd opnieuw geïnterpreteerd worden als er toevallig een getal achter staat. Het is gewoon Chrome die hier grondig de fout in gaat.

[jurjen_g]

In welk reallife scenario is dit dan een probleem? Ik ben nog nooit een URL tegengekomen met deze vreemde opbouw?

[Rob Wu]

Dit zou een serieus probleem kunnen zijn geweest als de crash door geheugencorruptie o.i.d. zou worden veroorzaakt. Hier is dat niet het geval, maar ik wil maar zeggen dat "Ik ben nog nooit een URL tegengekomen met deze vreemde opbouw?" geen goede indicator is of iets wel of niet een probleem is in een reallife scenario.

Juist de randgevallen waar geen rekening mee is gehouden is een bron van beveiligingsfouten. Voorbeeldje: Je zal waarschijnlijk nooit een negatief getal invoeren als je geld wilt overmaken, maar dat wilt niet zeggen dat het geen probleem zou zijn als een bank zo'n verzoek zou accepteren.

[Iblies]

Software moet zich gedragen zoals het het hoort, en geen verassingen met zou meebrengen. Bagataliseren doet me denken aan de uitspraak;

"It's not a bug; it's an undocumented feature!"

https://en.wikipedia.org/wiki/Undocumented_feature

De combinatie van de url komt zo vreemd over dat ik me afvraag waar eigenlijk de oorzaak ligt. De verklaring dat het om oude code gaat is erg vaag. Betekent het dat het in de oude versie het deed, is er code niet opgeruimd, maar belangrijker, werkt de nieuwe code niet goed samen met de rest, wat ook zeer reëel is.

[Verwijderd]

Het gaat er om, dat de fout ook in de Chromium webbrowser zit.
Dat is de browser, waar Google de source code van gebruikt voor de Chrome browser.
Chromium is trouwens open-source, dus de code mag gebruikt worden.

[Dreamvoid]

Grapjassen die deze link op allerlei sites/forums plaatsen.

[Tourmaline]

Ik heb er tot op heden ook nog geen last van gehad.
Hij crasht wel als ik de voorbeeld url in de adresbalk invoer en op enter druk, dan gaat hij hard op zijn gat!

Als je op de url probeert te klikken krijg je een foutmelding.

[Reactie gewijzigd door Tourmaline op 22 juli 2024 17:15]

[zvbhvb]

Met linux iptables string matching is dit eenvoudig op te lossen:

iptables -I INPUT -p tcp -s 0.0.0.0/0 -m string --string “/%%30%30” --algo bm -j DROP

Chrome of chromium crashed dan niet meer, de pagina word niet eens geladen.

[MSalters]

Nee, en jouw reactie _ook_ niet meer. Je iptables voorbeeld is een goed voorbeeld waarom stateless string matching een dom idee is: de string zelf is niet magisch fout, het gebruik ervan in 1 specifieke context (HTTP URL voor Chrome) is problematisch. Je zou theoretich nog iets kunnen bereiken met een regex match, maar dat wordt extreem duur: je ben dan redelijk wat state aan het bewaren in de regex matcher.

[zvbhvb]

De (iptables) state doet er in dit geval niet toe, zo crashed chrome nog steeds als je die bepaalde string inkomend toelaat als zijnde een established connection waar normaal gesproken de default policy DROP is op binnenkomende verbindingen.Iptables stringmatching is iets heel anders dan bijvoorbeeld Dansguardian regex matching.Het makkelijkste is tijdelijk ipv Chrome Firefox gebruiken.

[The Zep Man]

Chrome of chromium crashed dan niet meer, de pagina word niet eens geladen.

Aangenomen dat de pagina niet over een SSL/TLS verbinding wordt opgevraagd/gestuurd.

[zvbhvb]

Yep.

[eymey]

Hehe, goeie

De vraag is natuurlijk wel hoe 'duur' het voor je router wordt om ieder pakketje dat binnen komt aan een string inspection te gaan onderwerpen .

[.oisyn]

Het gaat niet om het laden van de pagina, het gaat om het verwerken van de URL.

[atomos]

hmmm, Linux Opera geeft onvoldoende geheugen aan.. dus ook een fout melding..

[jvwou123]

Opera tegenwoordig niets meer dan een eigen schil om chrome heen (kort gezegd)

[Ayyylias]

Dan zouden de benchmarks technisch gezien hetzelfde moeten zijn.

[i-chat]

nee, want webkit heeft meerdere versies, en het is aan devs om bepaalde instellingen te doen, bijv meer geheuge toeweizen aan proces x en minder aan y... dergelijke optimalisaties kunnen het beeld flink bijstellen... bovendien kan de schil er ook voor zorgen dat er bepaalde extra bewerkingen nog plaats vinden die het systeem belemeren in de toeweizing van resources aan de render-engine... kortom, de benchmarks zullen vergelijkbaar kunnen zijn maar er zullen toch verschillen zijn.

[Feanathiel]

Toch grappig, want hier op windows kicked hij er alleen maar een tab uit. Het is niet zo dat de browser volledig crashed.

[Tonko Boekhoud]

Crasht bij mij op Win 7 wel volledig, met een foutmelding Chrome stopped working, een infomelding Chrome stopped working, en de melding van Win 7 zelf.

[eymey]

Hier op Win7 crashed chrome alleen maar de betreffende tab

[devil-strike]

Ja zelfde hier maar dan onder win10.

[Milosonator]

Mogelijk is het een vergelijkbare fout op chrome die op een andere manier wordt weergegeven. Opera is immers ook Webkit.

[Loller1]

Dit is geen fout in Webkit, daarbij is Opera ook geen Webkit browser maar Blink. De fout zit ergens in Chromium of is in Blink geslopen sinds de fork, anders zou Safari hier ook last van hebben, en dat is niet het geval.

[itsalwaysme]

Hier omder Windows 10 herstart Opera. Dus lijkt daar ook in te zitten.

[Verwijderd]

Opera is een schil om Chrome heen. Logisch dus.

[WhatsappHack]

Op Mac OS X ook enkel onvoldoende geheugen.
... Totdat je voor de lol de URL probeert te openen in plaats van enkel te hoveren, dan crasht de browser helemaal.

[Djesse8999]

Betekend dit dat chrome bij een mouse over de webpagina al inlaad zodat als je klikt de pagina niet meer hoeft te laden?

[Foodie88]

Ik denk dat de URL reeds gedecodeerd wordt op het moment dat je hovert. Als ik het goed begrijp, is het het decoderen van de karakters in de URL dat de crash veroorzaakt.

[RobIII]

Eerder de "preview" van de url die je linksonder krijgt als je over een link hovert vermoed ik.

[Verwijderd]

ook vivaldi crasht

[_Thanatos_]

Dat is dan weer raar. Die browser pretendeert een reincarnatie van Opera te zijn, nadat Opera zichzelf de kak op heeft geholpen door een Chromium-kloon uit te poepen ipv een eigen browser. En nu blijkt dus dat Vivaldi eigenlijk ook een Chromium-kloon is.

Jammer, want ik hoopte dat Vivaldi zich zou beperken tot de layout engine, en de GUI gewoon goed zou doen. Ok, skip dus.

[MSalters]

Vivaldi gebruikt net zoals Opera de _Blink_ engine (WebKit afgeleide), net zoals Chromium dat doet. Dat zou geen verrassing moeten zijn.

[_Thanatos_]

Nee, Opera is niet een browser die toevallig de Blink engine gebruikt, het is een Chromium-kloon. En daardoor wordt de Blink engine gebruikt. Een klein maar belangrijk verschil.

Hoe dan ook om die reden heeft Opera nu te lijden onder bugs waar ze zelf helemaal *niets* aan kunnen doen.

[aadje93]

Hoezo is het "opvallend" dat hij al crasht als je mouse-over doet, volgensmij doet chrome ook gewoon aan een soort prefetching waarbij de url waar je muis overgaat al vast geresolved word door de DNS servers om zo een "snellere" internet ervaring te geven (firefox doet het nog een stapje verder door de complete html ook maar vast binnen te halen ex images dacht ik)

[afraca]

Volgens mij is het in dit geval simpeler. Je krijgt soms linksbeneden bij het hoveren te zien waar het naar toe linkt. Dus zelfs zonder al die prefetching zou het al triggeren.

[DrNizeGuy]

De android versie heeft dit probleem in ieder geval niet, zowel de standaard als de beta versie.

[Daantje20]

En in chrome op Android precies het zelfde.