1121833 - (CVE-2015-0810) Mozilla Firefox for Mac OS X : Cursor can be totally invisible using a flash object which renders the cursor invisible on it and the JavaScript function "Alert()" on another tab previously opened.

Status: RESOLVED DUPLICATE of bug 1125013

(Core Graveyard :: Plug-ins, defect)

Description

[Jordi Chancel]

Attachment: TestCase1.zip

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:

This vulnerability is similar to Bug 995603 .

I think this works only on Mac OS X.

steps :
-1 : Go to the testcase (1.htm), and click on the "clickme" link (a new tab will be opened).
-2 : Now you are on the new tab opened(2.htm) and must click on the "Step2 :ClickMe" button.
-3 : Move the cursor into the webpage and wait a few seconds.
-4 : A JavaScript function "Alert()" will redirect you on the previous tab (1.htm) .



Actual results:

The Cursor is now totally invisible.



Expected results:

You can use this vulnerability for install a xpi or make a clickjacking/cursorjacking or others spoofing attack on what you want.

Comment 1

[Jordi Chancel]

Attachment: Video Example MAC OS X.html

You can look this video for understand how this vulnerability works . :-)

Comment 2

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

Thanks Jordi. I can see the cursor get hidden. It appears very similar to bug 1009169, but is more reliable. I am not convinced that this alone constitutes an exploit, as you still have to convince the user to click where you want them to. However, I have reproduced the behavior.

Comment 3

[Jordi Chancel]

this vulnerability isn't low ,we can make exactly the same attack as bug 995603.

Do you want a demonstration ?

Comment 4

[Jordi Chancel]

This bug/vulnerability isn't sec-low ! 
Please look https://bugzilla.mozilla.org/show_bug.cgi?id=995603 , we can make the same attack with the same user interraction & severity ( bug995603 is sec-High ! ), so if bug 995603 is High , this bug is High too.

Comment 5

[Jordi Chancel]

Comment 4 :

This bug/vulnerability isn't sec-low ! 
Please look https://bugzilla.mozilla.org/show_bug.cgi?id=995603 , we can make the same attack with the same user interraction & severity ( bug995603 is sec-High ! ), so if bug 995603 is High , this bug is High too.

-----

I would add that i can send you a same PoC/demonstration than the PoC in bug995603 if you want.

[e-mail] , it's you which had defined bug995603 sec-High , can you confirm what i say please? 

I remain at your disposal should you have any questions or need more informations.

Comment 6

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

The first bug had a better proof of concept and appeared to be more reliable in getting the user to click somewhere predictable.

This bug hides the cursor, but no one who has tried it was successfully clickjacked. So, without an example that is shown to likely to harm people, it's not going to be rated as high.

Comment 7

[Jordi Chancel]

look https://bugzilla.mozilla.org/show_bug.cgi?id=1125013 please.

it is exactly the same bug as bug995603 with the same user interraction/severity and i have uploaded a poc like in bug 995603 , so if you don't want make this bug high , please make bug1125013 as high because it is exactly the same as bug 995603.

Comment 8

[Jordi Chancel]

Attachment: TESTCASE2 (severity demo).zip

This TESTCASE demonstrates the possible severity of this vulnerability , in this demonstration of a clickJacking attack, it's possible to render invisible the cursor for : 
use a combination with an image of the cursor manipulated through JavaScript leading to a clickjacking attack during interactions with HTML content subsequently.


With this flaw it's possible to execute an Addon (.XPI).

It's possible to make others ClickJacking/CursorJacking attacks (more or less severe than this demonstration)

Comment 9

[Jordi Chancel]

I have uploaded the TESTCASE2.zip which demonstrates the possible severity of this vulnerability , in this demonstration of a clickJacking attack, it's possible to render invisible the cursor for : 
use a combination with an image of the cursor manipulated through JavaScript leading to a clickjacking attack during interactions with HTML content subsequently.


With this flaw it's possible to execute an Addon (.XPI).

It's possible to make others ClickJacking/CursorJacking attacks (more or less severe than this demonstration)

Comment 10

[Jordi Chancel]

