Closed Bug 264560 Opened 20 years ago Closed 20 years ago

http meta refresh allows bypassing of XPI whitelist

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Version:
1.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: nivoside, Assigned: dveditz)

References

(Depends on 1 open bug)

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, regression, Whiteboard: [sg:fix])

Attachments

(2 files, 1 obsolete file)

testcase
143 bytes, text/html
Details
remove unnecessary "trustReferrer" code
1.66 KB, patch
Biesinger
: review+
jst
: superreview+
asa
: approval-aviary+
asa
: approval1.7.5+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041013 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041013 Firefox/0.10 When the link set to .xpi is clicked, in the case of the site where it has not appeared in a white list, it is blocked automatically. However, if it jump to .xpi with a refresh tag, this safeguard will not operate. Example: <HTML> <HEAD> <META HTTP-EQUIV="refresh" CONTENT="5; URL=http://hogehoge/spyware.xpi"> </HEAD> </HTML> Reproducible: Always Steps to Reproduce: 1.A page with a mechanism like an example is read. 2.It is not displayed that installation was blocked. Actual Results: 3.Installation Countdown of a dialog starts. Expected Results: Installation is stopped if the site has not appeared in a white list. A detailed cause also has report that the safeguard operated normally in the following unknown environments but. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 Furthermore, the information on build that this bug was reproduced is also added. Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
I don't believe this is an exploit worthy of being marked confidential. The information toolbar and XPI whitelist is not the primary mechanism here. A user still has to agree to install the software in the dialog.
Release Notes - Firefox Preview Release ("Greenlane") http://www.mozilla.org/products/firefox/releases/ > You can now open blocked popups, and the Extension install system > now blocks all attempts to install software > from sites other than update.mozilla.org. I will think that I do not need to treat this bug as secret, if a previous description is rewritten. It is fearful to take action dangerous to not knowing for the user of Firefox being protected with the imperfect safeguard. Users get used to pushing the button of a dialog too much. I think that the security mechanism by the white list is a wonderful idea very effective in order to take care of a user. In Firefox for which easy UI which can set up a zone is not prepared like IE, this function is very important. I want whether it should be fixed before this bug causes an important problem, and to hear the opinion of a security specialist.
Attached file testcase —
I have to respectfully disagree with Asa's assessment here. If we allow bypassing the whitelist, we have a serious problem. Or, the whitelist concept is really useless, and we're going to accept that IE does it better. We can't afford to be that short-sighted.
IIRC, sites can also bypass the XPI whitelist by using FTP.
Summary: It will be installable, even if it has not appeared in a white list, if the software of .xpi uses redirection. → Site can bypass XPI whitelist using redirect
This could be exploited really easily. If the user is on an imitation umo, or something else they trust already, there's no reason why we can reasonably expect that they're going to be astute enough to actually read where stuff's getting installed from. If that was enough in the first place, then the infobar/whitelist concept is a LOT of wasted time and code.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0+
Summary: Site can bypass XPI whitelist using redirect → http meta refresh allows bypassing of XPI whitelist
We need to fix this. Sites cannot bypass the whitelist using ftp, but the whitelisting is calculated somewhat differently. ftp urls are whitelisted based on where the xpi itself is hosted, not the launching site. This is suboptimal but unless we start hosting xpis on ftp://update.mozilla.org--we don't they're on ftp://ftp.mozilla.org and sometimes 3rd party sites--in practice the default protection is equivalent. This testcase, however, shows how to bypass whitelisting completely. This is not a security exploit, but as it could be used to badger the user into installing something evil (the purpose of whitelisting in the first place) I'd like to leave this bug confidential for a bit longer just as we kept a recent popup blocker bug confidential for a little while.
Assignee: bugs → dveditz
Whiteboard: [sg:fix]
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Browser
Version: unspecified → 1.0 Branch
(In reply to comment #3) > Created an attachment (id=162273) > testcase > > I have to respectfully disagree with Asa's assessment here. If we allow > bypassing the whitelist, we have a serious problem. Or, the whitelist concept > is really useless I happen to think the whitelist concept is useless. The web will just learn to post a little bit of information about what the user needs to do to add a site to the whitelist. Most users will happily follow those instructions. This is not a security issue. There is no exploit here and I don't see where the current security guidelines allow for keeping this closed as a security bug. The whitelist isn't about security. It's about giving the user one extra warning before he downloads and executes some code.
not an extra warning so much as preventing modal-dialog extortion: while(!InstallTrigger.install(....)) alert("you must install to continue. Bwa ha ha ha!"); The problem is that we're not getting a referrer in a meta-refresh. If we're trusting referrers we think that means the user typed the xpi in to the URL bar, which I wanted to allow as a way to bypass whitelisting for single installs. But (<ding!>) I just realized that https also doesn't pass referrers. I guess I was thinking that necko just didn't send the referrer, but I just checked and they aren't ever even added to the channel. So another way to get around whitelisting would be loading a xpi from an https page. Try, for example, clicking the url link from bug 246369.
Attached patch fix (obsolete) — — Splinter Review
This fixes the problem at the cost of no longer allowing users to type xpi's into the URL bar. For non-whitelisted sites they'll have to download it and launch it from a file: url instead
Attachment #162374 - Flags: superreview?(jst)
Attachment #162374 - Flags: review?(bugs)
Attachment #162374 - Flags: review?(bugs) → review+
Comment on attachment 162374 [details] [diff] [review] fix per irc discussion... the trustReferrer variable is unneeded now, it is enough to check referringURI.
Per comments from biesi I'm removing the whole "trustReferrer" cruft, not necessary if we're no longer treating a null referrer special in some cases.
Attachment #162374 - Attachment is obsolete: true
Comment on attachment 162427 [details] [diff] [review] remove unnecessary "trustReferrer" code want this on aviary and 1.7
Attachment #162427 - Flags: superreview?
Attachment #162427 - Flags: approval1.7.x?
Attachment #162427 - Flags: approval-aviary?
Attachment #162427 - Flags: superreview? → superreview?(jst)
Whiteboard: [sg:fix] → [sg:fix] have patch, need sr= and a=
Comment on attachment 162427 [details] [diff] [review] remove unnecessary "trustReferrer" code sr=jst
Attachment #162427 - Flags: superreview?(jst) → superreview+
Comment on attachment 162427 [details] [diff] [review] remove unnecessary "trustReferrer" code a=asa for aviary and 1.7 checkin.
Attachment #162427 - Flags: approval1.7.x?
Attachment #162427 - Flags: approval1.7.x+
Attachment #162427 - Flags: approval-aviary?
Attachment #162427 - Flags: approval-aviary+
Whiteboard: [sg:fix] have patch, need sr= and a= → [sg:fix] needs landing
dveditz: do you have an aviary tree or do you want me to land this?
landed trunk and branches
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0, fixed1.7.x
Resolution: --- → FIXED
Whiteboard: [sg:fix] needs landing → [sg:fix]
Seems like this bug is not fixed. Testcase still works with Firefox 1.0 RC1. Reopen?
This regressed, most likely due to fixing bug 265135 (a regression caused by this fix). ARGH!!!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 266554
Removing fixed flags to get this on the blocker radar again. We need a fix for this ASAP.
Keywords: fixed-aviary1.0, fixed1.7.x
would like to get this landed by tuesday, think that is possible?
Keywords: regression
Whiteboard: [sg:fix] → [sg:fix]patch in bug 266554
What's the status here? Cutoff is Tuesday night!
266554 has the patch for this, removing from the blocking list.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Fixed on the aviary branch again (in bug 266554).
Keywords: fixed-aviary1.0
OK, testcase didn't worked with Firefox 1.0 RC2. Firefox blocked bugzilla.mozilla.org from installing software.
Firefox windows branch build 2004-11-06-07-0.11 -loaded testcase from comment #3 -wait a moment -the "to protect your computer...." warning appears. -Click "edit options" button in the warning bar -resulting dialog offers option to add bugzilla.mozilla.org to the download white list which currently contains only u.m.o Isn't that suppose to happen?
Yes, this is fixed on Aviary again and by default b.m.o installs should be blocked. Needs bug 266554 to land on the trunk before it's fixed there.
the fix in bug 266554 closes the regression, fixed again on 1.7 branch
Keywords: fixed1.7.5
patch in bug 266554 landed on the trunk, fixed again.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Whiteboard: [sg:fix]patch in bug 266554 → [sg:fix]
Blocks: 248511
Group: security
Attachment #162374 - Flags: superreview?(jst)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: