Closed
Bug 765063
Opened 12 years ago
Closed 12 years ago
navigator.mozApps.install can be fooled into using an incorrect installing origin
Categories
(Core Graveyard :: DOM: Apps, defect)
Core Graveyard
DOM: Apps
Tracking
(blocking-kilimanjaro:+, blocking-basecamp:+, firefox14 unaffected, firefox15- unaffected, firefox16+ verified, firefox-esr10 unaffected)
VERIFIED
FIXED
mozilla15
Tracking | Status | |
---|---|---|
firefox14 | --- | unaffected |
firefox15 | - | unaffected |
firefox16 | + | verified |
firefox-esr10 | --- | unaffected |
People
(Reporter: Gavin, Assigned: myk)
References
Details
(Keywords: sec-high, Whiteboard: [blocking-webrtdesktop1+], [qa!] [advisory-tracking-])
Attachments
(2 files)
See bug 745928 comment 4. The "origin" used to determine the installation origin is retrieved from the window after the XHR to retrieve the manifest has been fetched, during which the window could have been navigated to anywhere.
There's a working testcase at http://app.g4v.org/, see screenshot of the produced doorhanger attached.
That page just does:
var request = navigator.mozApps.install("http://app.g4v.org/app.webapp");
document.location = 'about:blank';
(I chose about:blank because it's quick to load, but obviously that could be anything, and you could play tricks with delaying the manifest load to control things even further.)
Comment 1•12 years ago
|
||
Confirmed on desktop. Does not reproduce on Android though (cause Android does not show the location of the origin of where the app was installed from.
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → Web Apps
Product: Core → Firefox
QA Contact: general → webapps
Comment 2•12 years ago
|
||
Also - this is a front-end bug with desktop web apps (so this belongs in firefox --> web apps).
Updated•12 years ago
|
Summary: navigator.mozApps.install can be fooled into using an incorrect installing origin → Web apps doorhanger can be fooled into using an incorrect installing origin during install of a web app
Reporter | ||
Comment 3•12 years ago
|
||
No, this is a fundamental issue with the API - the specific symptom I mention in comment 0 isn't the only issue (and probably isn't the worst).
This is a core bug in the DOM API, so it belongs in DOM.
Component: Web Apps → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: webapps → general
Reporter | ||
Updated•12 years ago
|
Summary: Web apps doorhanger can be fooled into using an incorrect installing origin during install of a web app → navigator.mozApps.install can be fooled into using an incorrect installing origin
Comment 4•12 years ago
|
||
Let me backup and ask this question: What's affected by this then? What ends up being fooled here outside of the web apps doorhanger? Does this affect B2G? Does this affect the return values of the mozapps API after a call to install?
Better overarching question - what's the variable being referenced that holds the value of about:blank in that screenshot?
Comment 5•12 years ago
|
||
I believe because of this bug an attacking page can install (with the user's confirmation) any arbitrary manifest it hosts, and receipts passed to install(), for any origin (i.e., not just for the attacking page's origin).
Updated•12 years ago
|
blocking-kilimanjaro: ? → +
blocking-basecamp: --- → ?
Comment 6•12 years ago
|
||
We need to fix this for the 1st release of desktop web runtime
tracking-firefox16:
--- → ?
Whiteboard: [blocking-webrtdesktop1+]
Updated•12 years ago
|
blocking-basecamp: ? → +
Assignee | ||
Comment 7•12 years ago
|
||
I'm having trouble reproducing the problem automatically. I wrote a test that should do so, but when I run the test without fixing the bug, installation fails with the error:
************************************************************
* Call to xpconnect wrapped JSObject produced this error: *
[Exception... "Failure arg 0 [nsIDOMRequestService.fireError]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///Users/myk/Mozilla/x86_64-apple-darwin11.4.0-dbg/dist/NightlyDebug.app/Contents/MacOS/components/Webapps.js :: <TOP_LEVEL> :: line 146" data: no]
************************************************************
The original exception that triggers that one is:
TypeError: this._window is null
Which is presumably triggered by the reference to this._window.location.href on line 130 of dom/apps/src/Webapps.js.
Nevertheless, the fix in this patch looks correct, and the test passes with it, and it also works in my manual testing using Gavin's testcase, so it seems to fix the bug.
After building the appropriate directories, I run the automated test with:
make mochitest-chrome TEST_PATH=dom/tests/mochitest/webapps/test_bug_765063.xul
Note: it'd also be worth investigating why the doorhanger doesn't disappear as soon as the page location changes, which would prevent users from installing the app in the first place and seems worth doing, since otherwise the malicious site might still fool the user into thinking they're installing an app from a different site, even if this patch prevents the malicious site from fooling the webapp registry.
In theory, the doorhanger should disappear when the location changes, because XULBrowserWindow.onLocationChange calls PopupNotifications.locationChange, which closes doorhangers unless they set persistWhileVisible, and webappsUI doesn't do that <http://hg.mozilla.org/mozilla-central/file/b39f4007be5a/browser/modules/webappsUI.jsm#l139>.
Perhaps the location change races the notification? I added two buttons to my test app:
call install, then redirect immediately
call install, then redirect after one second
- http://www.mykzilla.org/app/
And the doorhanger sticks around when the first one redirects immediately, but it goes away when the second one redirects after one second.
Updated•12 years ago
|
Attachment #638948 -
Flags: review?(fabrice) → review+
Updated•12 years ago
|
status-firefox-esr10:
--- → unaffected
status-firefox14:
--- → unaffected
status-firefox15:
--- → affected
status-firefox16:
--- → affected
tracking-firefox15:
--- → +
Updated•12 years ago
|
QA Contact: jsmith
Assignee | ||
Comment 8•12 years ago
|
||
Comment on attachment 638948 [details] [diff] [review]
patch v1: set install URL/origin before initiating XHR
https://hg.mozilla.org/integration/mozilla-inbound/rev/fa750527a43b
Attachment #638948 -
Flags: checkin+
Updated•12 years ago
|
Whiteboard: [blocking-webrtdesktop1+] → [blocking-webrtdesktop1+], [qa+]
Assignee | ||
Comment 9•12 years ago
|
||
(In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> Note: it'd also be worth investigating why the doorhanger doesn't disappear
> as soon as the page location changes, which would prevent users from
> installing the app in the first place and seems worth doing, since otherwise
> the malicious site might still fool the user into thinking they're
> installing an app from a different site, even if this patch prevents the
> malicious site from fooling the webapp registry.
I filed bug 771294 on this issue. It too is marked Security-Sensitive, and I cc:ed a few folks who are cc:ed to this bug, but let me know if you aren't cc:ed and would like to be (and can't cc: yourself).
Assignee | ||
Comment 10•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/654181827f06
(resolve test bustage caused by fix for this bug)
Assignee | ||
Comment 11•12 years ago
|
||
Landed on central. Will request uplift to aurora after it bakes a couple days.
https://hg.mozilla.org/mozilla-central/rev/fa750527a43b
https://hg.mozilla.org/mozilla-central/rev/654181827f06
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Comment 12•12 years ago
|
||
Verified on Nightly.
Status: RESOLVED → VERIFIED
Whiteboard: [blocking-webrtdesktop1+], [qa+] → [blocking-webrtdesktop1+], [qa!]
Updated•12 years ago
|
Whiteboard: [blocking-webrtdesktop1+], [qa!] → [blocking-webrtdesktop1+], [qa+]
Updated•12 years ago
|
Whiteboard: [blocking-webrtdesktop1+], [qa+] → [blocking-webrtdesktop1+], [qa!]
Assignee | ||
Comment 13•12 years ago
|
||
I was going to request uplifting this to Aurora, but in bug 772638 the desktop runtime drivers propose disabling webapps in Firefox 15, which would make uplift unnecessary, so I'm going to wait on the outcome of that.
Comment 14•12 years ago
|
||
(In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> I was going to request uplifting this to Aurora, but in bug 772638 the
> desktop runtime drivers propose disabling webapps in Firefox 15, which would
> make uplift unnecessary, so I'm going to wait on the outcome of that.
What about B2G? Do they need the uplift to FF 15? Jonas do you know?
Note - this patch affects multiple platforms, so we have to check to see if the B2G team wants this uplifted or not.
Comment 15•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #14)
> (In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> > I was going to request uplifting this to Aurora, but in bug 772638 the
> > desktop runtime drivers propose disabling webapps in Firefox 15, which would
> > make uplift unnecessary, so I'm going to wait on the outcome of that.
>
> What about B2G? Do they need the uplift to FF 15? Jonas do you know?
B2G isn't a released product yet. There is no point in uplifting this for it. B2G will use a Gecko version higher than 15 anyway.
Comment 16•12 years ago
|
||
Marking as unaffected for 15 given bug 772638.
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → DOM: Apps
Comment 17•12 years ago
|
||
Can we make this bug publicly visible now?
Updated•12 years ago
|
Whiteboard: [blocking-webrtdesktop1+], [qa!] → [blocking-webrtdesktop1+], [qa!] [advisory-tracking-]
Updated•12 years ago
|
Group: core-security
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•