Bug 848253 (CVE-2013-1709)

It's possible to set a document's URI to a different document's URI

VERIFIED FIXED in Firefox 23

Status

()

Core
Document Navigation
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: moz_bug_r_a4, Assigned: smaug)

Tracking

(Blocks: 1 bug, {sec-high})

unspecified
mozilla24
x86
Windows XP
sec-high
Points:
---
Bug Flags:
sec-bounty -
in-testsuite ?

Firefox Tracking Flags

(firefox20 wontfix, firefox21 wontfix, firefox22- wontfix, firefox23+ verified, firefox24 verified, firefox-esr1723+ verified, b2g1823+ fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 affected)

Details

(Whiteboard: [adv-main23+][adv-esr1708+])

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
When a replace load happens in a subframe, nsDocShell::AddToSessionHistory reuses an existing SHEntry without creating a new BFCache entry. This can cause nsDocShell::InternalLoad to do a short-circuited load between different documents. By using this bug, it's possible to set a document's URI to a different document's URI.

* An attacker can create a fake login page whose URI is a real login page's URI. And, if a password for the real login page was already saved in the Password Manager, an attacker can steal the password without user interaction.

* An attacker can inject scripts into a page that uses external scripts with relative URLs.
(Reporter)

Comment 1

4 years ago
Created attachment 721601 [details]
testcase 1 - fake login page

This works on fx17-22.

Target page is https://www.getpersonas.com/en-US/signin

This creates a fake login page whose URI is the target page's URI. And, if you already saved a password for the target page, the Password Manager will automatically fill in the password.
(Reporter)

Comment 2

4 years ago
Created attachment 721604 [details]
testcase 2 - XSS

This works on fx17-22.

Target page is https://wiki.mozilla.org/Main_Page

This injects a script that opens an alert dialog with cookies into the target page.
(Reporter)

Comment 3

4 years ago
Please use the following URL to run testcase 2:

jar:https://bugzilla.mozilla.org/attachment.cgi?id=721604!/x.html
Flags: sec-bounty?
Keywords: sec-high

Updated

4 years ago
Blocks: 835618
Flags: sec-bounty? → sec-bounty-
Olli, could you dig in here?
Component: Security → Document Navigation
(Assignee)

Updated

4 years ago
Assignee: nobody → bugs
Olli any luck?
(Assignee)

Comment 7

4 years ago
Sorry about the delay. I'm going trough all my sg* bugs this week and this one is the last high/crit
rated so first one in the todo list.
(Assignee)

Comment 8

