92.10 KB, application/java-archive
1.89 MB, video/quicktime
823.14 KB, application/octet-stream
1.37 MB, application/octet-stream
872.28 KB, application/java-archive
53.81 KB, application/java-archive
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 .
for the instant run this vulnerability localy.
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.
Summary: Mozilla Firefox 21.0 Critical SPOOFING-CLICKJACKING (execute a XPI cover by a select/option element) → execute a XPI cover by a select/option element
Version: unspecified → 21 Branch
I can cover the "not install" button, this vulnerability is the same as https://bugzilla.mozilla.org/show_bug.cgi?id=726264 (critical vulnerability)
Attachment #764319 - Attachment mime type: application/octet-stream → application/java-archive
it's the same vulnerability as https://bugzilla.mozilla.org/show_bug.cgi?id=726264
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
what is the severity? high or critical?
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.
I've found the same issue with a form history... Can I report a new bug?
Jordi - feel free to report a new bug.
i have a testcase that works remotely by http:// do you want it?
No need for a remote test case. The one you've provided is fine, thanks.
what info do you need?
Jordi, please don't clear flags for other people.
Screen capture of this running on a Mac.
Summary: execute a XPI cover by a select/option element → Execute a XPI cover by a select/option element
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!
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.
After verification please write the severity of this vulnerability.
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.
if it's not critical it's high ... don't say me that it's moderate.
Jordi, Looking at the rating guidelines as https://wiki.mozilla.org/Security_Severity_Ratings, how do you say it is critical or high?
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
please don't clear "sec-high" or write the severity that you think.
(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.
(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.
haha ! so sec-high or sec-critical?
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.
on nightly build mozilla 26 it's fixed on mac os !RESOLVED FIXED?
correction it's on mozilla firefox 24.0b10 is fixed on mac
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 .
in fact it works perfectly well ! sorry for the two previous message it's not important
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
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.
Attachment #787362 - Attachment mime type: application/octet-stream → application/java-archive
Attachment #787363 - Attachment mime type: application/octet-stream → application/java-archive
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.
Flags: sec-bounty? → sec-bounty-
Dan, is this even an issue anymore with various redesigns and feature changes?
I can't really reproduce either issue with the new UI.
Group: core-security → core-security-release
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.