User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20150415140819 Steps to reproduce: Cursor is totally invisible on the webpage wich contents a flash object (which defined the cursor invisible) into an iframe with a big paddin. Sometime, after clicked on a button of the addon installation manager with the invisible cursor, the invisibility of the cursor is remains persistant and there is no limit for all types of clickjacking / CursorJacking / Spoofing attacks (WebRTC prompt for allow webcam spying / Geolocation Prompt for allow geolocation spying / Java Applet for allow its installation and its execution / etc. -1: Go to the testcase and move the cursor into the flash object wich defined the cursor invisible -2: A fake button and a fake cursor appears in some seconds, move the visible cursor on the fake button ( the visible cursor is a fake cursor) and after some instants, a XPI addon installation manager appears (the real vursor is always totally invisible and is on the installation button of the addon installation box. -3: Now try to click on the fake button but instead clicking on this fake button , the installation button of the addon is pressed and the addon is installed. (i will make and upload a demonstration video quickly.) Actual results: When a flash object (wich defined the cursor invisible) into an iframe wich have a big padding, the cursor remains invisible and it's possible like bug1125013 , bug1121833 and bug995603 to press the installation button of the addon installation box with the invisible cursor like a ClickJacking/CursorJacking attack. Expected results: The cursor remains invisible on the Addon Installation Box.
Use this first testcase and let me know if you have any problem to reproduce (setps are in the Description )
Attachment #8597569 - Attachment description: TestCase N°1 - Invisible Cursor Firefox v+37.zip → TestCase N°1.zip
This is pretty much exactly the same as the other bugs mentioned in comment 0. The cursor is hidden even when the Flash movie loses focus, and I suspect it's just another case of Firefox-to-plugin event handler mismanagement. As far as an exploit, it also has the same issues as the other mentioned bugs. In order to clickjack anything, you have to perfectly convince the user to click in a certain area at a certain time. This requires an exploit to be perfectly adaptive to the user's configuration, or else the user will not fall for it. I tried this sample many times, and it never tricked me into clicking the add-on install confirmation button. With a lot of effort, someone could make this a bit more reliable, but as is, it does not convince. It is a bug that we should consider fixing, but does not merit anything greater than sec-moderate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #8597569 - Attachment mime type: application/zip → application/java-archive
Jordi: we haven't been able to reproduce this, is there a particular OS or set up that you use? (also an intermediate file appears to be gone now, but we couldn't reproduce it before either.)
Can you still reproduce this after bug bug 1121811 fixed the general "invisible cursor on Mac" issue?
(In reply to Daniel Veditz [:dveditz] from comment #5) > Can you still reproduce this after bug bug 1121811 fixed the general > "invisible cursor on Mac" issue? This vulnerability worked very well after that the bug 1125013 was be fixed. The poc demonstrates that when an Addon XPI window is opened , the cursor was always invisible if the cursor was placed on the Addon window, but now with the new Addon execution method, so we need another window with the same properties and I think that i've found a new method ( a window with the same properties for render again the cursor invisible which has the same proprieties like the last Addon window in the last firefox versions where the poc in this report has worked perfectly [Firefox 41 and Firefox 40] ). I will send you ( the more quickly possible) a new testcase which demonstrate that a new malicious method can render again the cursor invisible. but like Matt Wobensmith has already said (after tested the poc on Firefox 39 and others versions) had already confirmed the severity of this security bug and the bug Bug 1121811 was integrated on Firefox 39 ( the version when Matt Wobensmith has confirmed this vulnerability). I will send you a needinfo flag when i will upload a new testcase.
Did you find a new testcase for this, Jordi?
Like i've said in comment6 : "I think that i've found a new method ( a window with the same properties for render again the cursor invisible which has the same proprieties like the last Addon window in the last firefox versions where the poc in this report has worked perfectly" I will work in a few days on this vulnerability for send you the new testcase the more quickly possible ( Sorry for the delay ). When the new testcase will be uploaded , i will send you a "needinfo" request for you confirm this new PoC. Thanks.
Closing this for now and minusing. If you find a new testcase that reproduces, please re-open and send us an email about the bounty.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: sec-bounty? → sec-bounty-
Resolution: --- → WORKSFORME
I found a new similar vulnerability , but which works differently than the actual testcase in this bug report. I will report the new testcase in another bug report because like i've said it works differently and it can be used in differents cases like the spying of the webcam and microphone ( WebRTC notification , and all others notification ) , the installation of a secured certificat for a malicious website , and many others interactions.
You need to log in before you can comment on or make changes to this bug.