Closed Bug 1125013 (CVE-2015-0810) Opened 5 years ago Closed 4 years ago

Mozilla Firefox for Mac OS X : Cursor can be totally invisible using flash object and div

Categories

(Core :: General, defect)

35 Branch
x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
firefox35 --- wontfix
firefox36 - wontfix
firefox37 + fixed
firefox38 + fixed
firefox-esr31 --- wontfix

People

(Reporter: jordi.chancel, Unassigned)

References

Details

(Keywords: sec-moderate, testcase, Whiteboard: [adv-main37+] RESOLVED FIXED by bug 1121811 on trunk)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

When you go on a flash object (with the cursor) that defined the cursor like invisible and a <div> transparent object (transparent obligatory) covers this flash object, 
the cursor is now totally invisible. 
This flaw can be in used in combination with an image of the cursor manipulated through JavaScript, leading to clickjacking during interactions with HTML content subsequently.

I have coded a PoC with the same interaction/severity as the PoC for bug995603 (the difference between this two bugs is :
in bug995603 (RESOLVED/FIXED) , the cursor is on the flash object and a some <div> will cover a part of this flash object , and the bug appear when you move the cursor to the <div>.
in this new bug (WORKS ON STABLE/BETA AND OTHERS VERSION OF FIREFOX) , the <div> will directly cover the totality of the flash object .


steps:
1 : Go to the flash object with the cursor (don't click on the flash object)
2 : Wait 2 s 
3 : The cursor is totally invisible on all element/ button (on webpage or firefox elements) / addon window or what you want

i will upload a video that demonstrates this vulnerability


Actual results:

This flaw can be in used in combination with an image of the cursor manipulated through JavaScript, leading to clickjacking during interactions with HTML content subsequently.


Expected results:

The cursor is totally invisible on all element/ button (on webpage or firefox elements) / addon window or what you want
Attached file Video-Example1.html
look this video please.
spohl, this looks very similar to bug 1117591, can you look at them together?
Assignee: nobody → spohl.mozilla.bugs
I'm definitely able to reproduce this. Looking into it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here is the detailed history of our behavior with this test case (e10s threw me a bit of a curve ball). I'll follow up with comments specifically about our situation today.

1. Revision 6338a8988917 (2012-06-06): Up until this nightly, this bug was reproducible.

2. Revision 7e4c2abb9fc9 (2012-06-07): Starting with this nightly, the bug was no longer reproducible.

3. Revision 423b9c30c73d (2013-10-17): Last nightly in which the bug was no longer reproducible.

4. Revision 4e7d1e2c93a6 (2013-10-18): Starting with this nightly, the bug started being reproducible again.

5. Revision a75897e664dd: This revision enabled e10s by default and started masking the problem. With e10s, the cursor never disappears. This is still the case until today, and is most likely a bug. However, in non-e10s, this bug is still reproducible.

6. Revision a6db8f54f5aa: With this revision, the cursor starts to be permanently visible in non-e10s as well. Although this is a bug, the immediate security issue reported here is no longer present in either e10s or non-e10s, since the cursor never disappears.

7. Revision b5842b906435 (bug 1121811): This revision properly fixed the security issue in non-e10s: The cursor disappears when hovered over the Flash object. Once the div is moved over the Flash object, the cursor reappears. For e10s however, the behavior is unchanged and the cursor remains permanently visible. The immediate security issue reported here continues to no longer apply.
:BenWa, your patch in bug 1121811 had the nice side-effect of fixing this security issue in non-e10s. To quickly summarize: the issue is that the cursor disappears over a Flash object that requests to hide the cursor. Then, a div object is moved on top of the Flash object. The cursor used to not reappear in this case. Your patch properly fixed this for non-e10s by letting the cursor disappear when requested, but once the div was moved over the Flash object, the cursor would reappear. In e10s however, the cursor never disappears in the first place. So, even though the security issue isn't present in e10s, we fail to hide the cursor.

I haven't had the chance to look into this in detail yet, but would you happen to know if your patch might only work in e10s? Do you have any thoughts on making it e10s compatible? Maybe more importantly, do you know if the regression of 60 FPS recomposites is still present in e10s that you intended to fix in bug 1121811?
Flags: needinfo?(bgirard)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> spohl, this looks very similar to bug 1117591, can you look at them together?

Side-note: I just noticed that this was meant to be bug 1117951. I'll look into that bug next.
I don't see how my patch has anything to do with the cursor. I suspect trying to follow what the difference in NP_SetWindow sent to the plugin and how the plugin responds to that by hidding/unhidding the plugin. Once you understand that then we can make sure we do the right thing with e10s and not by accident.
Flags: needinfo?(bgirard)
As of bug 1092630[1], the security issue reported here is no longer reproducible because the cursor no longer disappears when hovered over the Flash object. Bug 1121811[2] later fixed this in that the mouse starts disappearing again when appropriate, but it also reappears when the div is moved over the Flash object, so the security issue reported here remains not reproducible. I've reduced the test case and opened bug 1130435 to track the remaining e10s issue of the cursor not disappearing when hovered over the Flash object when it should. I'm marking this bug as WFM, but we shouldn't open it until bug 1092630 (and ideally bug 1121811) become part of our release branch and most likely ESR.

[1] https://hg.mozilla.org/mozilla-central/rev/a6db8f54f5aa (bug 1092630)
[2] https://hg.mozilla.org/mozilla-central/rev/b5842b906435 (bug 1121811)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
yes the cursor reappears when the div is moved over flash but it's not needed for the exploitation of this vulnerability, if you don't want change the resolution of this bug i will disclose this one which is exactly the same as bug995603, so, this bug is not fixed on each firefox version and this vulnerability is sec-high... if you want continu like this it like you want but i will disclose it in this case.
Status: RESOLVED → REOPENED
Flags: needinfo?(spohl.mozilla.bugs)
Resolution: WORKSFORME → ---
Keywords: sec-high, testcase
(In reply to Jordi Chancel from comment #9)
> yes the cursor reappears when the div is moved over flash but it's not
> needed for the exploitation of this vulnerability,

Could you clarify what you mean by this? The cursor reappears when it is moved away from the Flash object, or when the div is placed on top of it. Is there something else that we missed that makes this still exploitable?

> if you don't want change
> the resolution of this bug i will disclose this one which is exactly the
> same as bug995603, so, this bug is not fixed on each firefox version and
> this vulnerability is sec-high...

Yes, this isn't fixed on each version of Firefox, which is why this bug remains closed until the patches were able to make it to stable and ESR. Daniel, do you suggest that we handle this differently?
Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(dveditz)
(In reply to Stephen Pohl [:spohl] from comment #10)
> Yes, this isn't fixed on each version of Firefox, which is why this bug
> remains closed until the patches were able to make it to stable and ESR.
> Daniel, do you suggest that we handle this differently?

If we know which patch made the problem go away then "FIXED" is a better resolution than WORKSFORME. When we resolve a severe security bug it's important to track which versions are still affected. I've set the status-firefox flags based on my interpretation of your comment 4, please correct them if they're wrong.

But did bug 1121811 really fix the problem? Looks like the fix there was a backout of bug 1092630, but that one didn't land until Firefox 37. Seems hard to blame that one for this bug which Jordi reported against Firefox 35. Given we haven't found "a" fix we can backport to release builds it's probably better to leave this one open and just mark status-firefox38 as fixed.
Flags: needinfo?(dveditz)
Whiteboard: "fixed" by bug 1121811 on trunk
[Tracking Requested - why for this release]:
Lacking a fix and running out of time for Fx36 I'm not sure this will be approved, but I'd like to track it anyway to keep pressure on the effort to find a fix.
It is indeed a bit late in the 36 cycle. Not tracking but don't hesitate to propose if you find a low risk patch
(In reply to Stephen Pohl [:spohl] from comment #10)
> (In reply to Jordi Chancel from comment #9)
> > yes the cursor reappears when the div is moved over flash but it's not
> > needed for the exploitation of this vulnerability,
> 
> Could you clarify what you mean by this? The cursor reappears when it is
> moved away from the Flash object, or when the div is placed on top of it. Is
> there something else that we missed that makes this still exploitable?
Flags: needinfo?(jordi.chancel)
(In reply to Stephen Pohl [:spohl] from comment #14)
> > 
> > Could you clarify what you mean by this? The cursor reappears when it is
> > moved away from the Flash object, or when the div is placed on top of it. Is
> > there something else that we missed that makes this still exploitable?

in this testcase,the flashobject is completly covers by a div object( the flash object normaly defined the cursor like invisible) and when the cursor is invisible on the flash object and a div covers this object , the cursor is invisible and the invisibility is persistant (this demonstration is possible in firefox stable version 35.0.1).


In nightly it isn't the case because there is a bug in all flash object which defines the cursor as invisible , all flash object which should render the cursor invisible don' allow this possibility due to a bug inthe nightly version, when the bug in the nightly version will be fixed (allowing to renders invisible the cursor in all flash object which have this particularity) this bug will work on nighlty version.
Flags: needinfo?(jordi.chancel)
(In reply to Jordi Chancel from comment #15)
> (In reply to Stephen Pohl [:spohl] from comment #14)
> > > 
> > > Could you clarify what you mean by this? The cursor reappears when it is
> > > moved away from the Flash object, or when the div is placed on top of it. Is
> > > there something else that we missed that makes this still exploitable?
> 
> in this testcase,the flashobject is completly covers by a div object( the
> flash object normaly defined the cursor like invisible) and when the cursor
> is invisible on the flash object and a div covers this object , the cursor
> is invisible and the invisibility is persistant (this demonstration is
> possible in firefox stable version 35.0.1).
> 
> 
> In nightly it isn't the case because there is a bug in all flash object
> which defines the cursor as invisible , all flash object which should render
> the cursor invisible don' allow this possibility due to a bug inthe nightly
> version, when the bug in the nightly version will be fixed (allowing to
> renders invisible the cursor in all flash object which have this
> particularity) this bug will work on nighlty version.

I think you're referring to the difference between e10s vs. non-e10s windows. However, although the cursor is permanently visible in e10s (tracked by bug 1130435), the underlying security issue appears to be fixed by revision b5842b906435, i.e. bug 1121811 (see point 7 in comment 4).

Could you try to reproduce the issue in a current nightly with e10s disabled? Here are the steps:
1. Open browser to about:config
2. Set browser.tabs.remote.autostart.1 to false.
3. Restart the browser.
4. Run your test case.

Does the issue reproduce?
Flags: needinfo?(jordi.chancel)
i will reproduce whant you say quickly and say if there is any difference ( or if my nightly version was not updated like it should be the case.
Flags: needinfo?(jordi.chancel)
firstly ,on last firefox nightly update 38.0a1 (2015-02-23) on MAC OS X old version and YOSEMITE version, with flash last version (Adobe Flash Player Shockwave Flash 16.0 r0 Up to Date 16.0.0.305 ) the cursor doesn't disappeared when it is over the flash object (i haven't yet reproduce all steps you needed with e10s disabled , i will reproduce this steps immediatly and say if there is a difference.
Yes, that's due to bug 1130435.
after all steps you have needed me : the cursor disappears on the flash object when it is over it and appears when div cover it (when on about config the browser.tabs.remote.autostart.1 is false) (so this vulnerability doesn't work on last firefox nightly version but it works perfectly on firefox 35.0.1 stable version last update.
Flags: needinfo?(spohl.mozilla.bugs)
Thanks, Jordi! I've also gone ahead and confirmed that this issue is fixed in Firefox 37.0a2 (2015-02-23). This was to be expected, since bug 1121811 also landed there. The issue continues to be reproducible in Firefox 35 and Firefox 36.
Flags: needinfo?(spohl.mozilla.bugs)
Whiteboard: "fixed" by bug 1121811 on trunk → "fixed" by bug 1121811 on trunk , this vulnerability is exactly similar (same impact / same user interaction / same security rating) as bug 995603.
Whiteboard: "fixed" by bug 1121811 on trunk , this vulnerability is exactly similar (same impact / same user interaction / same security rating) as bug 995603. → "fixed" by bug 1121811 on trunk , this vulnerability is exactly similar (same impact / same user interaction / same security rating) as bug 995603 so the security rating is sec-high
Whiteboard: "fixed" by bug 1121811 on trunk , this vulnerability is exactly similar (same impact / same user interaction / same security rating) as bug 995603 so the security rating is sec-high → "fixed" by bug 1121811 on trunk , vulnerability exactly similar (same impact / same user interaction / same attack possibility) as bug 995603 so this vuln is sec-high
Keywords: sec-high
Whiteboard: "fixed" by bug 1121811 on trunk , vulnerability exactly similar (same impact / same user interaction / same attack possibility) as bug 995603 so this vuln is sec-high → "fixed" by bug 1121811 on trunk
Summary: Mozilla Firefox for Mac OS X : Cursor can be totally invisible using flash object and div (same vulnerability and same demonstration as bug995603) → Mozilla Firefox for Mac OS X : Cursor can be totally invisible using flash object and div
Flags: needinfo?(mwobensmith)
Attachment #8553549 - Attachment mime type: application/zip → application/java-archive
The severity of this bug falls in the wide mushy middle. Technically it's spoofing which is normally sec-low. Your examples eventually do sec-high things like turn on the camera or sec-critical things like installing random add-ons -- however it doesn't do those things silently with a drive-by. It requires some serious interaction with the user and the attack is not "silent" because ultimately the permission prompts/dialogs do pop on top where the user can see what happened. In the most critical case of the addon installs the attack assumes you've hacked addons.mozilla.org or convinced the user to change the pref allowing all sites to do installs. Even if the prompts popping up don't cause the user to abandon ship before getting hacked (perhaps it pops up within the user's reaction time) it's still going to cause the attack to get reported and prevent the potential for widespread damage that the sec-high and sec-critical severities represent. Even simple phishing sites with incorrect URLs fool some of the people some of the time.

You are correct that this bug has an identical impact to bug 995603. The bug that is rated incorrectly was bug 995603, artificially pushed to the high side so we could award a bounty in appreciation of your work and the novelty of the attack.

(in a few days I'll tag this comment off-topic so it does not distract the developers from fixing the problem.)
Flags: needinfo?(abillings) → sec-bounty?
Keywords: sec-moderate
Please direct comments about security bounties and severity ratings to the security alias. They are off-topic in a bug report which should be focused on diagnosing and fixing bugs.
Flags: needinfo?(dveditz)
Whiteboard: "fixed" by bug 1121811 on trunk → "fixed" by bug 1121811 on trunk ; Can I do a mix with Bug941482 or Bug927541 for renders silent the attack of the WebRTC webcam clickJacking?
Whiteboard: "fixed" by bug 1121811 on trunk ; Can I do a mix with Bug941482 or Bug927541 for renders silent the attack of the WebRTC webcam clickJacking? → RESOLVED FIXED by bug 1121811 on trunk ; Can I do a mix with Bug941482 or Bug927541 for renders silent the attack of the WebRTC webcam clickJacking?
Whiteboard: RESOLVED FIXED by bug 1121811 on trunk ; Can I do a mix with Bug941482 or Bug927541 for renders silent the attack of the WebRTC webcam clickJacking? → [adv-main37+] RESOLVED FIXED by bug 1121811 on trunk ; Can I do a mix with Bug941482 or Bug927541 for renders silent the attack of the WebRTC webcam clickJacking?
Alias: CVE-2015-0810
Flags: sec-bounty? → sec-bounty+
Whiteboard: [adv-main37+] RESOLVED FIXED by bug 1121811 on trunk ; Can I do a mix with Bug941482 or Bug927541 for renders silent the attack of the WebRTC webcam clickJacking? → [adv-main37+] RESOLVED FIXED by bug 1121811 on trunk
Duplicate of this bug: 1121833
This vulnerability is fixed in Firefox 37 
( https://www.mozilla.org/en-US/security/advisories/mfsa2015-35/ ). 

Can you make the resolution of this bug like RESOLVED/FIXED or VERIFIED/FIXED please ? ( It is important for me )

Thank you.

-Jordi Chancel
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(abillings)
Flags: needinfo?(spohl.mozilla.bugs)
Assignee: spohl.mozilla.bugs → nobody
I'm not sure exactly how to best close this, as it was technically fixed by bug 1121811. However, bug 1121811 wasn't dealing with the security issue reported here, so duplicating seems inappropriate. I'll let others make the call.
Status: REOPENED → RESOLVED
Closed: 5 years ago4 years ago
Flags: needinfo?(abillings)
Resolution: --- → FIXED
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.