1273129 - (CVE-2016-2822) Firefox Navigation from a page with an active <select> dropdown menu can be used for URL/SSL spoofing and ClickJacking

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[Jordi Chancel]

Attachment: TESTCASE V1 and TESTCASE V2.zip

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.

Comment 1

[Jordi Chancel]

Attachment: TestCase V1 and TestCase V2 (UPDATED).zip

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).

Comment 2

[Jordi Chancel]

Attachment: Video Example PoC v1.html

Comment 3

[Jordi Chancel]

Attachment: Video Example PoC v2.html

Comment 4

[Jordi Chancel]

Attachment: TestCase v1 and TestCase v2 (2nd UPDATE).zip

I updated again the testcases by adding some CSS atributes : 
"overflow-x:hidden;" and "overflow-y:hidden;" for a more convincing result.

Comment 5

[Al Billings [:abillings - ex-MoCo]]

Mats, you worked on bug 868327, can you take a look at this?

Comment 6

[Mats Palmgren (inactive)]

Hi Jordi, can you please test this build and see if it fixes the problem?  Thanks!
http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-7ebe5ea6222943ee7df0857c56b177208c44b06d/try-macosx64/

Comment 7

[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.

Comment 8

[Mats Palmgren (inactive)]

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/[e-mail]-840d48bf1cf6f898c8f4147107dcf0dd6c7a9512/
Please test that instead when it's ready.

Comment 9

[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).

Comment 10

[Mats Palmgren (inactive)]

OK, great.  Thanks for testing.

Comment 11

[Mats Palmgren (inactive)]

Attachment: fix

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...

Comment 12

[Mats Palmgren (inactive)]

The code that regressed is the same as in bug 868327, so using the same classification here.

Comment 13

[Jonathan Kew [:jfkthame]]

Comment on attachment 8753874 [details] [diff] [review]
fix

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

Oops indeed! :(

Comment 14

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/47ced506c7a32e8ca807978071a536f64c8332c8

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/47ced506c7a3

Comment 16

[Mats Palmgren (inactive)]

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.

Comment 17

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8753874 [details] [diff] [review]
fix

Fixes a typo and a sec-mod issue, Aurora48+, Beta47+, ESR45+

Comment 18

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/782b4767770b
https://hg.mozilla.org/releases/mozilla-beta/rev/bcc547cc6eec
https://hg.mozilla.org/releases/mozilla-esr45/rev/064d2636b91b

Comment 19

[Jordi Chancel]

I have a problem to contact Chris Hofmann on this email address about the bounty, someone know what is the problem?

Comment 20

[Al Billings [:abillings - ex-MoCo]]

You've already sent four or five emails to us, Jordi. Please don't send us email *and* needinfo? us in bugs. As always, questions on bounty need to be emailed to [e-mail] (which you did three times now for this), not asked in bugzilla.

Chris no longer works at Mozilla.

Comment 21

[Paul Silaghi, QA [:pauly]]

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

Comment 22

[Jonathan Kew [:jfkthame]]

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(?).

Comment 23

[Paul Silaghi, QA [:pauly]]

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?

Comment 24

[Mats Palmgren (inactive)]

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.

Comment 25

[Mats Palmgren (inactive)]

> 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.

Comment 26

[Paul Silaghi, QA [:pauly]]

(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

Comment 27

[Jordi Chancel]

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.

Comment 28

[Mats Palmgren (inactive)]

I've hidden it for now.

Comment 29

[Paul Silaghi, QA [:pauly]]

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.

Comment 30

[Mats Palmgren (inactive)]

Comment on attachment 8753874 [details] [diff] [review]
fix

(I guess this request isn't relevant anymore)