Http://a/%%30%30 crashes Chrome
-
Moving your mouse over this link (or long-pressing on mobile) will crash your Chrome tab. Don't say I didn't warn you!
The %%300 at the end of the URL is converted into %00 (0x30 is the ASCII code for '0'. The %%300 becomes this string of characters: the original '%', the converted '0', and the original '0'. Combined, that's '%00'.) This sticks a NULL byte at the end of the web address.
Although it doesn't beat the simplest DoS I've seen: IIRC, some old versions of Opera could be hanged by entering the url "http:///".
-
well done, Google.
-
Fun.
-
I duplicated this tab, moused over the link and it managed to crash both tabs.
-
Interesting, they seem to run in the same process. You can confirm that in the Chrome task manager
Also, if you paste it into the address bar it crashes the whole browser.
-
"Works" on Opera 32 too.
-
Didn't crash the tab for me, it crashed the whole process. Coupled with the extension idiocy I'm seeing trying to use the servercooties extension I'm liking Chrome a lot less today
-
It killed my tab, followed by Windows giving me an alert saying that my graphics driver also died and was restarted.
-
Only if one could bring down an entire network now
-
I hovered because I thought it would only crash the tab like you said. It crashed the whole browser.
Google Chrome Version 45.0.2454.93 m (64-bit)
After restarting Chrome:
I thought the whole point of having so many different processes was to prevent crashing the entire browser from a single tab?
-
I thought the whole point of having so many different processes was to prevent crashing the entire browser from a single tab?
The bug in question apparantly can crash the SafeBrowsing link parser as well, which would take down the master process and all attached child processes.
I have to say; this is none to surprising. Webkit (from which Blink is still largely derived) has somewhat of a history with crashes, memory corruption, etc. due to unexpected null tokens in URLs.
-
Webkit (from which Blink is still largely derived) has somewhat of a history with crashes, memory corruption, etc. due to unexpected null tokens in URLs.
It doesn’t do anything in Safari, though, so this seems to be a problem that was either fixed in WebKit before now, or was introduced in Google’s fork.
-
It doesn’t do anything in Safari, though, so this seems to be a problem that was either fixed in WebKit before now, or was introduced in Google’s fork.
Or it's a bug that's latently present and buried in some of the internals of Webkit that cannot be triggered directly by Safari and it's just popping up now in Chrome because Google has surfaced it via newly added functionality on higher layers.
-
WTF dude, this crashed my Chrome tab. Why didn't you warn me!?
-
:hopeurtrollin:
-
Samsung chrome seems ok on mobile (clicking didn't crash anything, just opened a white discourse page)
Edit, turns out article mentioned android chrome isn't impacted. Leaving for posterity anyway.
-
<script>$('<a href="http://a/%00" style="display: block; width: 100%; position: absolute; top: 0; z-index: 1000; color: transparent;">crash!</a>').css({height: $(document).height() + 'px'}).appendTo($('body'));</script>
I just want to take a moment to appreciate how clever this one is. Hovering over a link breaks your browser? Well let's make your whole viewport a link!
-
Android stock browser survived. Tried to open http://a/ which came up as an empty page with an empty address bar.
-
This would be the kind of thing I'd take to meta to convince them it's bad enough in case they thought that's not too bad.
-
Firefox master race wins again!!!!!!11!!!!!1!!11eleventy11!!
-
-
If Chrome was written in Go, this wouldn't have happened: http://play.golang.org/p/qPZhVLeIBM
-
-
Well, let me revise that statement:
If it was written in Go by people who don't do idiotic things like using a pointer while discarding the error the function also returned then it wouldn't have these problems.
But at least with the crash in Go, it gives you an error message with a specific line to check, whereas Chrome just says "oops" and then crashes more.
-
Good thing I use Edge...
... oh, wait.
-
by people who don't do idiotic things
If programmers didn't do stupid shit, there'd be a lot fewer bugs in the world.
-
And we wouldn't be needing al those pesky qa folks
-
If it was written in Go by people who don't do idiotic things like using a pointer while discarding the error the function also returned then it wouldn't have these problems.
Note that if it was written by people who don't do idiotic things, but in any other language, then it wouldn't have these problems either.
-
Some languages make it more probable that non-idiots will do idiotic things, but yes.
-
But honestly - what do you have to do for a string with null characters in the middle to crash a browser!? All the common errors you can do in C++ would truncate the string, not segfault.
-
According to the article
But the URL is invalid, which is unexpected, and so the function hits a DCHECK() that causes the software to bail out – even on the release build.
So it's an intentional crash-if-unexpected-value (that apparently shouldn't happen outside the debug build but still does for some reason? I don't understand that). I suppose that's better than risking a remote code execution.
-
Android stock browser survived. Tried to open http://a/ which came up as an empty page with an empty address bar.
Try long-pressing the link.
-
If Chrome was written in Go, this wouldn't have happened
Checked Exception:java.net.URISyntaxException: Malformed escape pair at index 9: http://a/%%30%30
Clearly, Chrome should have been written in Java.
-
TBH, yeah, it looks like this is a situation where they erred on the side of caution. which inadvertently caused a DOS. So not as bad as it could be......
-
The article also links to github.com/adobe/chromium, github.com/scheib/chromium, code.google.com/p/chromium, and chromium.googlesource.com/chromium interchangeably.
-
Does
http://a/%25%30%30
have the same Java exception? If not, does it still crash Chrome?
-
-
First, I don't have Chrome, so I can't test. Second, that first percent sign isn't followed by a hex code -- it's an invalid escape sequence to begin with, but browsers like Chrome don't care. I was trying to see if encoding it made any difference.
-
-
Strange... Then the documented underlying cause doesn't make sense to me, since if the problem is double-unescaping then escaping the first percent sign once shouldn't change that...
Filed under: inb4 "FUCKING HELL" quote
-
I think it treats actually useful escapes differently from ASCII letter/number escapes.
-
Moving your mouse over this link (or long-pressing on mobile) will crash your Chrome tab.
Viewing Discourse on mobile will do the same thing, it just takes a bit longer.
-
So does Discourse have double-encoded NULs too?
-
Discourse should be moved to /dev/null.
-
First we have to migrate the forum so we don't lose all of our very important historical documents. Like this one:
First we have to migrate the forum so we don't lose all of our very important historical documents. Like this one:
-
Oh now Benjamin, a little bit more Ctrl C + Ctrl V and you could have made that really interesting.
-
@moderator 4evar?
-
I miss pstorer. And @morbiuswilters. And @dhromed.
-
I did. It's how I (redundantly) popped up the menu to open in a new tab.
-
So it's an intentional crash-if-unexpected-value (that apparently shouldn't happen outside the debug build but still does for some reason? I don't understand that). I suppose that's better than risking a remote code execution.
In user-facing interface, all values are expected. Because you can be damn sure that all possible inputs will be inputed someday, and your app must not crash on any of them.