PREFACE
-------

I've found an issue with URLPatterns (src/extensions/common/url_pattern.cc) which makes it possible to construct an URL pattern with an empty host. While this isn't a vulnerability in itself, it violates an invariant which other code seems to rely on, namely that the host is never empty. I haven't found a concrete exploit based on it yet, only various other strange and potentially dangerous behavior. Still, I feel it's better to report this privately as there's a lot of permission related code using URLPatterns and relying on that invariant. Because of that, I believe there are possibly ways to exploit this further than I've done below.

Let me note that this is the first time I'm reporting something as security bug, so please let me know if you need any additional information.

VULNERABILITY DETAILS
---------------------

A URL pattern such as "https://:443/" is treated as valid, despite not having a host (only a port). This is because an empty host is checked in various places (see PARSE_ERROR_EMPTY_HOST in url_pattern.cc) but never when host/port are separated.

Interestingly enough, there's even a unittest for this:
https://cs.chromium.org/chromium/src/extensions/common/url_pattern_unittest.cc?l=73&rcl=fd6806b8dae4614967be60035c47303b5ec36d76

However, there are various reasons I still believe this to be a mistake:

- The normal URL parser rejects such URLs.
- Various comments in url_pattern.cc say so, and internally, an empty host is actually used for "*" (matches any host) - however, only with match_subdomains_ set to true.
- With the pattern "https://:443/", the permission dialog shows "It can read and change your data on" (sic).
- With the pattern "*://:*/", all tabs and extensions crash (failed checks) and Chrome is unusable until the extension is removed.

Exaple of failed checks when the crashes happen:
[30:30:0215/014303.207072:FATAL:dispatcher.cc(926)] fjnbnpbmkenffdnngjfgmeleoegfcffe was never loaded: 
[82:82:0215/013659.806060:FATAL:user_script.cc(304)] Check failed: URLPattern::PARSE_SUCCESS == result. Host can not be empty. *:///
(the latter seems to come from re-parsing an adjusted host name as URLPattern a second time)

Crash IDs I got for a single reproduction with the crashing pattern:
00b03a4d0572681c, ed3e7c170f596277, 59f0a336a1eafe56, 0fdda6fc9bada545, 1364a0b2af59485b, 261a46b0b74b602d, 5d289abb965161d7, 2bc92ad91874f3f5

VERSION
-------

Chromium 64.0.3282.140 (stable) on Archlinux
Chromium 66.0.3343.3 (dev) on Archlinux

I don't expect there to be any difference with another OS.

REPRODUCTION CASE
-----------------

I've attached two .crx files:

- urlmatch_text.crx: Will show the faulty text in the permission dialog. (Un)fortunately, it doesn't actually run test.js (which does alert("foo")) on any website it seems.
- urlmatch_crash.crx: As soon as it's installed, all tabs (including chrome://extensions) and all extensions will crash and you'll need to remove it (e.g. via the extension icon) to make Chrome usable again. Note that any other extensions installed will be disabled and need to be enabled by hand again.

(Since .crx files are valid(-ish) .zip files, you should be able to unpack them to get the source easily.)

PATCH
-----

I currently can't build Chromium easily, but I attached a (completely untested) patch (meant to be applied with -p0 in the src/extensions/common/ subdir) with how I'd try to solve it. I have no idea if it works properly, so feel free to ignore it if not.
 

Deleted: urlmatch_crash.crx 937 bytes

urlmatch_crash.crx 937 bytes Download

Deleted: urlmatch_text.crx 958 bytes

urlmatch_text.crx 958 bytes Download

Deleted: urlmatch.patch 1.5 KB

urlmatch.patch 1.5 KB Download