602780 - (CVE-2010-3774) about:neterror, certerror permit URL spoofing by being same-origin with about:blank

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect, P1)

Description

[Michal Zalewski]

This demo should speak for itself:

http://lcamtuf.coredump.cx/ffabout/

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]

[ 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]

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="http://www.google.com/favicon.ico" type="image/x-icon" />')

Comment 3

[Michal Zalewski]

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]]

Hey Boris - I think this probably lives somewhere in core, but I confess I'm not really sure where. Thoughts?

Comment 5

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

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]]

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]

You don't, as in, if you navigate to https://www.paypal.com./ 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 [:bzbarsky]]

Gah.  _And_ that GetAsciiHost change broke NS_SecurityHashURI!

Comment 10

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

Attachment: Fix handling of hosts in NS_SecurityCompareURIs.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

> 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 [:bzbarsky]]

Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

Requsting approval for 2.0.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/2ae4af7c7620

Comment 18

[Boris Zbarsky [:bzbarsky]]

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]]

Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

Approved for 1.9.2.12 and 1.9.1.15, a=dveditz for release-drivers

Comment 20

[Boris Zbarsky [:bzbarsky]]

Pushed:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8b515f27f430
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/48f46881338a

and a bustage fix for 1.9.1:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/866a335ecda1

Comment 21

[Al Billings [:abillings - ex-MoCo]]

Verified fixed for 1.9.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13pre) 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:1.9.1.16pre) Gecko/20101118 Shiretoko/3.5.16pre.

Comment 22

[Daniel Veditz [:dveditz]]

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.