Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 602780 (CVE-2010-3774)

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

RESOLVED FIXED in mozilla2.0b7

Status

()

Core
Security: CAPS
P1
critical
RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: Michal Zalewski, Assigned: bz)

Tracking

({verified1.9.1, verified1.9.2})

Trunk
mozilla2.0b7
verified1.9.1, verified1.9.2
Points:
---
Dependency tree / graph
Bug Flags:
sec-bounty +
in-testsuite +

Firefox Tracking Flags

(blocking2.0 final+, blocking1.9.2 .13+, status1.9.2 .13-fixed, blocking1.9.1 .16+, status1.9.1 .16-fixed)

Details

(Whiteboard: [sg:high], URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
[ 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. ]
(Reporter)

Comment 2

7 years ago
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" />')
(Reporter)

Comment 3

7 years ago
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?
(Assignee)

Comment 5

7 years ago
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
(Assignee)

Comment 6

7 years ago
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: --- → ?
(Assignee)

Updated

7 years ago
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+
status1.9.1: --- → wanted
status1.9.2: --- → wanted
Whiteboard: [sg:moderate]
(Reporter)

Comment 8

7 years ago
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.
(Assignee)

Comment 9

7 years ago
Gah.  _And_ that GetAsciiHost change broke NS_SecurityHashURI!
(Assignee)

Comment 10

7 years ago
OK, I've verified that the only non-nested URI impl in the tree that doesn't throw from GetHost() is nsStandardURL.
(Assignee)

Comment 11

7 years ago
Created attachment 481901 [details] [diff] [review]
Fix handling of hosts in NS_SecurityCompareURIs.
(Assignee)

Comment 12

7 years ago
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)

Updated

7 years ago
Assignee: nobody → bzbarsky
Priority: -- → P1
(Assignee)

Updated

7 years ago
Whiteboard: [sg:moderate] → [need review][sg:moderate]
(Assignee)

Comment 14

7 years ago
> 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.

Updated

7 years ago
Attachment #481901 - Flags: review?(jst) → review+
(Assignee)

Updated

7 years ago
Whiteboard: [need review][sg:moderate] → [need approval][sg:moderate]
(Assignee)

Comment 15

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

Requsting approval for 2.0.
Attachment #481901 - Flags: approval2.0?

Updated

7 years ago
Attachment #481901 - Flags: approval2.0? → approval2.0+
(Assignee)

Updated

7 years ago
Whiteboard: [need approval][sg:moderate] → [need landing][sg:moderate]
blocking2.0: ? → final+
(Assignee)

Updated

7 years ago
Depends on: 604851
(Assignee)

Comment 16

7 years ago
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.
(Assignee)

Updated

7 years ago
Depends on: 604368
(Assignee)

Comment 17

7 years ago
Pushed http://hg.mozilla.org/mozilla-central/rev/2ae4af7c7620
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Whiteboard: [need landing][sg:moderate] → [sg:moderate]
Target Milestone: --- → mozilla2.0b8
(Assignee)

Updated

7 years ago
Flags: in-testsuite+
(Assignee)

Comment 18

7 years ago
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 1.9.2.12 and 1.9.1.15, 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+
(Assignee)

Comment 20

7 years ago
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
status1.9.1: wanted → .15-fixed
status1.9.2: wanted → .12-fixed
(Assignee)

Updated

7 years ago
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: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.
Keywords: verified1.9.1, verified1.9.2
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]
Group: core-security
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.