backtop


Print

It's not just the 'a' one that's been floating around

Google Inc.'s (GOOG) Chrome browser is the most used third party browser in the world.  Available for both Microsoft Corp.'s (MSFT) Windows and Apple, Inc.'s (AAPL) OS X (as well as Google's own Android mobile OS), if you include Android's Chrome browser, then Chrome is the most used browser period.

But the PC version of Chrome has a nasty bug.  A simple string of text as a URL will instantly crash the browser on click-through, mouse over, redirect, or directly typing it in the your browser's URL bar.

The bug was first discovered by researcher Andris Atteka last Friday and was reported to Google's Chromum bug tracker.  Atteka presented it as follows 'http://a/%%30%30'.

Elegant, yet deadly it is.

However, new it is not.  A similar crash in fact appears to have plagued the world's most used browser from several years back -- Internet Explorer 7 (IE7).  Based on the discussions over at Microsoft's IIS.net forums, it sounds as if the the bug was highly similar.

Basically all of these involve the appearance of the '0x00' character somewhere in a URL string.  '0x00' is better known as the NUL character (or NULL for c#/c++ programmers).  In Linux NULL is best known as the bit bucket, the place you redirect terminal text to that you don't want to see, using something like:
{ commands } >/dev/null 2>&1
(redirect stdio to /dev/null, redirect stderr (2) to point stdio (1))

...or...
 
{ commands } &>/dev/null

(same idea, but BASH(ell) specific) [source]

In c-family languages the keyword NULL is often used to refer to unallocated object pointers.  Some modern C family languages like C# have switched to the littlecase version, null, the same syntax used by Java/Javascript.  (Database and scripting languages like SQL also make use of NULL.)

A slightly different kind of "null" value is found in string parsing -- null character codes, commonly referred to NUL (with just one 'l').  Typically used to denote the end of a string, it's typed as '\0' in C-style strings.

The bug traces to a mixture of Google's own implementation and URL parsing/encoding.

When you type a URL you may notice that when you type or click on a link (url) like "a/$%&" special chacters like '$' and '%' get converted to something like 'a%2F%24%25%26' in the query part of the URL when the search engine redirects.  This is called encoding.  Encoding converts a number of special characters to tyically two-digit hexadecimal equivalents.  In the above example:
  • '/' ----> '%2F'
  • '$' ----> '%24'
  • '%' ---> '%25'
  • '&' ----> '%26'
Encoding is generally a good idea as it helps make strings more orderly and prevents them from somehow being maliciously being structured.  But double encoding (or higher) as Google does can effectively go a bridge too far, allowing for obfuscation of malicious strings, as OWASP.org points out.  To give an example here's our Domain Name encoded... then double encoded: The first encode you can actually type in the browser bar, the second will be double decoded by Google Search, but won't directly route to the link in the URI (unique resource identifier object, the class that holds the URL).

Interestingly, Google's browser DOES support direct redirects of double encoded subdomains.  For instance: Will take you to a harmless picture of URLs that I found to crash Chrome.  Here's the picture in visual form:

Google Chrome

(All of the above urls in red will crash Chrome.)

Double encoding is probably a bad idea because it allows webpages to sneakily redirect you via a malicious subdomain.  It could even be exploited by third parties exploiting well intentioned websites via advertising platforms.

But for better or worse Google has double encoding.

Interestingly, it also has in URL decoding, as well.  For instance:
Will take you to:
For the main domain only one level of decoding is supported (more will drop you into a search result).  But in subdomains or files -- like the image above, Google's Chrome will double decode as well!
Interestingly Google Chrome decodes and replaces in the address bar up to three layers of encoded numbers, yielding a result that has no special encoding. And up to six layers will redirect properly to the url although layers 4-6 will stay encode in the url bar.
Click enter on the URL bar again and watch them disappear.

To try this yourself, just find an image with a number and keep pasting '%3' in front of the number (as '%31' through '%39' map to numbers '1' through '9' in ASCII URL encoding -- see this map).

Here's a neat trick.  

Any double decode or longer in Edge just does nothing.  If you have multiple single decodes Edge opens it amicably.  But you enter weirdo world when you have just one numeric decode in a URL an try to open it in Edge.

My default browser (Settings > System > Default apps > Web browser in Windows 10) was set to Opera Software ASA's (STO:OPERAO) titular browser.  When I tried to open a single encoded url like:
 
it opens it in Opera.  Bizarre.  Edge shows all sorts of strange behavior.  It will sometimes double decode all on its own.  Other times it will just sit there.  Other times still it will open in a third party browser.

But I digress.  Back to the Chrome bug.  The Chrome bug happens when it encounters something that encodes to '%00' (but not '%00' itself) in the final part of a URL (be it  domain or file).

The Register tracked the crash in Chrome's debug logs and discovered the following:
  • The %%300 at the end of the URL is converted into %00 (0x30 is the ASCII code for '0'. The %%300becomes 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.
  • This URL is passed to GURLToDatabaseURL() which calls ReplaceComponents().
  • This causes the URL to be processed again, hitting the NULL byte. It figures that shouldn't be there and marks the URL as invalid.
  • The code path returns to GURLToDatabaseURL() which expects the URL to still be valid, and calls spec() on it.
  • 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.
  • When hovering the mouse over the URL, the web address, which is marked as invalid, is sent to another part of the browser that expects valid-only addresses – causing the tab to be blown away.
So basically the decode to 0x00 is causing the URL to be deemed invalid and throwing some sort of deep exception that goes unhandled and crashes Chrome.

I did some poking around of my own and found this it is a mildly complex bug.

Chrome crash

For example, typing 'a/%%300' in the URL bar and pressing enter won't crash the browser, instead taking you to a search.  But if you type the same, but start with 'http://a...' it will crash.

Assuming your goal is to crash the browser, the easiest way to force it to crash in as few characters as possible is to only encode one of the zeroes (as the above does).  And to force it to crash without the 'http://' add a single forward slash '/' to the end of 'a/%%300' or 'a/%0%30'.  Voilà -- a crash in a can -- and in only 8 characters!

I believe my strategy holds the record for the shortest string to trigger this bug.

Also it hasn't been thorough covered that this bug doesn't just occur at the end of characters.

To work the code must be found in:
  • a string with a type specifier (e.g. http:// or file:///) URI
  • An unspecified string with at least two layers of subdomains (in the simples case one subdomain terminatinated in a slash. (e.g. testme/<crashcode>/)
Here's some more details of how you can form a crash string:
Use up to three layers of decoding by putting '%3' in front of all numbers recursively until a maximum of 3 levels is hit:
  • a/%00/
  • a/%%30%30/
  • a/%%%33%30%%33%30/
Why three? It's because of how many levels of automatic substitution is done (one level is eaten up by the '%00' code itself).  And don't forget you can hide it inside subdomains:

Hide the crash

Of course, this isn't a big security risk, but it is an annoyance.  Supposedly Chromium engineers are hard at work at Google fixing this bug.  My question is, do they know what they're doing?  It's not a tough problem to solve.  Let's see.  
  • The match (malicious string) is comprised of 0, 3, and '%'.
  • The match is found in a subdomain
  • The string always has at least two subdomains or a single subdomain but a proceeding type identifier (like http://)
  • The match is at least 5 characters long as you need at least one second-level numeric decode to make the bug work ('%%300' or '%0%30')
  • The match is at most 15 characters as it's limited to two recursive numeric decodes. ('%%%33%30%%33%30')
Just use a pair of regexes which in Perl would be something like:
  • m"http://|file:///|...etc...|....*/.*[%30]{5,15}.*"
  • m".*/.*[%30]{5,15}.*/.*"
... please curb the snide remarks, as I did not test that syntax.  I know that it might need a little cleaning to delimit special characters and correctly catch all cases, but that's the basic idea and it took me 10 minutes.  It's been several days since this bug has been published, but Google has been unable to fix it.

What is Google thinking letting such a massively ubiquitous bug survive so long, when it's so easy to detect the offending URL and sanitize it.

Ah well, at least Android is immune to the bug.  And on the plus side, humorous devs have cooked up games like "Tree Master" [via Vice's Motherboard] (which involves a maze in w/ bears and such  crashing your browser when you lose:

Chrome Crash

...or "LinkofDeath" which has a link chase your mouse (as crashes also occur on mouseover due to preview features in Chrome).

Chrome crash

...dare I say it?  "It's a feature!" (Ed. -- But, not really.  Fix it, please.)

Source: Chromium





"Spreading the rumors, it's very easy because the people who write about Apple want that story, and you can claim its credible because you spoke to someone at Apple." -- Investment guru Jim Cramer
Related Articles













botimage
Copyright 2017 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki