Closed
Bug 701071
(CVE-2012-0445)
Opened 13 years ago
Closed 13 years ago
<iframe> element is exposed across domains by its name attribute
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
firefox10 | --- | verified |
firefox11 | --- | verified |
firefox-esr10 | 10+ | fixed |
status1.9.2 | --- | unaffected |
People
(Reporter: bsterne, Assigned: smaug)
Details
(Keywords: regression, reporter-external, Whiteboard: [sg:high][qa?])
Attachments
(5 files, 1 obsolete file)
571 bytes,
application/octet-stream
|
Details | |
749 bytes,
application/octet-stream
|
Details | |
9.80 KB,
patch
|
jst
:
review+
|
Details | Diff | Splinter Review |
6.03 KB,
patch
|
Details | Diff | Splinter Review | |
3.77 KB,
patch
|
jst
:
approval-mozilla-aurora+
jst
:
approval-mozilla-beta-
|
Details | Diff | Splinter Review |
Alex Dvorov reported this to security@m.o: A form can be submitted to a named iframe in another domain if you know the name attribute of the iframe element. This is a regression, as Firefox 3.6 creates a new top-level window to which the form is submitted if the named iframe doesn't exist within the current window. This is the same behavior as the current version of Chrome. I'm setting this as moderate severity, because most high bugs involve stealing information or running script in the context of another site, but this is still bad. You could easily use this to spoof the content in another site if you know the name of an iframe there. I could be persuaded that this is in fact a high bug.
Comment 1•13 years ago
|
||
Bah, I thought we had mochitests for this when we fixed it last time :-(. bz, do you want this one?
Component: DOM: Core & HTML → Document Navigation
QA Contact: general → docshell
Whiteboard: [sg:moderate] → [sg:high]
Assignee | ||
Updated•13 years ago
|
Keywords: regressionwindow-wanted
![]() |
||
Comment 2•13 years ago
|
||
> I thought we had mochitests for this when we fixed it last time
Hmm. I believe at the time there was no way to sanely write tests for it, but I'll check.
In any case, what's happening is that the GetSubjectPrincipal call in nsDocShell::ValidateOrigin is finding the system principal, not null as it should for the form submit case. And it treats the two differently.
And the reason GetSubjectPrincipal does that is that nsScriptSecurityManager::GetPrincipalAndFrame extracts an nsJSContext from the |cx| which has an nsGlobalChromeWindow as its GetObjectPrincipal.
The callstack at this point has no JS running on it, but does have the click event dispatch that triggers the form submission...
Is a non-null subject principal actually expected in this situation? If so, why?
Assignee | ||
Comment 3•13 years ago
|
||
where is the testcase? Why do we get non-null principal if JS is not running o_O. XPConnect should push null cx.
![]() |
||
Comment 4•13 years ago
|
||
> where is the testcase? The testcase I used looks like this: On server ZZZZ I put this file, named iframe.html: <iframe name="x"></iframe> On server B (file:// in my case), I put this file: <form action="http://www.mozilla.org" target="x"> <input type="submit"> </form> <iframe src="http://ZZZZ/iframe.html"></iframe> Then clicked the submit button. > Why do we get non-null principal if JS is not running I _think_ that dispatch of the click event pushes the cx of the chrome window or something. I didn't get a chance to debug more in detail yet.
Assignee | ||
Comment 5•13 years ago
|
||
But click is happening in content, right? It should push the cx of content window.
Assignee | ||
Comment 6•13 years ago
|
||
..for event listeners. But for default handling there shouldn't be a context pushed, or, again, the context of the page.
Comment 7•13 years ago
|
||
Here is testcase: http://www.youtube.com/watch?v=HladcNKvlhQ
![]() |
||
Comment 8•13 years ago
|
||
That's not a testcase; that's a video. A testcase would be a web page showing the problem. Olli, per our IRC conversation, over to you. Looks like the issue is that we RePush when calling nsEventListenerManager::HandleEventInternal on the tabbrowser and pop too late.
![]() |
||
Updated•13 years ago
|
Assignee: nobody → bugs
Assignee | ||
Comment 9•13 years ago
|
||
Boris, feel free to test this. (I'll test the patch once this meeting is over)
Assignee | ||
Comment 10•13 years ago
|
||
Hmm, no the patch doesn't affect to the behavior. And Chrome gives the same behavior.
Assignee | ||
Comment 11•13 years ago
|
||
So the patch does change principal handling. nsDocShell::ValidateOrigin gets null principal and not system principal. But the behavior is still the same.
Assignee | ||
Comment 12•13 years ago
|
||
So in my test case we're passing the same treeitem as origin and target :/
Assignee | ||
Comment 13•13 years ago
|
||
alexdvorov from comment #7) > Here is testcase: http://www.youtube.com/watch?v=HladcNKvlhQ Would be great if you could upload your test using "Add an attachment", since apparently I have a different kind of testcase (the one from Boris) which is actually broken also in FF3.6.
Assignee | ||
Comment 14•13 years ago
|
||
I clearly have wrong test case (though, it is still showing a problem in browsers) since it works the same way in Gecko, Webkit and IE.
Assignee | ||
Comment 15•13 years ago
|
||
Ok, I shouldn't put <iframe src="http://ZZZZ/iframe.html"></iframe>, but open iframe.html in a separate tab.
Assignee | ||
Updated•13 years ago
|
Attachment #573541 -
Flags: review?(jst)
Assignee | ||
Comment 16•13 years ago
|
||
Comment on attachment 573541 [details] [diff] [review] patch Make sure we pop cx from stack when doing default handling. This is a regression from year 2009. I need to still write the mochitest for this.
Attachment #573541 -
Flags: review?(jst)
Comment 17•13 years ago
|
||
I from Russia, I can do mistakes in my messages, and incorrectly understand words. I uploaded tests. It's not nesessary to run pages from different domains.
Comment 18•13 years ago
|
||
Assignee | ||
Comment 19•13 years ago
|
||
Thanks for the tests, but any chance you could use zip or gz or bz2 for compression?
Comment 20•13 years ago
|
||
Comment 21•13 years ago
|
||
Added zip comressed testcase. Just open in two tabs index.html and index2.html. And why platform is Linux only? Under Windows it works too.
Assignee | ||
Updated•13 years ago
|
OS: Linux → All
Assignee | ||
Comment 22•13 years ago
|
||
(In reply to alexdvorov from comment #17) > It's not nesessary to run pages from different domains. Well, that is then a different case. The regression I see need cross-domain.
Assignee | ||
Comment 23•13 years ago
|
||
Had to add a way to push null context.
Attachment #573541 -
Attachment is obsolete: true
Attachment #573541 -
Flags: review?(jst)
Attachment #573834 -
Flags: review?(jst)
Comment 24•13 years ago
|
||
In v8.1 this will be fixed?
Assignee | ||
Comment 25•13 years ago
|
||
There won't be 8.1, and I doubt this can make to 8.0.*, since this isn't *critical* security bug. But I hope FF9, at latest. That will be released before Christmas. Anyhow, the patch needs to be reviewed before it can land to any branch.
Comment 26•13 years ago
|
||
Okay. There are people who speak in Russian? Because it's very hard to write in English. Знает кто нибудь тут русский?
![]() |
||
Comment 27•13 years ago
|
||
Я знаю русский.
Comment 28•13 years ago
|
||
О, это хорошо. А то я думал, что тут только по английски можно писать. То есть патч уже есть, осталось его только добавить в следующий FF 8.0.*?
![]() |
||
Comment 29•13 years ago
|
||
Обычно, здесь лучше писать по английски, чтобы все понимали... Патч естъ. Его нужно проверить, потом добавитъ в FF 11, потом скорее всего в 10 и 9. В 8.0.* этот патч скорее всего не попадет потому, что это не критический баг (пример критического бага -- возможность запускать на компьютере пользователя произвольный код). ------- For the rest, what happened above is Alex said that he's glad someone understands Russian; he'd thought that he would have to stick to English here. He then asked whether he understands correctly that there is a patch and all that's left is to add it to the next FF 8.0.*. What I said is basically a repeat of comment 25, but in Russian, along with an example of what we consider a critical security bug (remote code execution).
Comment 30•13 years ago
|
||
I listen about Bug Bountry, can I get anything? :)
Comment 31•13 years ago
|
||
New sg:high and sg:critical bugs are generally considered eligible for the bounty, but a formal decision will be made when the bounties evaluated (usually every 60 days or so).
Comment 32•13 years ago
|
||
I just need to wait 60 days, or must do something else?
Reporter | ||
Comment 33•13 years ago
|
||
(In reply to alexdvorov from comment #32) Just wait, and someone will be in contact with you eventually.
Comment 34•13 years ago
|
||
Okay. I'll wait.
Comment 35•13 years ago
|
||
Olli, can you explain the rationale here and what exactly is going wrong here?
Assignee | ||
Comment 36•13 years ago
|
||
We end up having wrong cx (chrome) on js stack when doing PostHandleEvent (which ends up submitting the form). This is a regression from the work where the number of push/pop calls were tried to be reduced.
Assignee | ||
Comment 37•13 years ago
|
||
review ping
Comment 38•13 years ago
|
||
Also we can use top.location.href to do physhing :) It's true sg:high bug.
Comment 39•13 years ago
|
||
Sorry - fishing. We can change all page containing iframe element, if page that was be in iframe, contains <script>top.location.href = "http://google.com/";</script>
Comment 41•13 years ago
|
||
The frame targeting issue has been considered sg:moderate in the past (e.g. http://www.mozilla.org/security/announce/2005/mfsa2005-51.html ) but it's possible we've learned better how to exploit it. But having the wrong cx on the stack (comment 36) sounds like it might lead to much worse (or not?). CC'ing moz_bug_r_a4 in case this inspires him.
Comment 42•13 years ago
|
||
So, I can't give bouty or t-shirt?
Updated•13 years ago
|
Attachment #573834 -
Flags: review?(jst) → review+
Assignee | ||
Comment 43•13 years ago
|
||
I'll land the patch first.
Assignee | ||
Updated•13 years ago
|
Attachment #579768 -
Attachment description: tests onlye → tests only
Assignee | ||
Comment 44•13 years ago
|
||
Attachment #579771 -
Flags: approval-mozilla-beta?
Attachment #579771 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 45•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/dfff3e59ef23
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 46•13 years ago
|
||
Comment on attachment 579771 [details] [diff] [review] patch only Per todays dirver meeting this is too late for beta, but approving for aurora.
Attachment #579771 -
Flags: approval-mozilla-beta?
Attachment #579771 -
Flags: approval-mozilla-beta-
Attachment #579771 -
Flags: approval-mozilla-aurora?
Attachment #579771 -
Flags: approval-mozilla-aurora+
Assignee | ||
Comment 47•13 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/9871079caf78
status-firefox10:
--- → fixed
status-firefox11:
--- → fixed
Comment 48•13 years ago
|
||
Don't forget to check the tests in.
status1.9.2:
--- → unaffected
Flags: in-testsuite?
Updated•13 years ago
|
Alias: CVE-2012-0445
Comment 49•13 years ago
|
||
Fails on Firefox 10.0.2. Should this be addressed in a ESR release?
Comment 50•13 years ago
|
||
Also fails on Firefox 11 Beta 6. Reopening this bug.
Updated•13 years ago
|
Whiteboard: [sg:high][qa+] → [sg:high]
Comment 51•13 years ago
|
||
Also broken in Aurora and Nightly.
![]() |
||
Comment 52•13 years ago
|
||
Jason, how did you test?
Comment 53•13 years ago
|
||
Steps: 1. Download the https://bugzilla.mozilla.org/attachment.cgi?id=573782 2. Opened index.html in tab #1 3. Opened index2.html in tab #2 4. Select the POST button in index2.html Expected: The text in index.html should not change. Actual: The text in index.html did change.
![]() |
||
Comment 54•13 years ago
|
||
> 2. Opened index.html in tab #1 > 3. Opened index2.html in tab #2 On different servers? The bug report is about the case when index.html is on one server and index2.html is on another one. See comment 4.
Comment 55•13 years ago
|
||
My test cases were both executed on the same server. I can retest that with separate servers. However, I want to know if that test case I used is allowed where index.html and index2.html are hosted on the same server. If it isn't, then there's still a problem.
![]() |
||
Comment 56•13 years ago
|
||
If they're on the same server, they should be able to link to each other at the moment. Resetting the fixed state, since as far as I can tell the bug is in fact fixed.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Updated•13 years ago
|
Whiteboard: [sg:high] → [sg:high][qa+]
Updated•13 years ago
|
Updated•13 years ago
|
Comment 57•13 years ago
|
||
Verified fixed on FF 10, FF 11 Beta 6, FF 12 Aurora, FF 13 Nightly.
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Whiteboard: [sg:high][qa+] → [sg:high]
Updated•13 years ago
|
status-firefox-esr10:
--- → fixed
tracking-firefox-esr10:
--- → 10+
Updated•13 years ago
|
Group: core-security
Comment 58•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #57) > Verified fixed on FF 10, FF 11 Beta 6, FF 12 Aurora, FF 13 Nightly. Jason, are you still set up to test this? If so, can you test the latest ESR nightly?
Updated•9 years ago
|
Keywords: regressionwindow-wanted
Updated•3 months ago
|
Keywords: reporter-external
You need to log in
before you can comment on or make changes to this bug.
Description
•