Closed
Bug 626775
(CVE-2013-0794)
Opened 14 years ago
Closed 12 years ago
Tab modal dialog spoofing (DOMWillOpenModalDialog + navigation)
Categories
(Toolkit :: General, defect)
Toolkit
General
Tracking
()
People
(Reporter: sync2d, Assigned: fryn)
References
Details
(Keywords: csectype-spoof, sec-moderate, Whiteboard: [sg:moderate][fixed-in-bug-611553][adv-main20+])
Attachments
(2 files)
bug 625187 without iframes.
Comment 1•14 years ago
|
||
Even in 3.6.x the timing here is pretty spooftastic -- the dialog title says the name of the other site but it overlays the Google content that's built behind it.
We could do all kinds of things differently (if not easily)
- don't layout a new page while a modal dialog is open
- auto-cancel the modal dialog on navigation
- leave the dialog open, but break the connection to the
calling page and just give them a "cancel" response.
Assignee: nobody → dolske
Comment 2•14 years ago
|
||
A check for something like |callingWindow.top == windowForPrompt.top| would probably be good to have (and just throw if that's the case, because we never want that to happen anyway).
Updated•14 years ago
|
Summary: tab modal dialog spoofing without iframes → Tab modal dialog spoofing (DOMWillOpenModalDialog + navigation)
Whiteboard: [sg:moderate]
Updated•13 years ago
|
Assignee: dolske → fryn
Comment 3•13 years ago
|
||
Hmm, I wonder if this and bug 383382 are the same thing.
![]() |
Assignee | |
Comment 4•13 years ago
|
||
While investigating this bug, I discovered that the prompter code can be completely broken with the following.
addEventListener('DOMWillOpenModalDialog', function() confirm(0));
alert(0);
Once this runs, if a user tries to navigate the tab to another address, it won't be displayed to the user and only the blank confirm dialog will be visible.
The check that Dolske suggests might be sufficient for the security part, but would completely disallowing prompts inside DOMWillOpenModalDialog handlers make sense?
Comment 5•13 years ago
|
||
DOMWillOpenModalDialog shouldn't be visible to content scripts at all - we just need to fix that, AFAICT.
![]() |
Assignee | |
Comment 6•13 years ago
|
||
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #5)
> DOMWillOpenModalDialog shouldn't be visible to content scripts at all - we
> just need to fix that, AFAICT.
Okay, fixing bug 611553 should do it then.
I just attached a patch to that bug.
Status: NEW → ASSIGNED
![]() |
||
Updated•13 years ago
|
Keywords: sec-moderate
![]() |
Assignee | |
Comment 7•12 years ago
|
||
I just fixed this by making DOMWillOpenModalDialog chrome-only in bug 611553.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
OS: Windows Vista → All
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [sg:moderate] → [sg:moderate][fixed-in-bug-611553]
Target Milestone: --- → mozilla21
Comment 8•12 years ago
|
||
We should land this on the branches... does b2g use this code? we maybe want to fix it there as well.
status-firefox-esr10:
--- → wontfix
status-firefox19:
--- → affected
status-firefox20:
--- → affected
status-firefox21:
--- → affected
status-firefox-esr17:
--- → affected
tracking-b2g18:
--- → ?
tracking-firefox19:
--- → +
tracking-firefox20:
--- → +
tracking-firefox21:
--- → +
tracking-firefox-esr17:
--- → 19+
Depends on: 611553
Comment 9•12 years ago
|
||
the fix in bug 611553 builds on bug 830858, and that changes the nsIDOMWindowUtils API -- pretty internal-ish but still might be used by add-ons so I'm not sure we could actually take this on stable branches. At least not without creating nsIDOMWindowUtils2 or something.
Depends on: 830858
![]() |
Assignee | |
Comment 11•12 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #10)
> This affects the b2g browser as well.
If they forked Firefox desktop or Fennec (XUL and Java), then they may need to patch their code, since the DOMWillOpenModalDialog event is also dispatched from the front end for those code bases.
I can take a look.
Where does their front-end b2g browser code live?
![]() |
Assignee | |
Comment 12•12 years ago
|
||
A quick Github search turned up nothing:
https://github.com/search?q=repo%3Amozilla-b2g%2Fgaia+DOMWIllOpenModalDialog&p=1&ref=searchbar&type=Code&l=
Comment 13•12 years ago
|
||
Frank - can you prepare patches for Aurora 20? Given the fact that bug 830858 changes interfaces and this is sec-moderate, we've decided to wontfix for FF19, B2G18 and ESR17.
![]() |
Assignee | |
Comment 14•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #13)
> Frank - can you prepare patches for Aurora 20? Given the fact that bug
> 830858 changes interfaces and this is sec-moderate, we've decided to wontfix
> for FF19, B2G18 and ESR17.
Sure. Given that the patches that fixed this bug are in two public bugs, should I simply use the same commit messages? If so, should I simply flag the patches in those bugs for aurora 20 approval? If not, do you want me to upload a copy of those patches combined into one to this bug with a different commit message?
Comment 15•12 years ago
|
||
Yeah let's nominate the two separate bugs, and just put in a private comment reminding us of the security implications. Thanks!
![]() |
Assignee | |
Comment 16•12 years ago
|
||
Fixed for Firefox 20 by pushing bug 830858 and bug 611553 fixes to aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/df5345414bb1
https://hg.mozilla.org/releases/mozilla-aurora/rev/46d904f2f252
https://hg.mozilla.org/releases/mozilla-aurora/rev/c7115618ac6e
Updated•12 years ago
|
Keywords: csec-spoof
Updated•12 years ago
|
Whiteboard: [sg:moderate][fixed-in-bug-611553] → [sg:moderate][fixed-in-bug-611553][adv-main20+]
Updated•12 years ago
|
Alias: CVE-2013-0794
Updated•12 years ago
|
Summary: Tab modal dialog spoofing (DOMWillOpenModalDialog + navigation) → Tab modal dialog spoofing
Updated•12 years ago
|
Summary: Tab modal dialog spoofing → Tab modal dialog spoofing (DOMWillOpenModalDialog + navigation)
Updated•10 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•