884488 - Execute a XPI cover by a select/option element

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Jordi Chancel]

Attachment: Spoofing clickjacking firefox local.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

-Click on the first button (click 1) 
-Click on the second button (select element [click 2])
-Click on the 3rd button (option element [click 3])
XPI Addon is cover by the select/option element and it's possible to make a clickjacking/spoofing attack.
(look this youtube video if you don't enderstand => http://www.youtube.com/watch?v=NMXkEzfX5_A&feature=youtu.be )


Actual results:

Windows calc command is executed (we can execute a trojan).


Expected results:

The select/option element shouldn't cover the XPI addon .

Comment 1

[Jordi Chancel]

for the instant run this vulnerability localy.

Comment 2

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

From the video this doesn't so much look like spoofing or click jacking but the windows are being positioned in such a way as to try and obscure them and their intent. Given that add-ons are as powerful as the browser it's also no surprise that they can be used for malicious intents and we have seen that from time to time, and is a direct reason we have a delayed install window and recommendations that users only install add-ons from trusted sources (AMO for example). Unless the windows covering the install is somehow locked there (not evident from video) the user could unstack them and read the windows and not install. Or just as easily click the not install button as that is not obscured or covered.

Comment 3

[Jordi Chancel]

I can cover the "not install" button,
this vulnerability is the same as https://bugzilla.mozilla.org/show_bug.cgi?id=726264 (critical vulnerability)

Comment 4

[Jordi Chancel]

it's the same vulnerability as https://bugzilla.mozilla.org/show_bug.cgi?id=726264

Comment 5

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

I can confirm this on Windows only. The image covers the XPI install dialog and therefore constitutes a real UI spoof. It could be used to trick users into installing untrusted XPIs. 

Also, side note: the image that is used to cover the UI is persistent and isn't easily dismissed, even with a page refresh. 

The only issue left in my mind is whether this is a duplicate of another bug, open or closed.

Comment 6

[Daniel Veditz [:dveditz]]

Why do we allow non-AMO sites to trigger installs so easily? THAT seems to be as big a problem as the spoof-using-select problem.

Comment 7

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

FWIW, follow these steps to reproduce the issue.

1. Download files locally (or run from attached JAR if you wish)
2. Launch index1.html
3. Click "Click 1" button.
4. Dismiss JS alert dialog.
5. Click "Click 2" image.
6. A new image is displayed. Click anywhere on this new image. (important)
7. Assuming this new image covers the XPI install dialog, click "Install Now"
8. Observe calculator.

Notes:
- Step 6 is important, because the overlayed image only remains if it's been given focus OR if your mouse happens to be positioned above it when the other page loads.

- The doorhanger that displays an XPI install confirmation is suppressed because of a geolocation doorhanger bug that Jordi has already filed (868327, but this is reportedly a dupe of another.) I find that the geolocation dialog does not always get suppressed - it appears to be intermittent.

While the execution might look a bit sloppy, I think it's good enough to trick many people into installing a malicious XPI. The ability to place an image in a SELECT element above our UI is the big problem, and the ability to suppress doorhanger(s) is also not good.

Comment 8

[Jordi Chancel]

what is the severity? high or critical?

Comment 9

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

Jordi - we haven't decided yet.

However, adding to my comment 7, I'm also going to point out that spawning the geolocation dialog is part of the hack here, as it forces focus to stay on the XPI install dialog for the clickjacking part.

Comment 10

[Jordi Chancel]

I've found the same issue with a form history...
Can I report a new bug?

Comment 11

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

Jordi - feel free to report a new bug.

Comment 12

[Jordi Chancel]

https://bugzilla.mozilla.org/show_bug.cgi?id=888842

Comment 13

[Jordi Chancel]

i have a testcase that works remotely by http:// do you want it?

Comment 14

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

No need for a remote test case. The one you've provided is fine, thanks.

Comment 15

[Jordi Chancel]

what info do you need?

Comment 16

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

Jordi, please don't clear flags for other people.

Comment 17

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

Attachment: Mac_example.mov

Screen capture of this running on a Mac.

Comment 18

[Jordi Chancel]

Attachment: Windows exemple

Comment 19

[Jordi Chancel]

I do not want to work with Curtis Koenig, he is not even able to confirm the vulnerability and write their severity, it slows down the work everyone!

Comment 20

[Jordi Chancel]

Attachment: Linux exemple

Comment 21

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

OK, after further investigation, I realize that I am making a critical mistake in running this locally and assuming that this is the same behavior as we'd expect when hosted from the web.

When run locally, it works. When hosted from a web server, it does not.

Jordy, in comment 13 you mentioned that you can host this via HTTP and that it works when run from the web. If this is the case, please provide us with a URL so that we can see it working. 

Thank you.

Comment 22

[Jordi Chancel]

Attachment: REMOTE TESTCASE WINDOWS EXEMPLE

Comment 23

[Jordi Chancel]

Attachment: REMOTE TESTCASE.ZIP

After verification please write the severity of this vulnerability.

Comment 24

[Mats Palmgren (inactive)]

Testing the PoC in comment 23 in Nightly and Firefox 23 on Windows 7 (all en-US).

First, the "Tripleclickme" button seems misplaced on my system.  I assume it's
meant to be in the same position as the "Allow" button in the add-on
installation door-hanger to cause an involuntary click on it.

After adjusting the "Tripleclickme" button offset, triple-clicking doesn't
actually cause a click on the "Allow" button, it seems to be ignored.
The button UI looks like it's pressed but no action occurs - the installation
dialog isn't opened.  (Maybe we have some defense in place that ignores clicks
with click count > 1 there?)

