Bug 959531 (CVE-2014-1489)

settings & history ID bug

VERIFIED FIXED in Firefox 27

Status

()

VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: zaanx91, Assigned: billm)

Tracking

({csectype-dos, regression, sec-low})

26 Branch
Firefox 29
x86_64
Windows 7
csectype-dos, regression, sec-low
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox26 wontfix, firefox27 fixed, firefox28+ verified, firefox29+ verified, firefox-esr24 unaffected, b2g18 unaffected, b2g-v1.1hd unaffected, b2g-v1.2 unaffected, b2g-v1.3 unaffected, b2g-v1.4 unaffected)

Details

(Whiteboard: [adv-main27+])

Attachments

(4 attachments)

(Reporter)

Description

5 years ago
Created attachment 8359715 [details]
bug.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

Create an html page with the following markup:

<button name="settings" id="settings">settings</button>
<button name="history" id="history">history</button>


Actual results:

when i click on the settings button, it opens the settings of the firefox, 
same results for the histroy button, it opens the firefox histroy window.


Expected results:

It should invoke my code whether its JavaScript or any other action.

Comment 1

5 years ago
Created attachment 8359773 [details]
testcase 959531.html

I can't reproduce with Firefox 26 or 29 (Nightly) on Linux.

Comment 2

5 years ago
But I could on Windows 7 with Firefox 26 and 29 but not Firefox 25.
(Reporter)

Comment 3

5 years ago
yes it's on windows 7 and not every time, sometimes it happens and sometimes it doesn't.
(Reporter)

Comment 4

5 years ago
i figured it out, the innerHTML of the button is case sensitive ("Settings", "History"), it happens in this case only, in addition to the element ID

<button type="button" class="abutton" id="settings">Settings</button>
<button id="history" class="abutton" type="button">History</button>

Comment 5

5 years ago
Reproducing this requires that the tab in question have loaded about:home first.

This is a regression from bug 899222, where about:home adds event listeners to operate the settings/bookmarks buttons. It appears that these listeners are being set on the window and not the document, so they are not unset on page navigation.

This is unlikely to be an actual security issue, but since I'm not certain I'll leave it for billm to decide whether to leave this bug private.
Component: Untriaged → General

Updated

5 years ago
Blocks: 899222
Keywords: regression
(Reporter)

Comment 6

5 years ago
ok thanks alot .
I think that "Restore Previous Session" is the worst that could happen here. Your current session would be lost, which is pretty bad.
Assignee: nobody → wmccloskey
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Reporter)

Comment 8

5 years ago
oh ok, thanks Bill !
Keywords: csectype-dos, sec-low
Created attachment 8360727 [details] [diff] [review]
about-home-fix

Ugh, a frustrating bug. I used |this| inside an event handler. In the fix, I wanted to use an arrow function, but the function also needs to refer to itself, which arrow functions can't do.
Attachment #8360727 - Flags: review?(felipc)
Created attachment 8360728 [details] [diff] [review]
about-home-test

Fails without the patch, passes with it.
Attachment #8360728 - Flags: review?(felipc)
Attachment #8360727 - Flags: review?(felipc) → review+
Attachment #8360728 - Flags: review?(felipc) → review+
The patch fixes it, but should we make it more robust by double checking onClick that our doc is about:home?
OK, I can do that.
Somehow this didn't get resolved.
https://hg.mozilla.org/mozilla-central/rev/76cf1178c524
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment on attachment 8360727 [details] [diff] [review]
about-home-fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 899222
User impact if declined: A malicious site could make a button that causes the user's session to be lost (and the previous one restored).
Testing completed (on m-c, etc.): On m-c.
Risk to taking this patch (and alternatives if risky): Pretty low. It's a very straightforward change.
String or IDL/UUID changes made by this patch: None
Attachment #8360727 - Flags: approval-mozilla-beta?
Attachment #8360727 - Flags: approval-mozilla-aurora?
status-b2g18: --- → unaffected
status-b2g-v1.2: --- → unaffected
status-b2g-v1.3: --- → unaffected
status-firefox26: --- → wontfix
status-firefox27: --- → affected
status-firefox28: --- → affected
status-firefox29: --- → fixed
status-firefox-esr24: --- → unaffected
tracking-firefox28: --- → +
tracking-firefox29: --- → +

Updated

5 years ago
Attachment #8360727 - Flags: approval-mozilla-beta?
Attachment #8360727 - Flags: approval-mozilla-beta+
Attachment #8360727 - Flags: approval-mozilla-aurora?
Attachment #8360727 - Flags: approval-mozilla-aurora+

Updated

5 years ago
Keywords: verifyme
Do you mind taking care of this Ryan? Thanks.
https://hg.mozilla.org/releases/mozilla-aurora/rev/e05b56b61342
https://hg.mozilla.org/releases/mozilla-beta/rev/1b3060857876
status-b2g-v1.1hd: --- → unaffected
status-b2g-v1.4: --- → unaffected
status-firefox27: affected → fixed
status-firefox28: affected → fixed
Flags: in-testsuite?
Whiteboard: [adv-main27+]
Alias: CVE-2014-1489

Updated

5 years ago
Depends on: 968597
For whatever reason, I wasn't able to reproduce on a Win7 system with Fx26, even when about:home was open previously. However, I am able to see it consistently on the Mac.

Verified Fx28 release build.
Verified Fx29, build from 2014-02-10.
Status: RESOLVED → VERIFIED
status-firefox28: fixed → verified
status-firefox29: fixed → verified
Keywords: verifyme
Group: core-security
Setting in-testsuite+ as this bug has a browser chrome test.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.