1255174 - Mac OS X : Cursor-ClickJacking (CursorJacking) vulnerability (persistent invisibility of cursor) using a Flash object in fullscreen (which defined the cursor invisible) and quit this fullscreen mode

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Jordi Chancel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160303134406

Steps to reproduce:

Like Bug 1158439 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1158439 ), Bug 1125013 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1125013 ), Bug 1009540 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1009540 ) and Bug 995603 ( https://bugzilla.mozilla.org/show_bug.cgi?id=995603 ) the cursor is totally invisible.
This new Cursor-ClickJacking (CursorJacking) vulnerability uses a Flash object in fullscreen mode (which defined the cursor as not visible) and go out of this fullscreen mode.

This Cursor-clickjacking (CursorJacking) vulnerability can allow to render the cursor totally invisible and this invisibility is persistent and can be used :

- To spy the WebCam and the Microphone using WebRTC notification (others similar notifications could be used by a malicious attacker).
- To instal a malicious secure certificate for a dangerous website. 
- To execute (probably) a Java Applet locally (not tested for the moment).
- And much others malicious actions like the others previous Cursor-ClickJacking vulnerabilities already reported and fixed on some Firefox previous versions.

The testcase uses differents steps to exploit this vulnerability (all these steps are shown in the video example noted in this description already uploaded and accessible for you).

----

/!\ In the testcase , i use a Flash movie and when this Flash object is in fullscreen mode, the button to quit the fullscreen mode is in the bottom of the screen. 
So the flash object isn't perfectly crafted for a better exploitation but if I had used a flash object with the same results which allow to go in fullscreen mode and allowing the invisibility of cusor, but with a button in the center of the screen to quit the fullscreen mode (instead of the bottom of the screen used by the Flash object into the testcase that i will upload , this could be more convincing). /!\

Vidéo Example: https://www.youtube.com/watch?v=sholwXyGyOg 

STR :

-1: Go on the testcase and click on the button named "Click1" and after some seconds, another button "Click2" appears, the user should also click on it.(The 1st button starts the Flash movie and the 2nd button will use the fullscreen mode of this Flash object).
The Flash movie could be invisible (by a method used in a common ClickJacking attack (eg: style="opacity:0.0; filter:alpha(opacity=0);" ).
 
-2: When you are in Fullscreen mode , click on the button in the flash object to go out of this fullscreen mode (this button is in the bottom of screen).

-3: After some seconds (when the user has closed the fullscreen mode), the cursor becomes invisible and this invisibility is persistent. A fake cursor appears and is used instead the real cursor for effectuate a malicious attack. 
The user goes on the cancel button into the fake Download "open file" dialog with the visible cursor (the visible cursor is fake) , a WebRTC notification appears and the real cursor (always invisible) is on the button which will activated the webcam of the trapped user when the trapped user thinks clicked on the "cancel" button of the fake Download "open file" dialog.

Tested on Mac OS X Yosemite 10.10.2 and El Capitan 10.11 .



Actual results:

Cursor is totally invisible and this invisibility is persistent (like a Cursor-ClickJacking attack) and can be used to spy the webcam and the microphone of a trapped user and can be used for very much others malicious actions.



Expected results:

Normally the cursor should not be invisible when it is on a WebRTC notification (or all others similar notifications ) and when it goes out the webpage.

Comment 1

[Jordi Chancel]

Attachment: TestCase n°1 [use the testcase on Http: protocol].zip

Comment 2

[Jordi Chancel]

Matt, Could you define the severity and/or confirm this vulnerability please?

Thanks

Comment 3

[Matt Wobensmith [:mwobensmith][:matt:]]

This does not reproduce for me. I can see, based on comparing my results to the video, that this example is highly dependent on screen resolution, browser window size and possibly other display issues. 

As is, I would mark this unable to reproduce.

If this issue were reproducible, I would probably mark it as a duplicate of the last similar Flash/cursor bug you filed. This is the same issue - event passing between Firefox and Flash is incorrect, Flash thinks it has focus and can hide the cursor, but in fact, focus has been returned to Firefox.

Comment 4

[Jordi Chancel]

(In reply to Matt Wobensmith [:mwobensmith][:matt] from comment #3)
> This does not reproduce for me. I can see, based on comparing my results to
> the video, that this example is highly dependent on screen resolution,
> browser window size and possibly other display issues. 
> 
> As is, I would mark this unable to reproduce.
> 
> If this issue were reproducible, I would probably mark it as a duplicate of
> the last similar Flash/cursor bug you filed. This is the same issue - event
> passing between Firefox and Flash is incorrect, Flash thinks it has focus
> and can hide the cursor, but in fact, focus has been returned to Firefox.

I realy think that this Cursor-ClickJacking vulnerability isn't a duplicate of my last similar Flash/cursor bug report.

I perfectly reproduced the testcase on Mac OS X 10.11 El Capitan, 

but the Flash Object (Flash movie) used in the testcase opens sometime a popup which doesn't launch the Flash movie directly 
(if a popup is launched you must to click again on the same place of the "Click1" button).

I will make again some tests on the testcase and try to code a new testcase which will be more easily to reproduce.

(eg: use another Flash object and change some html/javascript code for that the testcase can be reproduces using every window size , screen resolution , etc ).

So I will try to code a better testcase quickly and upload it for that you could better understand this testcase and reproduce it more easily.

I will "needinfo" you when the new testcase will be uploaded.

Thanks

Comment 5

[Jordi Chancel]

The testcase works very well on every window size , screen resolution , 
I have tested this testcase on Mac OS X YOSEMITE 10.10.2 and Mac OS X El Capitan 10.11 with multiple screen resolution and multiple window size and the testcase works very well.

But I repeat that the flash object used in the testcase opens sometime a popup which doesn't launch the Flash movie directly 

So, if a popup is launched you must to click again on the same place of the "Click1" button 

and after click on the "click2" button for activated the fullscreen mode 

and when you are in the fullscreeen mode click on the button in the flash movie for go out of this fullscreen mode.

Matt, could you try again with the same testcase please?

Thanks

––––––

And like described in the description of this report :

/!\ In the testcase , i use a Flash movie and when this Flash object is in fullscreen mode, the button to quit the fullscreen mode is in the bottom of the screen. 
So the flash object isn't perfectly crafted for a better exploitation but if I had used a flash object with the same results which allow to go in fullscreen mode and allowing the invisibility of cusor, but with a button in the center of the screen to quit the fullscreen mode (instead of the bottom of the screen used by the Flash object into the testcase that i will upload , this could be more convincing). /!\

––––––

Comment 6

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

Bounty minusing for now since this has been resolved "works for me" for a while. If the status changes, we will reconsider it for bug bounty.