Closed Bug 1273129 (CVE-2016-2822) Opened 8 years ago Closed 8 years ago

Firefox Navigation from a page with an active <select> dropdown menu can be used for URL/SSL spoofing and ClickJacking

Categories

(Core :: General, defect)

41 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla49
Tracking Status
firefox47 --- verified
firefox48 --- verified
firefox49 --- verified
firefox-esr45 47+ verified

People

(Reporter: jordi.chancel, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: csectype-spoof, regression, sec-moderate, Whiteboard: [adv-main47+][adv-esr45.2+])

Attachments

(4 files, 2 obsolete files)

Attached file TESTCASE V1 and TESTCASE V2.zip (obsolete) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

This new vulnerability is very similar to a vulnérability previously reported by me: MFSA-2013-94 ( https://bugzilla.mozilla.org/show_bug.cgi?id=868327 ).

I discovered again a malicious method to put arbitrary HTML content within <select> elements and place it in arbitrary locations. 

This can be used to spoof the displayed addressbar (Location Bar URL & SSL Spooofing), leading also to multiple clickjacking attacks (eg: WebCam ClickJacking using the WebRTC dialog) and other spoofing attacks.

I have two Proof of Concept, the first use a <select> dropdown menu no persistent, and the 2nd Proof of Concept use a <select> dropdown menu persistent.

(Two demonstration videos will be uploaded to show you the severity and the impact of these PoCs and of this vulnerability).



Actual results:

This can be used to spoof the displayed addressbar (or others spoofing attacks) and leading also to multiple clickjacking attacks.



Expected results:

In a normal case, a <select> element shouldn't cover the location bar and this <select> menu shouldn't persist during browsing.
The previous testcases uploaded had an error. This is an update of these testcases.

(Tested only on Mac OS X YOSEMITE and Mac OS X El Capitan).
Attachment #8752819 - Attachment is obsolete: true
Summary: Firefox Navigation from a page with an active <select> dropdown menu can be used for URL/SSL spoofing and ClickJacking Attacks (the <select> dropdown menu can be persistent) → Firefox Navigation from a page with an active <select> dropdown menu can be used for URL/SSL spoofing
Summary: Firefox Navigation from a page with an active <select> dropdown menu can be used for URL/SSL spoofing → Firefox Navigation from a page with an active <select> dropdown menu can be used for URL/SSL spoofing and ClickJacking
I updated again the testcases by adding some CSS atributes : 
"overflow-x:hidden;" and "overflow-y:hidden;" for a more convincing result.
Attachment #8752879 - Attachment is obsolete: true
Flags: sec-bounty?
Mats, you worked on bug 868327, can you take a look at this?
Flags: needinfo?(mats)
Hi Jordi, can you please test this build and see if it fixes the problem?  Thanks!
http://archive.mozilla.org/pub/firefox/try-builds/mpalmgren@mozilla.com-7ebe5ea6222943ee7df0857c56b177208c44b06d/try-macosx64/
Flags: needinfo?(mats) → needinfo?(jordi.chancel)
These testcases works on Firefox 46.0.X but don't work on Nightly 47.0b7.

I will try to code a valid testcase for Nightly.
Flags: needinfo?(jordi.chancel)
Sorry, I didn't realize the test was specific to the v46 branch.
I've scheduled a new build for v46 (estimated time to complete: 61 minutes):
https://archive.mozilla.org/pub/firefox/try-builds/mpalmgren@mozilla.com-840d48bf1cf6f898c8f4147107dcf0dd6c7a9512/
Please test that instead when it's ready.
Flags: needinfo?(jordi.chancel)
This vulnerability is perfectly fixed on 46.0.2.

All actual testcases works perfectly on Firefox 46.0.1 (actual release) but don't work on Firefox 46.0.2 (next release). 

(RESOLVED/FIXED on 46.0.2).
Flags: needinfo?(jordi.chancel)
OK, great.  Thanks for testing.
Attached patch fixSplinter Review
This is a regression in v41 from this change in bug 1113206:
https://hg.mozilla.org/mozilla-central/diff/c838abaf38a4/layout/forms/nsComboboxControlFrame.cpp#l1.171

Both .YMost and .y got translated to .BEnd, oops...
Assignee: nobody → mats
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8753874 - Flags: review?(jfkthame)
Blocks: 1113206
Keywords: regression
The code that regressed is the same as in bug 868327, so using the same classification here.
OS: Unspecified → All
Hardware: Unspecified → All
Comment on attachment 8753874 [details] [diff] [review]
fix

Review of attachment 8753874 [details] [diff] [review]:
-----------------------------------------------------------------

Oops indeed! :(
Attachment #8753874 - Flags: review?(jfkthame) → review+
https://hg.mozilla.org/mozilla-central/rev/47ced506c7a3
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Comment on attachment 8753874 [details] [diff] [review]
fix

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: sec-moderate, but seems unlikely to be exploited
Fix Landed on Version: 49
Risk to taking this patch (and alternatives if risky): zero risk, it's just fixing a trivial typo that returns us to previous tested behaviour
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Approval Request Comment
[Feature/regressing bug #]: bug 1113206 
[User impact if declined]: sec-moderate, but seems unlikely to be exploited
[Describe test coverage new/current, TreeHerder]: no test coverage
[Risks and why]: zero risk, it's just fixing a trivial typo that returns us to previous tested behaviour
[String/UUID change made/needed]: none

Although it's just sec-moderate, I think it's worth uplifting since it's
a zero risk typo fix.
Attachment #8753874 - Flags: approval-mozilla-esr45?
Attachment #8753874 - Flags: approval-mozilla-beta?
Attachment #8753874 - Flags: approval-mozilla-b2g48?
Attachment #8753874 - Flags: approval-mozilla-aurora?
Comment on attachment 8753874 [details] [diff] [review]
fix

Fixes a typo and a sec-mod issue, Aurora48+, Beta47+, ESR45+
Attachment #8753874 - Flags: approval-mozilla-esr45?
Attachment #8753874 - Flags: approval-mozilla-esr45+
Attachment #8753874 - Flags: approval-mozilla-beta?
Attachment #8753874 - Flags: approval-mozilla-beta+
Attachment #8753874 - Flags: approval-mozilla-aurora?
Attachment #8753874 - Flags: approval-mozilla-aurora+
Group: core-security → core-security-release
Flags: sec-bounty? → sec-bounty+
Flags: qe-verify+
Whiteboard: [adv-main47+][adv-esr45.2+]
I get different results in 49.0a1 (2016-05-30) compared to 47b9. So, I'm not sure if this is not fixed in beta, or the testcases just don't work on nightly.
http://i.imgur.com/69vXNUC.png
Flags: needinfo?(mats)
For testing, note that dropdowns behave quite differently on e10s vs non-e10s. I think the testcases for this issue may have been specific to non-e10s(?).
Thanks, Jonathan.
I got the same behavior on Nightly with e10s OFF.
Anyway, I still reproduced the persistent menu behavior using the second testcase, when opening a new browser window. Is that expected?
Flags: needinfo?(mats)
Flags: needinfo?(mats)
Depends on: CVE-2016-9076
The persistent menu problem sounds like a separate bug, can you file a new bug about it?
I think it can be public - I don't see a security issue with it.

Let's keep this bug about URL bar spoofing on non-e10s only.
I retested Nightly with e10s and it seems we have the same URL bar spoofing issue
there.  (Perhaps we've never had any protection on e10s?)

For tracking purposes I filed a separate bug 1276976 to fix this on e10s.
Flags: needinfo?(mats)
> I think it can be public - I don't see a security issue with it.

Although we need to keep any testcases that reveal *this* bug non-public of course.
So we probably need a new testcase for that bug where we make sure the dropdown menu
opens *downwards*.  Then I think it's OK to make it public.
Alias: CVE-2016-2822
(In reply to Mats Palmgren (:mats) from comment #25)
> > I think it can be public - I don't see a security issue with it.
> 
> Although we need to keep any testcases that reveal *this* bug non-public of
> course.
> So we probably need a new testcase for that bug where we make sure the
> dropdown menu
> opens *downwards*.  Then I think it's OK to make it public.
done - bug 1277271
The persistent menu problem is used in others reported vulnerabilities which affects Firefox ( like Bug952951 or Bug941482 [...] ) and had already been used in previous fixed vulnerability like MFSA-2012-75 ( https://www.mozilla.org/en-US/security/advisories/mfsa2012-75/ ) , please don't allow Bug1277271 to be public.
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(mats)
I've hidden it for now.
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(mats)
I'm marking this bug as verified fixed on FX 47, 48.0a2 (2016-06-01), 49.0a1 (2016-06-01), 45.1.1esrpre (2016-05-29) considering the follow-up bug 1276976 and bug 1277271.
Group: core-security-release
Comment on attachment 8753874 [details] [diff] [review]
fix

(I guess this request isn't relevant anymore)
Attachment #8753874 - Flags: approval-mozilla-b2g48?
Version: 46 Branch → 41 Branch
You need to log in before you can comment on or make changes to this bug.