Last Comment Bug 602780 - (CVE-2010-3774) about:neterror, certerror permit URL spoofing by being same-origin with about:blank
: about:neterror, certerror permit URL spoofing by being same-origin with about...
: verified1.9.1, verified1.9.2
Product: Core
Classification: Components
Component: Security: CAPS (show other bugs)
: Trunk
: All All
: P1 critical (vote)
: mozilla2.0b7
Assigned To: Boris Zbarsky [:bz]
Depends on: 604368 604851
  Show dependency treegraph
Reported: 2010-10-07 22:05 PDT by Michal Zalewski
Modified: 2014-09-04 09:39 PDT (History)
12 users (show)
rforbes: sec‑bounty+
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Fix handling of hosts in NS_SecurityCompareURIs. (4.18 KB, patch)
2010-10-08 13:00 PDT, Boris Zbarsky [:bz]
jst: review+
jst: approval2.0+
dveditz: approval1.9.2.13+
dveditz: approval1.9.1.16+
Details | Diff | Splinter Review

Description Michal Zalewski 2010-10-07 22:05:09 PDT
This demo should speak for itself:

In essence, "special" about:neterror / about:certerror pages are reachable from about:blank - but are displayed in special contexts where the contents of the address bar point to the destination to which the browser attempted to navigate. This allows address bar spoofing, as shown in the PoC.
Comment 1 Michal Zalewski 2010-10-07 22:23:11 PDT
[ In general, I think you can trigger neterror or certerror in pretty much every legit domain: pick a location that returns 204, redirects to self, has a cert for a different vhost, is not listening on this port, has no such CNAME, or anything else along these lines. ]
Comment 2 Michal Zalewski 2010-10-07 22:26:17 PDT
I can also override the warning triangle icon by injecting any other favicon in the intercepted document, e.g.:

javascript:void(document.body.innerHTML='<link rel="shortcut icon" href="" type="image/x-icon" />')
Comment 3 Michal Zalewski 2010-10-07 22:44:21 PDT
This also allows the appearance of a legitimate about:certerror to be completely changed, possibly to confuse the user; presumably the same for about:blocked, etc. I am not particularly familiar with XUL, so I am not sure if this permits malicious content to interact with these interstitials in a more meaningful ways, but it's a bit scary.
Comment 4 Johnathan Nightingale [:johnath] 2010-10-08 06:14:23 PDT
Hey Boris - I think this probably lives somewhere in core, but I confess I'm not really sure where. Thoughts?
Comment 5 Boris Zbarsky [:bz] 2010-10-08 06:32:15 PDT
You betcha it does.  XPConnect, I'd guess.  There's no CheckPropertyAccessImpl call there, so I assume wrappers fail.

This happens on trunk too.
Comment 6 Boris Zbarsky [:bz] 2010-10-08 06:48:04 PDT
Oh, man.  Here're the relevant code bits:

241 nsSimpleURI::GetHostPort(nsACString &result)
242 {
243     // Note: Audit all callers before changing this to return an empty
244     // string -- CAPS and UI code may depend on this throwing.
245     return NS_ERROR_FAILURE;
246 }

382 nsSimpleURI::GetAsciiHost(nsACString &result)
383 {
384     result.Truncate();
385     return NS_OK;
386 }

and NS_SecurityCompareURIs was changed in bug 442812 to use GetAsciiHost instead of GetHost.  I thought nsSimpleURI::GetAsciiHost did the same as GetHost, but clearly I was wrong.

We need to either got back to GetHost, make GetAsciiHost throw, or add an explicit check for "scheme doesn't actually support useful hosts" in NS_SecurityCompareURIs.  This third is probably safest...

We need this on 1.9.1 too.
Comment 7 Daniel Veditz [:dveditz] 2010-10-08 10:12:17 PDT
I haven't tried it, but I assume you do not get SSL security markings through this spoof. In the missing host case we don't even make a connection to get cert information, but in the 204 case only "mostly sure" the neterror icon will clear it.
Comment 8 Michal Zalewski 2010-10-08 10:17:39 PDT
You don't, as in, if you navigate to and intercept about:certerror, you simply have no SSL indicators shown at all.

I am not sure if malicious JS can actually click through any of the UIs; presumably not, calling click() on the XUL button does not seem to be having any effect, but I don't entirely understand why.
Comment 9 Boris Zbarsky [:bz] 2010-10-08 11:49:37 PDT
Gah.  _And_ that GetAsciiHost change broke NS_SecurityHashURI!
Comment 10 Boris Zbarsky [:bz] 2010-10-08 11:53:15 PDT
OK, I've verified that the only non-nested URI impl in the tree that doesn't throw from GetHost() is nsStandardURL.
Comment 11 Boris Zbarsky [:bz] 2010-10-08 13:00:05 PDT
Created attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.
Comment 12 Boris Zbarsky [:bz] 2010-10-08 13:01:29 PDT
Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

I took the liberty of adding some actual regression tests so this won't happen again.
Comment 14 Boris Zbarsky [:bz] 2010-10-11 20:53:46 PDT
> Are any of those scarier? 

I think so.  For example, this bug makes about:blank same-origin with about:config (or about:addons, or other system-principal about: stuff).  And while web pages can't link to the latter, they _can_ trick users into loading it into a window they have a handle to, I think.  And then we lose.
Comment 15 Boris Zbarsky [:bz] 2010-10-12 18:12:54 PDT
Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

Requsting approval for 2.0.
Comment 16 Boris Zbarsky [:bz] 2010-10-15 20:42:33 PDT
Looks like compartments broke some stuff that doesn't get exercised until this bug is fixed... So landing this depends on fixing bug 604851 first.
Comment 17 Boris Zbarsky [:bz] 2010-10-18 13:04:36 PDT
Comment 18 Boris Zbarsky [:bz] 2010-10-18 13:07:11 PDT
Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

As expected, this applies as-is to both branches.
Comment 19 Daniel Veditz [:dveditz] 2010-10-20 10:36:12 PDT
Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

Approved for and, a=dveditz for release-drivers
Comment 21 Al Billings [:abillings] 2010-11-18 16:07:29 PST
Verified fixed for 1.9.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101118 Namoroka/3.6.13pre. 

Verified fixed for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101118 Shiretoko/3.5.16pre.
Comment 22 Daniel Veditz [:dveditz] 2010-12-03 12:51:47 PST
While the original report appeared to be sg:moderate, the underlying bug in NS_SecurityCompareURI could potentially lead to worse things (see comment 14). raising to sg:high.

Note You need to log in before you can comment on or make changes to this bug.