1208703 - Combinations of keys pressed on the keyboard into the Private Browsing home page(about:privatebrowsing) which is opened after that a dialog window is opened (window.showModalDialog), leads to Arbitrary Code Execution.

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Jordi Chancel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150917150946

Steps to reproduce:

(My exploit is exploitable only on MAC OS X but can be adapted for Windows, Linux, ...)

When you have convinced a lambda user to press multiple keys on the keyboard into the home page of the Private Browsing "about:privatebrowsing" which is at the first plan (because it is opened after a dialog window [window.showModalDialog] ), can hide the developper tool : "JavaScript Scratchpad" and lead to Arbitrary Code execution.

With a specially crafted webpage it's possible to insert data into the clipboard for the purpose of paste these data silently and maliciously.

Step 1 : Go to : http://alternativ-testing.fr/5J9L-javascript-scratchpad-showmodaldialog-keys_pressed-code%20exec/

Step 2 : Realize the instructions on this web page (which consist to press multiple keys on the keyboard after that the steps 1 and 2 have been effected)



Actual results:

Explanation:
Malicious JavaScript Code : [javascript:file=Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);file.initWithPath("/Applications/Calculator.app/Contents/MacOS/Calculator");process=Components.classes["@mozilla.org/process/util;1"].createInstance(Components.interfaces.nsIProcess);process.init(file);args=[];process.run(false,args,args.length);] is executed into "about:privatebrowsing" using the JavaScript-Scratchpad which isn't visible ( hidden by the private browsing home page at the first plan ) and leads to execute : [/Applications/Calculator.app/Contents/MacOS/Calculator].


This vulnerability can be also used for use a XSS attack type on all website where an attacker wants steal sensitive informations (cookie / saved password & login / webpage content / register all key pressed / ... ).



Expected results:

In my view, when the JavaScript Scratchpad is opened, it should be automatically on the first plan, even if a dialog window is opened, the JavaScript scratchpad must be on top of the dialog window for security reason, because this one isn't visible and like my TestCase demonstrates the potential dangerosity concerned, this possibility is unsecure for Firefox users.
On another similar bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1202234)  on the comment 10 (https://bugzilla.mozilla.org/show_bug.cgi?id=1202234#c10) there is 3 proposition for fix the vulnerability,
but there is some problems with option 2 and option 3.

Option 2) says that we must not allow devTools on privileged pages by default, but with this bug , the javascript scratchpad can be opened behind an unprivileged webpage which is on a dialog window and can still execute arbitrary code if a privileged page like (about:privatebrowsing) is opened after the unprivileged webpage and that the javascript code pasted in the javascript scratchpad is executed after that the privileged page has been opened.

Option 3) says that the devtools can't be opened if the window is too small for see the devtools, but in this case the window's lenght is not a problem because we can execute arbitrary code on a privileged window with a normal lenght.



Vulnerability bug found and reported by Security researcher Jordi Chancel.

Comment 1

[Jordi Chancel]

Attachment: TestCase n°1 (Arbitrary Code Execution with about:privatebrowsing).html

Comment 2

[Jordi Chancel]

Attachment: TestCase n°1 (Arbitrary Code Execution with about:privatebrowsing).html

Comment 3

[Jordi Chancel]

I have add some people in the CC list for confirm this report.

Matt Wobensmith , can you define the sec-severity please? (This vulnerability bug very similar to Bug1202234 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1202234 ).

Thanks.

Comment 4

[Daniel Veditz [:dveditz]]

What is a "lambda user"? "power user"? In a fresh profile this PoC fails because you have to type "allow pasting" into the scratchpad before pasting works, and a normal user will not have done that. A power user is extremely unlikely to follow all those keystrokes without getting suspicious (they'll know what some of them mean).

Key to this PoC is showModalDialog() which is deprecated and a known security hazard (for exactly this kind of "hiding what's really going on" reasons). Already killed in Chrome, not yet dead in Firefox (see bug 981796)

Uses Flash to capture the Copy to Clipboard, but most users will have flash, and if they don't you could just try to convince the user to do more keystrokes. There might even be a DOM api for it in the future.

I don't really blame devtools here -- they're doing what they're supposed to do.

Don't know why about:privatebrowsing needs to be privileged. Can we reduce that?

Comment 5

[Jordi Chancel]

I would know if the bug1208703 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1208703 can be valid for the "sec-bounty ?" flag , this vulnerability has the same impact as bug1202234 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1202234 but require a different patch ,

For the Bug1202234, they have three proposition to fixe it (on comment10 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1202234#c10 :

One (hard) option would be to re-write the page as unprivileged like about:home, and implement the powerful features it needs via a postMessage() API. That's probably not worth the work.

2) Another mitigation would be to not allow devTools on privileged pages by default, instead showing some kind of warning. Probably a door-hanger since those float and would be visible no matter the size of the window, with a scary-ish warning about powerful features and an "Allow" (once) button. Power users will want a "Allow Always" option, but that could perhaps be enabled through devtools settings rather than on the in-your-face door hanger.

3) And lastly, Jordi's suggestion in comment 2 is a good idea. Either don't open devtools if they can't be shown, or automatically trigger the existing "Show in separate window" functionality.

---

but with the bug1208703 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1208703 ) the only possibility to fixe this vulnerability is to forbiden the window.showModalDialog() JavaScript function or to choose the more dificult option (option 1 in comment10 on bug1202234 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1202234#c10 ) so the two others options can't fixe the bug1208703 .

So this bug report demonstrates than the only possibility to fixe Bug1202234 and Bug1208703 is the option1 in comment10 on Bug1202234 -> https://bugzilla.mozilla.org/show_bug.cgi?id=1202234#c10

Comment 6

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

Jordi,

We've asked you before to email us about bounty questions. We get enough specific mail from bugzilla about bugs that we don't need bounty questions or needinfo? for them here. Since you *also* sent an email, I'm not sure why you're spamming the bug with bounty questions. Please don't.

Comment 7

[Daniel Veditz [:dveditz]]

We have not fixed bug 1202234, this is the same essential problem: if you can convince a user to trust you, you can fool them into doing dangerous stuff. Although the details differ here, it's the same social engineering attack. If we figure out how to prevent users from doing this in one place it will likely fix it here. For purposes of the bug bounty program we're considering this a duplicate of bug 1202234

Comment 8

[Daniel Veditz [:dveditz]]

sorry, wrong flag. this one is not getting a separate bounty

Comment 9

[Jordi Chancel]

I've moved the repertory of my testcase in my server, the testcase is available in the new URL address.

Comment 10

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #4)

Key to this PoC is showModalDialog() which is deprecated and a known
security hazard (for exactly this kind of "hiding what's really going on"
reasons). Already killed in Chrome, not yet dead in Firefox (see bug 981796)

Happily, this is gone now.