Attachment: Video-Example-(severity demo)on_Mac_OS_X.html

I have uploaded a new testcase which demonstrate the severity of this vulnerability and i have uploaded a video too which demonstrate the severity and user interraction needed for this vulnerability.
---

This TESTCASE demonstrates the possible severity of this vulnerability , in this demonstration of a clickJacking attack, it's possible to render invisible the cursor for : 
use a combination with an image of the cursor manipulated through JavaScript leading to a clickjacking attack during interactions with HTML content subsequently.

With this flaw it's possible to execute an Addon (.XPI).

---

It's possible to make others ClickJacking/CursorJacking attacks (more or less severe than this demonstration).
---

I assume than this flaw require more minimal user interraction than Bug995603 and bug Bug1125013 But it's not possible that this bug is only sec-low , i'm sure than this bug is sec-moderate at worst or sec-high (like i think surely). the impact is exactly the same as bug995603 (but with more minimal user interaction) . i wanna too that you look https://bugzilla.mozilla.org/show_bug.cgi?id=1125013 which is exactly the same vulnerability with the same severity and user interaction as Bug995603 (so, this bug must be defined like sec-high).

Thank tou very much for you quick answer.

Comment 11

[Jordi Chancel]

The test case that i have uploaded requires too much steps or unlikely steps, but i can code a better proof of concept which will render a better severity of this vulnerability with less steps and better likely steps for the vulnerability demonstration, please let me the time to code a better proof of concept for this vulnerability and you will define better the real severity of this security bug (for me the gravity which is the less severe is "sec-moderate" and the gravity which is the more elevated is "sec-high") .

PS: this vulnerability have the same impact than the bug995603 reported , i must just code a better testcase for render the same severityin this bug. the better Proof Of Concept will be coded and uploaded soon as possible.

Comment 12

[Jordi Chancel]

For the instant, TESTCASE2 is a better Proof of concept than the previous testcase and demonstrates a better severity but i think than i can code a better TESTCASE which will elevate the simplicity of exploitation of this vulnerability.

I will try to code quickly the better TestCase but for the moment i work on others Bug/Vulnerabilities (for demonstrate a better severity/simplicity of exploitation/using of normal user interaction/ etc.).

But i will try to code the better Proof of concept the more quickly possible, ( for the instant, TESTCASE2 is sec-moderate like less severity and for me the more elevated gravity of the Testcase2 is sec-high. So if the Testcase2 is only sec-Moderate, i will code the more quickly possible a PoC which have sec-high like severity impact.).

Comment 13

[Jordi Chancel]

Can you define the severity using the new TESTCASE (TestCase2.zip) ?

TESTCASE2.ZIP demonstrates that we can intall XPI addon using invisible cursor with low user interaction.

Comment 14

[Jordi Chancel]

Can you define the severity using the new TESTCASE (TestCase2.zip) ?

TestCase2.ZIP demonstrates that we can install an addon using this 
vulnerability which can render the cursor invisible with low user interaction.

