Crash Google Chrome with one tiny URL: We cram a probe in this bug

How clicking on or even rolling your mouse over it will knacker browser

You can crash the latest version of Google Chrome with a simple tiny URL.

Just rolling your mouse over it in a page, launching it from another app such as an email client, or pasting it into the address bar, will kill either that tab or the whole browser.

It's perfect for pranking friends by sending it to them in emails and messages.

The flaw was spotted just before the weekend by a chap called Andris Atteka, who blogged about the programming blunder here, and filed a bug report here.

This crashes someone's browser in web gtalk/chrome if you msg them that URL https://t.co/vi0e10IEFH

— mdowd (@mdowd) September 20, 2015

Below is a screenshot of two forms of the offending URL – we won't put them this article as-is, because they will crash your tab if you accidentally wander your pointer over them in Chrome. And that's not nice.

We've tested it on Chrome 45.0.2454.93 on OS X El Capitan and Windows 10, and both flavors of the browser are vulnerable. Chromebooks and Linux flavors of the browser are also crashed by the URL, plus Opera 32.0 which is based on Chromium 45, we're told. Android's Chrome is not affected, it seems.

"Unfortunately no reward was awarded as this was deemed to be only a denial-of-service vulnerability," wrote Atteka. "Anyway, making secure software is much harder than finding issues in it. Thanks Google."

What's cool about this bug is that it triggers a fatal exception (a SIGTRAP) rather than the usual memory access violation error caused by an overrun buffer, heap corruption, or similar – even in released code. This means some part of the executable was reached that the programmers never expected normal users to hit. As it turns out, the code at fault is some really old stuff.

This is the crash information from OS X:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   com.google.Chrome.framework 0x0000000102b18a45 0x102500000 + 6392389
1   com.google.Chrome.framework 0x0000000105900595 0x102500000 + 54527381
2   com.google.Chrome.framework 0x00000001059083d2 0x102500000 + 54559698

What happens is this:

• 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.
• 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.

There's more discussion on how the developers plan to solve this problem in the Chromium bug tracker. It's sorta like the gaffe that plagued Skype in June.

"There are going to be crashes all over as a result of this. This is a mess," sighed one Chromium project contributor a couple of hours ago. The team are working on a fix, so stay tuned. ®