1115362 - Mozilla Firefox for MAC : with some JavaScript events and functions it's possible to bypass the addon box safety time to press directly the 'install' button in addition of an attack of clickjacking allowing to mislead the user

Status: RESOLVED INVALID

(Toolkit :: Add-ons Manager, defect)

Description

[Jordi Chancel]

Attachment: Local TESTCASE1.HTML.zip

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

Steps to reproduce:

(to load directly an addon installation box you should open the testcase localy , if you open this testcase remotely , it will don't works as it is described)

When you use some JavaScript code for load an addon with the OnMouseMove JavaScript event , it's possible to make appear an addon installation box with no secure time before to allow to click on the 'install' button.

Step to reproduce:
-1 : Use the TESTCASE1 that i have uploaded,
-2 : Move the mouse on the first blue link (step1 into the testcase),
-3 : a first Addon Installation bow will be appear with the secure time enabled ( for the moment the security works as well),
-4 : Click on the 'Cancel' button into the addon installation box,
-5 : And after , try to click quickly on the 'CLICKME QUICKLY' button into the testcase

Actual Results :
during you try to click on the "CLICKME QUICKLY" button , a 2nd Addon installation box will be loaded without security delay before to allow to click on the 'Install' button.



Actual results:

If the "CLICKME QUICKLY" Button (step2 into the testcase) is at the same place as the 'Install' button of the Addon Installation Box , it's possible that an user press the 'Install' Button instead of the other fake button and so install the malicious addon.

The Malicious addon which have not the time of security on the 'install' button can be installed using a ClickJacking attack.



Expected results:

I think it's possible to bypass directly the secure time on the addon installation box and i will try to code a better testcase for demonstrate this possibility.

Comment 1

[Jordi Chancel]

Attachment: Video Example n°1

You can look this video for understand how the TestCase works.

Comment 2

[Jordi Chancel]

Merry christmas at all of you! :-)

Comment 3

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

Merry Christmas and Happy New Year to you too, Jordi! :)

I investigated this using your files, and I think I can see what you are finding. The wait time that is used for the add-on install dialog only happens with the first attempt of installation. Subsequent attempts to install the same add-on in your sample file show that there is no wait time. 

Then, your example shows that the page might ask the user to click a button in its content. However, your theory is that - by social engineering - that click might then be used to in the add-on dialog to accidentally confirm install of the add-on. I can see that in the video you describe.

So, in summary:
- Requires local file, already present on your computer
- Local file content must position spoofed clickable button in the same area as install button in add-on dialog
- Timing must be good enough to fool user into not noticing the add-on dialog before clicking
- If all of the above are present, installation of malicious add-on is possible

Does that sound correct?

Comment 4

[Daniel Veditz [:dveditz]]

This is clearly a bug in the modal install notification dialog which tries to reset the count if the dialog loses focus. Somehow closing and reopening doesn't reset the count.

Experiment: set the pref "security.dialog_enable_delay" to 10000 (10 seconds) before re-running this test.
Results:
* if you cancel the install dialog while it's still counting down, then the next install dialog restarts the count with the button disabled.
* if you wait for the full 10 seconds to elapse before canceling then the install button remains enabled after the dialog closes and reopens.

Looks like it's reusing the same dialog object for both install requests. That seems wrong, but rather than figure that out it might be an easy fix to just reset the countdown when the cancel button is pressed.

As a practical attack this seems unlikely given the pre-conditions. You'll likely have more success convincing people to knowingly download and install hacked versions of popular freeware through buying search ads (naive members of my own family have fallen for this). The solution is probably the same: these sites get reported and blocked (eventually).

Comment 5

[Andy McKay]

Would this still be relevant since every extension install requires the user to approve the permissions dialog? There isn't any specific time count in this dialog.

Comment 6

[Kris Maglione [:kmag]]

The UI that this applied to no longer exists. The new install flow has its own issues, which have their own bug.