4 years ago
(In reply to moz_bug_r_a4 from comment #1)
> Created attachment 721601 [details]
> testcase 1 - fake login page
> 
> This works on fx17-22.
> 
> Target page is https://www.getpersonas.com/en-US/signin
Looks like getpersonas page has changed.
(Assignee)

Comment 9

4 years ago
(In reply to moz_bug_r_a4 from comment #2)
> Created attachment 721604 [details]
> testcase 2 - XSS
> 
> This works on fx17-22.
> 
> Target page is https://wiki.mozilla.org/Main_Page
> 
> This injects a script that opens an alert dialog with cookies into the
> target page.

I don't see any alert dialog when loading jar:https://bugzilla.mozilla.org/attachment.cgi?id=721604!/x.html
but the address of the iframe page looks wrong.
(Assignee)

Comment 10

4 years ago
Created attachment 747174 [details] [diff] [review]
v1

I think we should do this. I wish replace/bfcache handling wasn't so fragile.
Attachment #747174 - Flags: review?(justin.lebar+bug)
(Assignee)

Comment 11

4 years ago
Figuring out what kind of tests would be good for this. Tests should land way after the patch has landed though.
(Reporter)

Comment 12

4 years ago
(In reply to Olli Pettay [:smaug] from comment #8)
> (In reply to moz_bug_r_a4 from comment #1)
> > Created attachment 721601 [details]
> > testcase 1 - fake login page
> > 
> > This works on fx17-22.
> > 
> > Target page is https://www.getpersonas.com/en-US/signin
> Looks like getpersonas page has changed.

(In reply to Olli Pettay [:smaug] from comment #9)
> (In reply to moz_bug_r_a4 from comment #2)
> > Created attachment 721604 [details]
> > testcase 2 - XSS
> > 
> > This works on fx17-22.
> > 
> > Target page is https://wiki.mozilla.org/Main_Page
> > 
> > This injects a script that opens an alert dialog with cookies into the
> > target page.
> 
> I don't see any alert dialog when loading
> jar:https://bugzilla.mozilla.org/attachment.cgi?id=721604!/x.html
> but the address of the iframe page looks wrong.

testcase 1 and 2 no longer work because the target pages have changed.  Also, testcase 1 needs a trivial change to work on trunk.  I'll attach new testcases.
(Reporter)

Comment 13

4 years ago
Created attachment 747846 [details]
testcase 3 - fake login page

This works on fx17-23.

Target page is https://www.rooms.hp.com/signin.aspx

This creates a fake login page whose URI is the target page's URI. And, if you already saved a password for the target page, the Password Manager will automatically fill in the password.
(Reporter)

Comment 14

4 years ago
Created attachment 747847 [details]
testcase 4 - XSS

This works on fx17-23.

Target page is http://www8.hp.com/us/en/sitemap.html

This injects a script that opens an alert dialog with cookies into the target page.
(Reporter)

Comment 15

4 years ago
Please use the following URL to run testcase 4:

jar:https://bugzilla.mozilla.org/attachment.cgi?id=747847!/x.html
Attachment #747174 - Flags: review?(justin.lebar+bug) → review+
smaug and I discussed this over PM.  Here's a slightly edited version.

<jlebar> I wanted to make sure I understood what's going on here.
<jlebar> We're doing a replace-history load into a subframe, but then the testcase causes us to end up using that shentry's bfcache entry after we replace it?
<jlebar> But the bfcache is the only thing that's wrong here -- e.g. the URI isn't wrong?
<smaug> so the key thing is the short-circuit load when going back
<jlebar> ah
<jlebar> as usual
<smaug> we end up calling SetDocumentURI and what not
<jlebar> okay, I see.
(Assignee)

Comment 17

4 years ago
I'll try the new testcases.
(Assignee)

Comment 18

4 years ago
Comment on attachment 747174 [details] [diff] [review]
v1

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Not very easily, IMO

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Comment will be about releasing old data earlier

Which older supported branches are affected by this flaw?
All

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
The same patch should apply everywhere.

How likely is this patch to cause regressions; how much testing does it need?
Changes to session history are somewhat regression risky.
Attachment #747174 - Flags: sec-approval?
status-b2g18: --- → affected
status-firefox20: --- → wontfix
status-firefox21: --- → wontfix
status-firefox22: --- → affected
status-firefox23: --- → affected
status-firefox-esr17: --- → affected
tracking-b2g18: --- → ?
tracking-firefox22: --- → ?
tracking-firefox23: --- → ?
tracking-firefox-esr17: --- → +
Whiteboard: [checkin after 5/14]
Comment on attachment 747174 [details] [diff] [review]
v1

sec-approval+ for m-c after 5/14. Please nominate patches for branches then.
Attachment #747174 - Flags: sec-approval? → sec-approval+

Updated

4 years ago
tracking-firefox22: ? → +
tracking-firefox23: ? → +
(Assignee)

Comment 20

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/1695bdfbfa8e
https://hg.mozilla.org/mozilla-central/rev/1695bdfbfa8e
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-b2g18-v1.0.1: --- → affected
status-firefox24: --- → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Whiteboard: [checkin after 5/14]
(In reply to Olli Pettay [:smaug] from comment #20)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/1695bdfbfa8e

Can you nominate for uplift to FF22/23 please?
Flags: needinfo?(bugs)
(Assignee)

Comment 23

4 years ago
Comment on attachment 747174 [details] [diff] [review]
v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): NA 
User impact if declined: see comment 0
Testing completed (on m-c, etc.): landed to m-c 2013-05-15
Risk to taking this patch (and alternatives if risky): 
Changes to session history are somewhat regression risky. I don't know any alternative approaches.
String or IDL/UUID changes made by this patch: NA
Attachment #747174 - Flags: approval-mozilla-esr17?
Attachment #747174 - Flags: approval-mozilla-beta?
Attachment #747174 - Flags: approval-mozilla-b2g18?
Attachment #747174 - Flags: approval-mozilla-aurora?
Flags: needinfo?(bugs)

Updated

4 years ago
Attachment #747174 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
We'll discuss whether we want to ship this first with FF22/23.
Would also be great if you could provide instructions for general QA regression testing here given the risk profile.
Keywords: qawanted
Attachment #747847 - Attachment mime type: application/x-jar → application/java-archive
https://hg.mozilla.org/releases/mozilla-aurora/rev/72f386b8c46b
status-firefox23: affected → fixed
(Assignee)

Comment 27

4 years ago
(In reply to Alex Keybl [:akeybl] from comment #25)
> Would also be great if you could provide instructions for general QA
> regression testing here given the risk profile.

See moz_bug_r_a4's tests
Matt, can you please have a look at this RE: comment 27?
Keywords: qawanted → verifyme
QA Contact: mwobensmith
This is fairly straightforward to verify, but I can't get testcase 3 (in comment 15) to work, as Firefox won't allow me to open a file with jar: protocol. Am I missing something?

The other test (testcase 3) works fine.
^^^ Replace first line with this:

"This is fairly straightforward to verify, but I can't get testcase 4 (in comment 15) to work (...)"
You'll need to flip network.jar.open-unsafe-types to true for that particular testcase to work, I think.
Hmm, scratch that, it's marked as "application/java-archive", so it should work either way.
Thanks for the help, Gavin. Flipping the pref worked.

For the record, I confirmed the vulnerability based on the following assumptions:

- Testcase 3 is able to mimic a page in hp.com's domain, which prompts the Password Manager for that domain and displays hp.com's domain in the address bar.

- Testcase 4 is able to inject a JS alert box, which tries to display the hp.com domain's cookie.

I confirmed a successful fix for these vulns with these assumptions:

- Testcase 3 no longer prompts the Password Manager for hp.com's domain, and no longer displays their domain in the address bar, but "data:," instead.

- Testcase 4 no longer displays a JS alert box at all.

I was able to see both test cases work in pre-patch builds from multiple branches.

I was able to verify fixed on these branches:

FF23 2013-05-22
FF24 2013-05-22
status-firefox23: fixed → verified
status-firefox24: fixed → verified

Updated

4 years ago
tracking-b2g18: ? → 22+
tracking-firefox-esr17: + → 22+

Updated

4 years ago
Attachment #747174 - Flags: approval-mozilla-esr17?
Attachment #747174 - Flags: approval-mozilla-esr17+
Attachment #747174 - Flags: approval-mozilla-beta?
Attachment #747174 - Flags: approval-mozilla-beta+
Attachment #747174 - Flags: approval-mozilla-b2g18?
Attachment #747174 - Flags: approval-mozilla-b2g18+

Updated

4 years ago
status-firefox22: affected → wontfix
tracking-b2g18: 22+ → 23+
tracking-firefox22: + → -
tracking-firefox-esr17: 22+ → 23+
Comment on attachment 747174 [details] [diff] [review]
v1

Sorry, mismarked for a moment there. We decided to take in FF23 and all corresponding security branches (including B2G v1.1).
Attachment #747174 - Flags: approval-mozilla-beta+ → approval-mozilla-beta-
(the rationale was of course the risk described in comment 23, and an email discussion with the security team)
https://hg.mozilla.org/releases/mozilla-b2g18/rev/0c187b6751a2
https://hg.mozilla.org/releases/mozilla-esr17/rev/3aff426f2461
status-b2g18: affected → fixed
status-b2g18-v1.0.0: --- → wontfix
status-firefox-esr17: affected → fixed
Confirmed fixed 17esr 2013-06-18.
Status: RESOLVED → VERIFIED
status-firefox-esr17: fixed → verified
Whiteboard: [adv-main23+][adv-esr1708+]
Keywords: verifyme
Alias: CVE-2013-1709
Group: core-security
You need to log in before you can comment on or make changes to this bug.