385 bytes, text/html
8.67 KB, patch
|Details | Diff | Splinter Review|
344 bytes, text/html
185 bytes, text/html
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3 My report to firstname.lastname@example.org: An attacker may force a script installation to happen, then change the page behind the scenes so that the callback occurs in the domain of any random page. Note that this happens whether the user clicks "ok" or "cancel" on the XPI install dialog. This can be used to steal cookies, passwords, submit information to another site, etc. The sample exploit provides the users bugzilla cookie in a dialog, but could easily submit it to another site. See attached testcase. Note that testcase should be run on a different server, since it steals cookies from bugzilla. Reproducible: Always Steps to Reproduce:
Exploitation would require injecting this code into a site whitelisted for install (but that's currently possible, see bug 292302). Then again, if you can inject code into arbitrary sites you could just inject the attack code rather than go through the InstallTrigger redirection.
Assignee: nobody → dveditz
Severity: critical → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
The worse case is being able to inject code in about:config or any other XUL page, if you can get around the problem of loading that sort of page from untrusted content. The InstallTrigger script would be run within the chrome, with full chrome privileges. Since you can inject code into any page (even those not normally vulnerable to injection) I think this becomes much more critical.
Flags: blocking-aviary1.0.5? → blocking-aviary1.0.5+
cc'ing a few folks to see if we can get some traction here, we need a fix soon if this is going to make 1.0.5.
Whiteboard: [sg:fix] eta: 6/28 → [sg:fix] eta: 6/28 [cb] no progress for 1.8b3?
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
Version: unspecified → Trunk
Affects suite as well--worse, in fact, because there's no whitelisting.
dveditz tells me if you remove the IconURL from the testcase, it works as expected.
The approach taken is to save the nsIPrincipal when InstallTrigger.install is called. Then before calling out to the saved callback, we check to see if the current principal matches what we saved. This ensures that InstallTrigger and the callback function exist within the same context, if i understand correctly. This patch provide no user interface that the callback was not executed. I have tested this against a modified version of the testcase above which I put here for testing. http://www.meer.net/~dougt/eviltrigger.html I also put a legal "do no evil" test case which shouldn't be broken here. You will see a install fail dialog -- but the point is that the callback is called and you will see an alert telling you that. http://www.meer.net/~dougt/installtrigger.html In both cases, you need to whitelist www.meer.net for _testing_. Doug
Comment on attachment 188355 [details] [diff] [review] patch v.1 doug says he's attaching one with fixed whitespace
incorporating dan's comments.
Whiteboard: [sg:fix] eta: 6/28 [cb] no progress for 1.8b3? → [sg:fix] need sr=, a=, landing
Comment on attachment 188362 [details] [diff] [review] patch v.2 a=chase pending jst's sr
Should those sample exploit pages be password protected?
Comment on attachment 188362 [details] [diff] [review] patch v.2 sr=jst
Attachment #188362 - Flags: superreview?(jst) → superreview+
Whiteboard: [sg:fix] need sr=, a=, landing → [sg:fix] ready for landing
TRUNK: Checking in nsJSInstallTriggerGlobal.cpp; /cvsroot/mozilla/xpinstall/src/nsJSInstallTriggerGlobal.cpp,v <-- nsJSInstallTriggerGlobal.cpp new revision: 1.46; previous revision: 1.45 done Checking in nsXPITriggerInfo.cpp; /cvsroot/mozilla/xpinstall/src/nsXPITriggerInfo.cpp,v <-- nsXPITriggerInfo.cpp new revision: 1.29; previous revision: 1.28 done Checking in nsXPITriggerInfo.h; /cvsroot/mozilla/xpinstall/src/nsXPITriggerInfo.h,v <-- nsXPITriggerInfo.h new revision: 1.21; previous revision: 1.20 done AVIARY_1_0_1_20050124_BRANCH: Checking in nsJSInstallTriggerGlobal.cpp; /cvsroot/mozilla/xpinstall/src/nsJSInstallTriggerGlobal.cpp,v <-- nsJSInstallTriggerGlobal.cpp new revision: 220.127.116.11.2.5; previous revision: 18.104.22.168.2.4 done Checking in nsXPITriggerInfo.cpp; /cvsroot/mozilla/xpinstall/src/nsXPITriggerInfo.cpp,v <-- nsXPITriggerInfo.cpp new revision: 22.214.171.124; previous revision: 126.96.36.199 done Checking in nsXPITriggerInfo.h; /cvsroot/mozilla/xpinstall/src/nsXPITriggerInfo.h,v <-- nsXPITriggerInfo.h new revision: 188.8.131.52; previous revision: 184.108.40.206 done MOZILLA_1_7_BRANCH: Checking in nsJSInstallTriggerGlobal.cpp; /cvsroot/mozilla/xpinstall/src/nsJSInstallTriggerGlobal.cpp,v <-- nsJSInstallTriggerGlobal.cpp new revision: 220.127.116.11; previous revision: 18.104.22.168 done Checking in nsXPITriggerInfo.cpp; /cvsroot/mozilla/xpinstall/src/nsXPITriggerInfo.cpp,v <-- nsXPITriggerInfo.cpp new revision: 22.214.171.124; previous revision: 126.96.36.199 done Checking in nsXPITriggerInfo.h; /cvsroot/mozilla/xpinstall/src/nsXPITriggerInfo.h,v <-- nsXPITriggerInfo.h new revision: 188.8.131.52; previous revision: 184.108.40.206 done Marking fixed.
installtrigger.install() example which should work -- it does nothing evil.
email@example.com -- I removed the test cases from the web.
Note to QA: the eviltrigger.html testcase (or original testcase for Firefox 1.0.3 or earlier) need to be hosted on a non-bugzilla site -- if the original page starts on bugzilla then there's no problem if the callback can get your bugzilla cookies. Adding fixed keywords to match checkin comment
Security advisories published
You need to log in before you can comment on or make changes to this bug.