Closed Bug 602780 (CVE-2010-3774) Opened 11 years ago Closed 11 years ago

about:neterror, certerror permit URL spoofing by being same-origin with about:blank


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




Tracking Status
blocking2.0 --- final+
blocking1.9.2 --- .13+
status1.9.2 --- .13-fixed
blocking1.9.1 --- .16+
status1.9.1 --- .16-fixed


(Reporter: lcamtuf, Assigned: bzbarsky)




(Keywords: verified1.9.1, verified1.9.2, Whiteboard: [sg:high])


(1 file)

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.
[ 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. ]
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" />')
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.
Hey Boris - I think this probably lives somewhere in core, but I confess I'm not really sure where. Thoughts?
You betcha it does.  XPConnect, I'd guess.  There's no CheckPropertyAccessImpl call there, so I assume wrappers fail.

This happens on trunk too.
Version: 3.6 Branch → Trunk
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.
Severity: normal → critical
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Component: Security → Security: CAPS
Product: Firefox → Core
QA Contact: firefox → caps
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.
blocking1.9.1: ? → .15+
blocking1.9.2: ? → .12+
Whiteboard: [sg:moderate]
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.
Gah.  _And_ that GetAsciiHost change broke NS_SecurityHashURI!
OK, I've verified that the only non-nested URI impl in the tree that doesn't throw from GetHost() is nsStandardURL.
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.
Attachment #481901 - Flags: review?(jst)
Assignee: nobody → bzbarsky
Priority: -- → P1
Whiteboard: [sg:moderate] → [need review][sg:moderate]
> 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.
Attachment #481901 - Flags: review?(jst) → review+
Whiteboard: [need review][sg:moderate] → [need approval][sg:moderate]
Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

Requsting approval for 2.0.
Attachment #481901 - Flags: approval2.0?
Attachment #481901 - Flags: approval2.0? → approval2.0+
Whiteboard: [need approval][sg:moderate] → [need landing][sg:moderate]
blocking2.0: ? → final+
Depends on: 604851
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.
Depends on: 604368
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [need landing][sg:moderate] → [sg:moderate]
Target Milestone: --- → mozilla2.0b8
Flags: in-testsuite+
Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

As expected, this applies as-is to both branches.
Attachment #481901 - Flags: approval1.9.2.12?
Attachment #481901 - Flags: approval1.9.1.15?
Comment on attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.

Approved for and, a=dveditz for release-drivers
Attachment #481901 - Flags: approval1.9.2.12?
Attachment #481901 - Flags: approval1.9.2.12+
Attachment #481901 - Flags: approval1.9.1.15?
Attachment #481901 - Flags: approval1.9.1.15+
Target Milestone: mozilla2.0b8 → mozilla2.0b7
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.
Alias: CVE-2010-3774
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.
Whiteboard: [sg:moderate] → [sg:high]
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.