Anyway, if I play along and click "Allow" and quickly click the other
("clickme quickly...") button as instructed I get the "wait the 5 seconds
and press Enter" thing to display above the installation dialog.
(it's slightly misplaced so I can see "Install Now" button, but I assume
that's easily fixed).

Still, the whole thing doesn't seem very convincing to me...
Do users really triple-click on buttons just because the web page says so?
(disregarding that it doesn't actually work in this case).
And then click another button "very quickly" and then "wait 5 seconds
and press Enter".  It seems unlikely that a user can be tricked into
following a complicated series of actions like that, or even performing
it correctly.

I'm not trying to deny this is a bug of course, we should definitely fix
this "combobox drop-down overlaps UI" problem somehow.  But if it's this
hard to trigger then I don't see it as a big threat at the moment.

Comment 25

[Jordi Chancel]

if it's not critical it's high ... don't say me that it's moderate.

Comment 26

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

Jordi,

Looking at the rating guidelines as https://wiki.mozilla.org/Security_Severity_Ratings, how do you say it is critical or high?

Comment 27

[Jordi Chancel]

sec-critical
    Exploitable vulnerabilities which can lead to the widespread compromise of many users. 
sec-critical Examples:

    Launching of arbitrary local application with provided arguments
    Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue
    Any crash where random memory or NULL is executed (the top of the stack is not a function)




And i don't view any moderate vulnerability that lead to code execution.

So this vulnerability is critical or high

Comment 28

[Jordi Chancel]

please don't clear "sec-high" or write the severity that you think.

Comment 29

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

(In reply to Mats Palmgren (:mats) from comment #24)
 
> After adjusting the "Tripleclickme" button offset, triple-clicking doesn't
> actually cause a click on the "Allow" button, it seems to be ignored.
> The button UI looks like it's pressed but no action occurs - the installation
> dialog isn't opened.  (Maybe we have some defense in place that ignores
> clicks with click count > 1 there?)

 So it doesn't work as advertised.
 
> Anyway, if I play along and click "Allow" and quickly click the other
> ("clickme quickly...") button as instructed I get the "wait the 5 seconds
> and press Enter" thing to display above the installation dialog.
> (it's slightly misplaced so I can see "Install Now" button, but I assume
> that's easily fixed).
> 
> Still, the whole thing doesn't seem very convincing to me...
> Do users really triple-click on buttons just because the web page says so?
> (disregarding that it doesn't actually work in this case).
> And then click another button "very quickly" and then "wait 5 seconds
> and press Enter".  It seems unlikely that a user can be tricked into
> following a complicated series of actions like that, or even performing
> it correctly.
> 
> I'm not trying to deny this is a bug of course, we should definitely fix
> this "combobox drop-down overlaps UI" problem somehow.  But if it's this
> hard to trigger then I don't see it as a big threat at the moment.

I'm making this a sec-moderate. This chain of events requiring user interaction is too lengthy to be higher.

Jordi, this isn't "arbitrary execution" because even if you succeeded in installing a custom XPI, it isn't going to take over a user's entire computer and launch, for example, calculator. If you can post a version of this that doesn't require repeated user interaction to install *and* can do damage, we can re-evaluate. The definition of sec-critical you quote above mentions "user dialog fatigue" in it. This is part of what Mats is discussing.

Jordi, do not clear or change security flags. If you do, they will changed back. It isn't for you, as an external reporter, to set or clear those flags. You can make an argument against a rating but changing meta flags on a security bug isn't something you should be doing.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

(In reply to Al Billings [:abillings] from comment #29)
> Jordi, this isn't "arbitrary execution" because even if you succeeded in
> installing a custom XPI, it isn't going to take over a user's entire
> computer and launch, for example, calculator.

That's not true - extensions have system privileges, so installing one without user consent is exactly arbitrary remote code execution.

Comment 31

[Jordi Chancel]

haha ! so sec-high or sec-critical?

Comment 32

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

Jordi, while I am corrected by Gavin, your bug doesn't really work because it requires a massive amount of user interactions. You didn't respond to what Mats said so it stands. This *may* be a sec-high but I am quite skeptical that you can get anyone to click to it.

Comment 33

[Jordi Chancel]

on nightly build mozilla 26 it's fixed on mac os !RESOLVED FIXED?

Comment 34

[Jordi Chancel]

correction it's on mozilla firefox 24.0b10 is fixed on mac

Comment 35

[Jordi Chancel]

i think it only don't work on my macbook air Mac Os X v 10.7.5, but on the video Mac_exemple.mov it works perfectly .

Comment 36

[Jordi Chancel]

in fact it works perfectly well ! sorry for the two previous message it's not important

Comment 37

[Daniel Veditz [:dveditz]]

fwiw we ought to have a bug on file somewhere about how terrible it is that we have the clickjackable "Allow" dropdown. I know I've complained about it enough! We ship with a whitelisted install store. We don't need to make it easy to add more sites to that list. Either you go to AMO and get a nice experience, or you download the file and "Install" it from your local disk like some setup.exe

Comment 38

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

Bug Bounty Triage: We're making this the master bug for XPI clickjacking issues that you're reporting. They are all variants of the same basic problem.

Comment 41

[David Chan [:dchan]]

Hi Jordi,

Thanks for reporting this bug to us. The bounty committee has decided to pay on bug 941482 instead of this bug. We believe both bugs have very similar root causes (hiding chrome UI). The ability to overlay content on top of the chrome UI exists in many areas as you have discovered. We are working toward a fix on that.

We are aware of the risks by allowing users to install addons from non-trusted sites.

Comment 43

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

Dan, is this even an issue anymore with various redesigns and feature changes?

Comment 44

[Daniel Veditz [:dveditz]]

I can't really reproduce either issue with the new UI.