And if the severity is not sufficient enough like sec-high or at worst sec-moderate , it is probably possible than i can code another better TESTCASE with less of user interaction (a testcase with more minimal interactions than the previous testcase "testcase1.zip" and the actual testcase "TESTCASE2 (severity demo).zip" .

Comment 15

[Jordi Chancel]

Can you define the severity using the new TESTCASE (TestCase2.zip) ?

And if the severity is not sufficient enough like sec-high or at worst sec-moderate , it is probably possible than i can code another better TESTCASE with less of user interaction (a testcase with more minimal interactions than the previous testcase "testcase1.zip" and the actual testcase "TESTCASE2 (severity demo).zip" .

Comment 16

[Stephen A Pohl [:spohl]]

(In reply to Jordi Chancel from comment #15)
> Can you define the severity using the new TESTCASE (TestCase2.zip) ?

This is not something that I do.

Comment 17

[Benjamin Smedberg]

->jesse for thoughts on a security rating

Comment 18

[Jordi Chancel]

The impact is of this vulnerability is the same as bug995603 but with a bit more of minimal user interaction , for the instant , say me what is the severity of this vulnerability issue (after test the testcase2 (severity demo).zip) (which works on firefox 36 but not on nithly 39.0a1 due to e10s enabled and revision b5842b906435 (bug 1121811) fixed on Nightly ( I recall you than revision b5842b906435 for bug 1121811 not demonstrates a vulnerability but a stability/or others which isn't in relation with the security of firefox), if you think than the severity not sec-moderate at worst , i think than i can code a better testcase which require less of user interaction (minimal interaction) an which will works with the same flash object with window.open JS function but differently (and so have a better severity of the actual testcase) but if the severity is sec-moderate at worst or sec-high at best , it is already that to obtained  :-)

Comment 19

[Jordi Chancel]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #17)
> ->jesse for thoughts on a security rating

Comment about the next security rating.


This vulnerability has the same impact as bug995603 but with a bit
more of minimal user interaction , for the instant , say me what is the
security rating of this vulnerability reported (after test the "testcase2 (severity
demo).zip" which works on firefox 36.0 and having a better severity demonstration than the first testcase uploaded ).
I think than i can code a better testcase which require less of interactions (minimal interactions also) and which works with the same flash object and with window.open JavaScript function (or with other tab opened (like before), but opened differently) (for have a new testcase with a better security rating if the security rating of the actual testcase is too low) but if the severity is sec-moderate at worst or sec-high at best like i think that the possibilities of this vulnerability are the same than bug995603 (which was "sec-high"),after using "testcase (severity demo).zip" (which works on Mozilla firefox 36.0) ,if the security rating is what i think, i will be agree with you and i will not try to code a better testcase.  :-)

Comment 20

[Jordi Chancel]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #17)
> ->jesse for thoughts on a security rating


About bug1125013 , it was rated "sec-moderate" (comment 27 on bug 1125013 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1125013#c27 ).

And Bug1125013 has the same possibilities / dangerousity / effects as this bug .

On the comment 30 on the bug1125013 i've asked this ( https://bugzilla.mozilla.org/show_bug.cgi?id=1125013#c30 ) :

"If i do a mix with another bug (unpatched) rated as 'sec-moderate' also, to program a better testcase which use these vulnerability (Bug1125013 and another Bug/Vulnerability), the testcase programed will render an attack really more 'silent' for an attack of  'spying webcam', in this case, is it possible to change the security rating?"

---
 
So, can you put a security rating for this bug now please [after testing the new  TESTCASE2_(severity_demo).zip -> https://bugzilla.mozilla.org/attachment.cgi?id=8555736 and I also forgot to tell you again that this TESTCASE2 may be significantly improved (I have an idea for not use the alert () function of JavaScript to not be forced to press the Enter key and thus used the minimum interractions and consequently that they will be as minimal as possible (using only: Cursor clicking and moving the cursor) (see comment 19 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1121833#c19 ] , and if i succeed to program a better testcase for bug1125013 , can you put a better security rating for this bug (Thus after than a better testcase programed for bug1125013 and that his security rating is thus elevated if David Veditz allows that i mix different vulnerabilities( Security Bug1125013 and another security Bug that I have in reserve (which is UNPATCHED) which allow to render the prompt WebRTC Webcam more silent)  

---

So after have read this comment you can,must/should read these others comments:

comment 27 on bug 1125013 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1125013#c27

comment 30 on bug 1125013 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1125013#c30

comment 19 on bug1121833  -> https://bugzilla.mozilla.org/show_bug.cgi?id=1121833#c19

Comment 21

[Daniel Veditz [:dveditz]]

Jordi: please don't harass the developers in the bug with off-topic conversations. Stuff about bounties and security ratings should be sent to the security alias, keep the bug focused on fixing the problem (e.g adding testcases and explanations are great, thanks for testcase2).

Comment 22

[Daniel Veditz [:dveditz]]

The cursor no longer goes invisible for me, also "fixed" by bug 1121811 on trunk? Is there any reason to believe the underlying bad interaction between Flash and Firefox on Mac is a different one from bug 1125013?

Comment 24

[Jordi Chancel]

this bug is fixed by Bug 1125013

RESOLVED/FIXED for me.