Closed Bug 240552 Opened 21 years ago Closed 21 years ago

Make nsInstallTrigger::UpdateEnabled check with permission manager (in effect block XPI installs from non-whitelisted sites)

Categories

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

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugs, Assigned: dveditz)

References

Details

(Keywords: fixed1.7, relnote, Whiteboard: needed-aviary1.0?)

Attachments

(4 files)

Launch XPinstall in various ways
1.53 KB, text/html
Details
Loads first testcase in an iframe
737 bytes, text/html
Details
1.7 branch patch to restrict XPInstalls to whitelisted sites
43.78 KB, patch
danm.moz
: review+
sspitzer
: superreview+
chofmann
: approval1.7+
Details | Diff | Splinter Review
trunk patch checked-in
43.98 KB, patch
Details | Diff | Splinter Review
We want to initially be able to configure Firefox so that xpinstall attempts from sites other than *.mozilla.org are blocked by default. This requires a separate permission type for xpinstall requests. Dan and I discussed initially seeding existing hostperm.1 files with valid URLs using preferences. Creating UI for this is a separate bug which can be tackled after the initial back end work is complete.
I think we want this for 1.7 too. Anyone disagree? /be
Flags: blocking1.7+
I hope you'll include Mozdev, Extension Room and Firefox Help in the default whitelist. No gripes with this holding up 1.7, malware must be stopped before it's allowed to start.
(In reply to comment #1) > I think we want this for 1.7 too. Anyone disagree? > > /be What will the preference tree be? Since the UI is separate, how will those of us comfortable with ChromEdit add/remove sites to the listing?
Even when you follow comment 2, this would mean everybody trying to use a third-party developer's page to install an extension would first need to fiddle with preferences... IMHO, this change would surely not help promoting Mozilla's (and especially Firefox's) Extensibility. And who prevents someone from making a "trojan extension" and then have it added to database.mozdev.org (= extensionroom, firefox help), ? You certainly can't check the whole code of every new extension added there...
The reservations about trojan / malicious code being hosted at a main extension site are a bit silly, especially as this bug changes nothing in terms of those main sites. Sure, not everyone will be able to scan every line of code, but I think anything malicious will be spotted soon enough and pulled from the server. Is it not worth reducing the risk to only those known and often used sites by default, instead of extending the ability to install from all sites, where the potential for misuse is far greater? As for individual unofficial sites, the UI that is implemented should make it easy to add sites to the trust list, but beyond that, why aren't these people getting their extensions listed? Hosting screenshots, FAQs, Q&A, forums, (etc.) on your own site is fine, but why avoid putting your extension on the main sites? If I were looking for an extension, I'd prefer one central source than lots of small websites with a handful of extensions each, and we should be moving in that direction anyway IMO, if not only for the sake of security, but sheer common sense.
Am I right to assume that permission whitelist would apply to the location of the web page containing the link, and not its (specified or real, redirected) target? 'Cause for Extension-Room, the web page is on mozdev.org, but the install links often point to somewhere else... (In reply to comment #5) > The reservations about trojan / malicious code being hosted at a main extension > site are a bit silly, especially as this bug changes nothing in terms of those > main sites. > If I were looking for an extension, I'd prefer one central source than > lots of small websites with a handful of extensions each, and we should be > moving in that direction anyway IMO, if not only for the sake of security, but > sheer common sense. Okay, I agree on both. ('hosted at' => 'linked by', though) > As for individual unofficial sites, the UI that is implemented should make it > easy to add sites to the trust list, but beyond that, why aren't these people > getting their extensions listed? Hosting screenshots, FAQs, Q&A, forums, (etc.) > on your own site is fine, but why avoid putting your extension on the main > sites? It's not about avoiding getting listed - some users might want to visit the homepage of a listed extension first to get more info, and then click the install link that's there. Extension writers then have to explain the process how to "trust them" on their page, which is okay enough. (Note however, that we're likely to run into the same user-clicks-OK-on-any-warning if we pop up a "would you like to trust this site?" box. However, that's still better than nothing, and should be discussed on the UI bug.)
(meant: the same user-clicks-OK-on-any-warning phenomenon we know from IE-based malware)
This will be at the same time, or after database.mozdev.org becomes redundant. There is nothing to prevent us from linking to an exterior site (other than it takes us a month to actually put the listing in), assuming it is an XPI. Database.mozdev.org nor texturizer.net actually host extensions, we merely link to them. Are we talking about extensions that will be hosted at *.mozilla.org, or linked from there?
(In reply to comment #8) > Are we talking about extensions that will be hosted at *.mozilla.org, or > linked from there? I'd hope the whitelist would be for the site that hosts the extension, because otherwise it would be too easy to submit a real extension to an authentic site, wait for it to be listed, and then switch it for a spyware-enabled version. Access to *.mozilla.org is a known quantity through CVS and friends; access to other sites (even Mozdev, texturizer.net, and other extension-loving known friends) is not. Admins on these sites simply don't have the time to test every new version of each extension for this. For some of the extensions that wouldn't even work, as some use a static address to a "latest stable" version (e.g., Googlebar). You're back to relying on the extension source for trustworthiness, which is what this is supposed to avoid in the first place. Actually, one last thought: *.mozilla.org is *not* sufficiently safe because it includes b.m.o. bugzilla.mozilla.org should be blocked because anyone with the time can create a pseudo-real-looking (but fake) bug, immediately INVALIDate it so it avoids attention among the hundreds of thousands of bugs in the DB, and upload a malicious XPI as an attachment to the bug.
Sorry for making a big discussion out of this, and for my harsh words, but I think whitelisting *only* mozilla.org could even *destroy* the extension development community that has developed so prosperously since firebird 0.7. In either case, this should not be decided in a hurry.
Further info / debate about this bug can be found here: http://forums.mozillazine.org/viewtopic.php?t=64341
Presumably, there will be a domain such as update.mozilla.org. But how will extensions on that site get listed? And how will the bandwidth issue be handled? Other than an "official" extension like DOMI, what makes *.mozilla.org safer?
I think Firefox's XPI dialog has enough advantages over IE's ActiveX dialog that this change isn't necessary. IE has a "Yes" button; Firefox has an "Install" button. IE's warning is vague and misleading ("You should only install/view this content if you trust [company] to make that assertion"); Firefox's is clear. IE's warning is surrounded by security-related imagery and the reassuring text "Publisher authenticity verified by mumbo jumbo". But if we do restrict XPIs to mozilla.org, we might as well also: 1. Restrict XPIs to update.mozilla.org, not just *.mozilla.org. 2. Restrict to a mozilla.org key instead of (or in addition to) a specific hostname, to protect against MITM attacks. 3. Place the same restrictions on script-permission prompts as on XPI prompts.
I have concern with this blocking 1.7, at least without the UI available at the same time. If 1.7 is released, and someone goes to mozdev.org and installs an extension, what will happen?
Is there any reason why people cannot host the XPIs on their own servers, but the install prompt can only be launched from whitelisted domains? The only arguement I can see against this is that people can submit a real extension, then swap it for a malicious one after being listed on the extension sites, but in reality, this would get noticed and reported quickly. The other potential disadvantage that people raise is that people would be unable to provide install links via their own website. My proposal would be to have some kind of forwarding system in these cases. Best to explain this in a step by step example: 1) User navigates his way to extensions.cusser.net and wants to install Hotmail Tabs. 2) User clicks the install link. 3) Install link loads a script (php or otherwise) on extensionroom.mozdev.org which triggers my extension installer (from their whitelisted domain) and goes back to my page. This would be possible via simple php and mysql, where the install url for the site may be (for example): http://extensionroom.mozdev.org/firefox/installer.php?extension=163&returnurl=http://extensions.cusser.net/index.html#hotmailtabs This should already be possible with the existing database, as you have the XPI location and (presumably) some kind of primary key that can be used to identify extensions.
(In reply to comment #15) > in reality, this would get noticed and reported quickly. We can't afford to have a malicious extension downloaded from a trusted site even once by a newbie; extensions need to be safe from the start. If Firefox can ever be legitimately criticized as insecure (as a malicious extension on a trusted site would be) it's lost a major advantage over IE. > The other potential disadvantage that people raise is that people would be > unable to provide install links via their own website. The default whitelist would only allow extensions from safe sites, but UI for this would easily allow other sites to be added. (The UI's a separate bug for after this.) There's absolutely no reason an extension dev couldn't provide an install link on his site; he just has to expect users of his extension to trust him. Can we wait on the discussion of this until after the backend's been implemented (or at least continue this discussion elsewhere, like Mozillazine)? The backend should be extensible, so any changes should be relatively easy. The UI is what will really determine whether these changes result in a securer browser or not, and that's a separate bug for after this one's complete.
Has a bug been filed for the UI?
(In reply to comment #15) > Is there any reason why people cannot host the XPIs on their own servers, but > the install prompt can only be launched from whitelisted domains? The only > arguement I can see against this is that people can submit a real extension, > then swap it for a malicious one after being listed on the extension sites, but > in reality, this would get noticed and reported quickly. Indeed it would. This might be getting a little complex now... buuuuut.... Firstly: The link to the extension OR the file could be whitelisted (e.g. I could link direct to an extension hosted on *.mozilla.org from my personal homepage, or someone could click "Download Ben's Extension" on *.mozilla and download the file from my server). Second: Could the URI on *.m.o contain an MD5 hash for the extension .xpi? The extension manager would download the file and then check the file MD5 against the one from the whitelisted URI and if they match, it knows that: 1) The file is presumed safe because it came from a whitelisted domain, and 2) That the file has not been modified since the submission to the whitelist site. Maybe this is getting too complicated and OTT, but I thought I should suggest it, since it might work if the security/flexibility points here aren't covered by something else already. Ben
I do think it would be good for some sort of signature check to occur, but I also think that should be a new bug.
1) Also need to ban adding .exe files to XPI. If you write for mozilla, then do it for all platforms. If even malware is in update.mozilla.org, there is no use of it either. 2) Web features -> block popup windows should be renamed to trusted sites and that list may also install XPI
note to my previous comment: malware creator can also create "googal supertoolbar" which at first sight wouldn't be spotted malicious, then upload "the next REAL version" which contains .exe files. That's why .exe file disabling in XPI should be implemented.
(In reply to comment #20) > 1) Also need to ban adding .exe files to XPI. If you write for mozilla, then do > it for all platforms. If even malware is in update.mozilla.org, there is no use > of it either. That doesn't make sense. After all, it would be very easy to have the executable named "test.xul" in the XPI, and rename it after unpacking. Besides, XPInstall does not and should not care whether the stuff being installed (and that's not always an extension) is cross-platform or not. In fact, being cross-platform could even mean having an .exe in a XPI, along with a linux and mac executable...
(In reply to comment #20) > 1) Also need to ban adding .exe files to XPI. Kill using XPI to install plugins stone dead. Nice one...
Banning .exe files from XPIs would not improve security at all because chrome javascript can do anything an .exe file can do.
I was wondering whether people had considered using certificates rather than url to determine the trustworthyness of a plugin. Basically a plugin writer could get their code signed by mozilla.org or someother body that is willing to be responsible for such things and they can host the plugin anywhere they like. By default mozilla/firefox would only allow a user to install trusted plugins. You could argue that a developer isn't going to want to get his plugin resigned everytime he makes a minor change. But in my mind this can actually work in the end users favour. Only major releases are signed so newbie users will only be able to install properly stable plugins. So far people have only considered the affect of a malicious plugin. I would argue that a poor quality plugin has an equally bad impact on a new user's experience and therefore mozilla reputation. I would envision the following: By default mozilla would only allow signed plugins to work. This means that new/basic users are guaranteed a stable experience which can be easily and safely extended. Power users would be able to make some config change that would allow any extension to be installed (possibly with warnings). That way if you really need a cutting edge plugin you can still easily do so if you have made the necessary change to your configuration. There is the prickly question as to how a plugin gets signed. Obviously, it places a burden on both the developer and the signer. I would suggest that the choice as to whether a plugin should be signed can be done by some form of peer review. Initially a new plugin is submitted as unsigned to some website for listing experimental extensions. Power users would then be able to download it. If the plugins works, is stable and doesn't appear to be malicious then after some period it can be voted to be signed and added to the main extension listing site
I think that if the XPI contains an EXE, a dialog should be displayed: WARNING! This installer contains an executable file. Executing it could damage your computer, install malicious software, or any number of other things. Please make sure you trust this extension (<<NAME>>). [Proceed] [Do Not Install] Additionally, you could also have some sort of "wrapper" for installations. For example, run them in a protected environment of some sort. If an installer tries to access an environment outside of Mozilla (i.e. an installer), display a dialog that explains that ("This installer is attempting to modify settings outside of Mozilla. While this may be valid behavior, it could be malicious or damaging. Make sure you trust this extension. [Proceed] [Do Not Install]"). comment #20: >2) Web features -> block popup windows should be renamed to trusted sites and > that list may also install XPI I disagree. There's some sites out there that you may want to get popup windows from, but you may not want to download stuff from (like serial/crack sites). There should be a dialog that pops up the first time you try to install something that warns you and instructs you like the popup window info thing does. Surely users won't want to whitelist something they're not 100% sure of (requiring a few extra clicks to do something is usually a deterrent for people who don't know too much about what they're doing). The default whitelist could contain known plugin sites (and the whitelist could whitelist based on installing URL or location of installer, or both, or either).
Actually.. I just stumbled upon this: http://www.bengoodger.com/software/mb/extensions/howto.html That idea is actually pretty good, and solves most of my suggestions.
How about this: Instead of dictating they must come from moz.org's site, issue "certificates" to the extension makers that the XPI can be buiult with so that it'll have a "Known Safe" type sticker. like a seal of quality thing. This'll take the saem amount of time (maybe less) from devs/moz.org, and no bandwidth. It's better than signing, because it'll still be reviewed, but it'll still give m.o a bandwidth break and allow devs freedome to host their own extensions that m.o might not want to.
mozilla.org will be making use of the mirrors.
Status: NEW → ASSIGNED
Flags: blocking1.7+
Flags: blocking1.7+
Not sure I'm happy with this whole approach, the restrictions work best against sites which play nice, and malicious sites by definition will not play nice. Guaranteed to enrage happy Mozilla contributors creating useful additions, making it easier to install things via downloading an executable which misses the point entirely. Would be better if we had a "blocked install" icon in the chrome, but can't be done for 1.7. For now (if this patch goes in) people who want to install things would either need to manually add the site to the xpinstall.whitelist.add pref using about:config, download the xpi and install via file: url. If it's an HTTP link and you don't block referrer then you could copy the link and enter it into the URL bar. In all cases you then still get the normal XPI confirmation dialog. Patch also contains trivial fix for regression bug 235925
Comment on attachment 149726 [details] [diff] [review] 1.7 branch patch to restrict XPInstalls to whitelisted sites Picking danm as reviewer in case he can think of a better approach from his popup-blocking battles. He's got more information inside a GlobalWindow than I get from a channel, though.
Attachment #149726 - Flags: superreview?(sspitzer)
Attachment #149726 - Flags: review?(danm-moz)
danm and seth, can you do reviews on this... i'd like to get it landed soon on the 1.7 branch if it looks good.
Why is the "texturizer.net" included in the patch for whitelist by default?? That website had nothing to do with Mozilla's websites. Or you'll have people saying we should make "cnn.com" be part of the patch or some other who would say the same thing about XXX websites.
(In reply to comment #35) > Why is the "texturizer.net" included in the patch for whitelist by default?? > That website had nothing to do with Mozilla's websites. Or you'll have people > saying we should make "cnn.com" be part of the patch or some other who would say > the same thing about XXX websites. Because texturizer.net hosts the official Firefox/Thunderbird help, and other stuff directly related to Mozilla, similar to MozDev. The beauty of having this type of a project is that if someone demands that we add CNN.com to the whitelist, we can just say no, and move on. We're not obliged to follow suggestions.
(In reply to comment #36) > (In reply to comment #35) > > Why is the "texturizer.net" included in the patch for whitelist by default?? > > Because texturizer.net hosts the official Firefox/Thunderbird help, and other > stuff directly related to Mozilla, similar to MozDev. texturizer.net doesn't actually host installable XPIs though, does it? I'm not sure it needs to be on the whitelist, unless there's something going on with referers that I don't understand.
The whitelist is intended to cover the sites *initiating* the install request, not hosting the .xpi itself. The confirmation dialog shows the source of the .xpi at which point the user could decide if they trust that server. Texturizer and mozdev need to be on the whitelist for those sites to continue working. I say "intended" because the patch only works this way for javascript InstallTrigger requests and HTTP-served .xpis with referrer headers turned on. For ftp links I couldn't figure out the true site they came from so the patch just uses the .xpi host which might be a fatal hole in this approach (a random evil site could still pester you to install things from ftp.mozilla.org should it know of something hosted there with an exploitable flaw). The Firefox team intends to restrict the whitelist to updates.mozilla.org (not even the whole of mozilla.org), but I believe they'll have time to put in some whitelist-adding UI before 1.0 This patch is quite a restriction to spring on the hard-working, enthusiastic, Mozilla supporters and contributors at sites like mozdev.org. I'd like to be generous with the whitelist, especially this close to the 1.7 release. If anyone knows of other popular and reputable theme or add-on sites let me know and we'll consider adding them. Being on the whitelist does not make it easier for a site to sneak an install onto your machine -- you'll still see the confirmation dialog. Being on the whitelist only gives the site the ability to annoy you with a potentially unwanted confirmation dialog, and that's not too dangerous a power to give to known mozilla-friendly sites. Unfortunately it's impractical to have a default list a mile-long, plus the hurt feelings when some sites make it and others don't, so I think we'll arbitrarily restrict it to sites which aggregate multiple other installs. Add we should add whitelisting UI for 1.8
Whiteboard: need reviews
Comment on attachment 149726 [details] [diff] [review] 1.7 branch patch to restrict XPInstalls to whitelisted sites Now that the usability issues have all been hashed out :) This patch looks good to me. By default it accepts only XPIs hosted on trusted sites or referred from a trusted site. It's the sort of clamp-down we need because there are jerks out there with access to Mozilla source code who will exploit weaknesses in anything less. Note that a more sophisticated user can download and install from the local hard disk, or pref off protection entirely. Notes: I fuzzed out somewhere in nsJSInstallTriggerMmmmphxxx. But it all /looked/ fine. When checking permissions for a URI, DOMWindows use nsIDOMDocument::GetDocumentURI, while InstallTrigger uses nsIWebNavigation::GetCurrentURI. They're not the same object and I think they're equivalent though there's a time during document load when the former is unavailable which it would seem makes the latter more desirable... But it'd be nice if DOMWindow and XPInstall agreed on a consistent methodology. Not much of a complaint. I must have missed something. r=danm
Attachment #149726 - Flags: review?(danm-moz) → review+
(In reply to comment #39) > When checking permissions for a URI, DOMWindows use > nsIDOMDocument::GetDocumentURI, while InstallTrigger uses > nsIWebNavigation::GetCurrentURI. They're not the same object and I think > they're equivalent though there's a time during document load when the former > is unavailable which it would seem makes the latter more desirable... But it'd > be nice if DOMWindow and XPInstall agreed on a consistent methodology. Yeah, they should agree, and using nsIDocument::GetDocumentURI() is the right thing to do since there's a window during page transition where nsIWebNavigation::GetCurrentURI() will return the URI we're transitioning to, but the current document is still the old one. r=jst too with that changed.
still trying to wrap my head our that patch. but some small nits: 1) + rv = prefBranch->GetIntPref( (const char*)"network.http.sendRefererHeader", is that cast necessary? 2) + //*aReturn = AllowInstall(uri); + //rv = UpdateEnabled(globalObject, &enabled); that commented code can be removed, right? 3) + host.Insert("http://", 0); does that mean that we will not accept xpis from https:// servers on whitelisted domains? 4) + prefBranch->GetBoolPref( (const char*)XPINSTALL_WHITELIST_REQUIRED, + &requireWhitelist ); is that cast necessary? 5) what will this mean for a company who might want to employ xpis internally? or is that just a matter of using CCK to tweak the new pref so that mycompany.com is allowed?
also, is it possible to make foo.bar.com whitelisted, but bar.com is not? this could be useful to say allow official.company.com, but not userhomepage.company.com.
>there's a window during page transition where >nsIWebNavigation::GetCurrentURI() will return the URI we're transitioning to, >but the current document is still the old one. LOL Yes that's the same moment I was referring to. For a time the document is null, and thus, no nsIDocument::GetDocumentURI. But I bow to Johnny's interpretation of this turbulent period. >3) + host.Insert("http://", 0); >does that mean that we will not accept xpis from https:// servers on >whitelisted domains? Some scheme, any scheme, is necessary only to construct a valid URL. It's stripped off by the permission manager, which cares only about the host. >5)what will this mean for a company who might want to employ xpis internally? Anyone can produce a distribution with a larger initial whitelist, and individuals can alter their whitelist after the fact, though not in a pretty way. Makes you want to be careful who gives you your copy. Which of course you should already be. >is it possible to make foo.bar.com whitelisted, but bar.com is not? PermissionManager supports this. Our UI once supported it, but that was removed because UE felt is was too complex. (I really wanted to word that a different way, but I'll stick with that.) A few tweaks to updateWhitelist would allow this if we're prepared to take on the complexity when the time comes to write a UI.
Comment on attachment 149726 [details] [diff] [review] 1.7 branch patch to restrict XPInstalls to whitelisted sites sr=sspitzer
Attachment #149726 - Flags: superreview?(sspitzer) → superreview+
Comment on attachment 149726 [details] [diff] [review] 1.7 branch patch to restrict XPInstalls to whitelisted sites a=chofmann for 1.7
Attachment #149726 - Flags: approval1.7+
Whiteboard: need reviews → ready to land
We're hoping to wrap up 1.7 early next week, so it would be good if this could land as soon as possible.
Blocks: 245062
fixed on trunk and 1.7 branch
Keywords: fixed1.7
Whiteboard: ready to land
The minor differences are to address review comments: - use document URI instead of web navigation - support ability to blacklist subdomains I'm unhappy that non-http protocols work completely differently than JS triggers and http links. The latter depend on the launching page as they should, but the former depend only on the install source. DocShell knows who triggered it in all cases but I couldn't find a good way to get that info passed to the content handler. Darin suggested that's what the channel owner is for, but I found the owner to be null in all XPInstall cases because the DocShell only sets the owner for javascript: and data: urls. I tried "fixing" that and ended up giving system privileges to all pages because nsDocument assumes that if there's an owner on the channel that's the privileges to be used by the loaded content too. Fixed that by changing nsDocument to read the owner only in the js: and data: cases and found that some of the about: pages and chatzilla were broken. I finally wised up that playing with this critical code, simple though it looked, was a really really really bad idea for a 1.7 patch. I think it's ultimately the right approach, but it needs much more thought and testing. So for now we've got this xpinstall-only change that will need to be tightened up as abusers catch on to the change, much as the popup-blocker evolved over time.
Attachment #150201 - Attachment description: actual check-in → trunk patch checked-in
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
This checkin has broken the AIX and HP-UX clobber tinderboxes. xlC_r -o nsInstallTrigger.o -c -DOSTYPE=\"AIX5.1\" -DOSARCH=\"AIX\" -DHAVE_DEPENDENT_LIBS -I/home/tbox/builds/tinderbox/AIX_5.1_Clobber/mozilla/xpinstall/src/../public -I../../dist/include/xpcom -I../../dist/include/xpcom_obsolete -I../../dist/include/string -I../../dist/include/jar -I../../dist/include/caps -I../../dist/include/content -I../../dist/include/necko -I../../dist/include/intl -I../../dist/include/locale -I../../dist/include/libreg -I../../dist/include/js -I../../dist/include/pref -I../../dist/include/widget -I../../dist/include/uriloader -I../../dist/include/xpconnect -I../../dist/include/dom -I../../dist/include/windowwatcher -I../../dist/include/plugin -I../../dist/include/unicharutil -I../../dist/include/appshell -I../../dist/include/docshell -I../../dist/include/cookie -I../../dist/include/layout -I../../dist/include/zlib -I../../dist/include/xpinstall -I../../dist/include -I/home/tbox/builds/tinderbox/AIX_5.1_Clobber/mozilla/obj-tinder/dist/include/nspr -I. -qflag=w:w -DNDEBUG -DTRIMMED -O2 -qmaxmem=-1 -qalias=noansi -DMOZILLA_CLIENT -D_MOZILLA_CONFIG_H_ -DMOZILLA_VERSION=\"1.8a2\" -DAIX=1 -DHAVE_SYS_INTTYPES_H=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_SIGINFO_T=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_INT64=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_DIRENT_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_MALLOC_H=1 -DHAVE_X11_XKBLIB_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_LIBC_R=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBC_R=1 -DFUNCPROTO=15 -DHAVE_XSHM=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_STAT64=1 -DHAVE_LSTAT64=1 -DHAVE_FLOCKFILE=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STRTOK_R=1 -DHAVE_RES_NINIT=1 -DHAVE_LANGINFO_CODESET=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DMOZ_WIDGET_GTK=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_X11=1 -DMOZ_APP_NAME=\"mozilla\" -DMOZ_ENABLE_COREXFONTS=1 -DMOZ_EXTRA_X11CONVERTERS=1 -DOJI=1 -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1 -DACCESSIBILITY=1 -DMOZ_XPINSTALL=1 -DMOZ_JSLOADER=1 -DHAVE_GSSAPI_GSSAPI_H=1 -DHAVE_GSSAPI_GSSAPI_GENERIC_H=1 -DHAVE_GSS_C_NT_HOSTBASED_SERVICE=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DMOZ_SVG_RENDERER_LIBART=1 -DMOZ_LOGGING=1 -DMOZ_USER_DIR=\".mozilla\" -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DMOZ_XUL=1 -DMOZ_PROFILESHARING=1 -DMOZ_PROFILELOCKING=1 -DSUNCTL=1 -DMOZ_BYPASS_PROFILE_AT_STARTUP=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DNS_PRINT_PREVIEW=1 -DNS_PRINTING=1 -DMOZILLA_LOCALE_VERSION=\"1.8a\" -DMOZILLA_REGION_VERSION=\"1.8a\" -DMOZILLA_SKIN_VERSION=\"1.5\" /home/tbox/builds/tinderbox/AIX_5.1_Clobber/mozilla/xpinstall/src/nsInstallTrigger.cpp "/home/tbox/builds/tinderbox/AIX_5.1_Clobber/mozilla/xpinstall/src/nsInstallTrigger.cpp", line 53.10: 1540-0836 (S) The #include file "nsIPermissionManager.h" is not found. gmake[4]: *** [nsInstallTrigger.o] Error 1 gmake[4]: Leaving directory `/home/tbox/builds/tinderbox/AIX_5.1_Clobber/mozilla/obj-tinder/xpinstall/src'
Filed Bug 245826 for the build breakage.
Ugh. I realize that this change was primarly with Firefox in mind (which already requires certain extensions) but xpinstall is still being used by seamonkey and the cookie extension (where permission manager lives) is/was still optional there. If the permission manager is going to be required, can we move it out of extensions/ or declare that extensions/ are no longer optional for suite builds?
cls: good point. We've suffered with required extensions in the past, let's not retrogress. Dan, can you file a followup bug about moving the extensions/cookie stuff to a better place, or places? Please cc: me. Thanks, /be
This did more than just add a dependency on cookie; it breaks the default client.mk target (as opposed to build_all_depend which tinderboxes do) by making a file in tier_50 depend on an export from tier_94.
FYI, this also broke all of the Thunderbird trunk builds on tinderbox: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Thunderbird
I don't know if it is related or not yet. But ever since Thunderbird turned green after Dan checked in a fix, the Thunderbird OS X build crashes on startup. Looking at the firefox tinderbox page for the trunk, it looks like it may be crashing too. Tinderbox looks green but if you look at the log you'll see: Error: regxpcom: exited with status 255 I doubt the crash would be related to xpinstall though so maybe the crash was caused by something else while the tree was red.
So now when someone clicks on, say, http://www.hacksrus.com/~ginda/chatzilla/xpi/chatzilla-0.9.64.xpi then the throbber will briefly spin and... that's all folks. At the very least the new behaviour should already be in the release notes. As it is I expect a flurry of bugs to get filed...
Keywords: relnote
Obviously it works fine from the above link hosted on a mozilla.org site ;-)
I added this to the release notes: 'To protect users from installing malicious code unintentionally, extensions and add-ons can now only be installed from trusted sites on a "whitelist". The whitelist can be altered by changing the xpinstall.whitelist.add preference.' The wording could probably be improved...
Can I double check that the XPI actually has to be hosted on the whitelisted server? If not then this patch can be trivially worked around by eg. loading a whitelisted page into a hidden iframe, modifying its DOM to point to the XPI file and then simulating a click on the link. The wording made it sound like a XPI would be accepted if hosted on a trusted site OR referred to from a trusted site. thanks -mike
Blocks: 246097
I created bug 246097 to hold discussions about changes to the default whitelist. Implementing some UI (bug 241705) will make the point moot, so whitelist fiddling is strictly a shortterm solution. RELNOTE: I would also add that the behavior can be completely reverted by changing the pref xpinstall.whitelist.required to false. comment 59 gave me a scare, but that's not possible: our same-origin policy would prevent anyone else from modifying the DOM in the iframe. Unless, of course, they've got chrome privileges or are already the same whitelisted host, and in both cases they could get the install going directly. Confusion arises because this patch implements two DIFFERENT policies that apply to different cases. I'm unhappy about this, but initial attempts to fix it a different way resulted in horrible security holes (system privileges for all--whee!). The main and intended behavior is: For purposes of whitelisting I do not care where the .xpi itself is hosted(*). The confirmation dialog tells the user about that and they can make their own decision. What I do want to stop is malicious sites pestering users with modal confirmation dialogs hoping to get some fraction of those users to say yes. Whitelisting does not stop people installing exploitable code; mozilla.org itself has shipped exploitable code--it happens. Whitelisting does not prevent evil people from hacking trusted sites. Whitelisting does not prevent evil people from hacking offsite installs referred to from trusted sites. Whitelisting does not prevent slimy evil people from posing as a good guy and earning trust, then planting exploitable code on people. Whitelisting does, I hope, restrict the problem to a small enough set of popular sites that the "many eyes" phenomenom will discover any such evils, stop them, and get the word out about how to clean up. Whitelisting *certainly* protects the 99% of normal users who would never otherwise install an add-on (*)For xpis hosted on non-http(s) protocols--or if the user has turned off http referrers--I can't currently figure out where the click originated. In those cases the decision is based on where the XPI is hosted instead. I seriously considered simply disallowing these until we can change docshell to pass reliable origination information on the channel. For non-whitelisted sites users can download the install and then manually launch it as a file: URL, much as they can for an executable -- no point in being more restrictive than executables. As far as I can tell the only currently-whitelisted site that hosts xpis over ftp is mozilla.org itself. Malicious sites can still pester people to install something from ftp.mozilla.org. Since we use mirrors that could potentially cover more than just mozilla content, we'll have to keep an eye on this. We could always quickly add ftp.mozilla.org to the BLACKlist very quickly, and distribute that pref-patch through a .xpi (the final patch contains blacklisting ability as suggested in review comment 42).
I've added a mention of the .required pref to the release note.
Blocks: 246122
(In reply to comment #56) > So now when someone clicks on, say, > http://www.hacksrus.com/~ginda/chatzilla/xpi/chatzilla-0.9.64.xpi then the > throbber will briefly spin and... that's all folks. At the very least the new > behaviour should already be in the release notes. As it is I expect a flurry of > bugs to get filed... I don't think putting it in the RELNOTES is good enough. There should be an indicator or dialog saying Mozilla has blocked the XPI. People may mistake this for a slow connection or high traffic. I've created bug 246131
Why?? There is no point to this whole "XPI whitelist" idea. From what I understand, your reasoning is: a) any XPI can contain malware b) if we restrict XPI downloads to "known good" locations we can reduce malware However it doesn't work this way. By restricting the XPI download locations you are just hurting extension developers by stopping them from easily offering extensions for download. As a number of people have pointed out, even "known good" extensions can be swapped for malware downloads, or the sites hacked (e.g. debian, savannah) and "known bad" extensions inserted in place. What about the work involved in policing these "known good" extensions? Who's going to be the thought police? Who actually has the time to decide what is "good" and what is "bad bad bad"? Why not follow the same logic with executable files? a) any executable can contain malware/viruses/bugs/bad spelling b) if we restrict executable downloads to "known good" locations we can reduce malware/viruses/bugs/bad spelling We allow people to download EXE files from anywhere and execute them directly from the download dialog. An XPI should not be any different. This half-baked idea was then rushed into a major release with no UI at all! Extensibility and openness has been one of the main features of Mozilla/Thunderbird/Firefox and then you just broke with nothing to tell users why 1.7 doesn't install my extension anymore. Yes, I expect that there will be lots of bugs on this too, and the solution is to remove this whitelist thought policing. This is not a solution but a problem. If you want a list of "known good extensions" then CREATE THAT LIST! Stick it on a website, have a menu or button in Mozilla/Firefox that directs the noob to it. Have it at the top of the default bookmarks. Advertise it in the New York Times. However don't disable XPI download/install from anywhere on the web for fake feel good "safety".
I think the whitelisting idea is a good idea, but here's the following flaws: I'm an experienced user, and I know how to work about:config, but I really don't feel like doing it just so I can allow XPIs from non-whitelisted sites; I'd just assume disable whitelisting entirely and allow all XPIs. I think that newbies will just disable the system (because you have to go through about:config to whitelist new sites, and disabling whitelisting entirely is easier), and this entire system (good in theory) is moot. If you're going to add this, make it whitelist * until you get a UI for it. You know, like work your UI people extra hard to get a UI for it, and make it into 1.7, or whitelist * and have them get the UI into 1.8. Personally, I've found sites besides Firefox Help and the Extension Room that have valid themes/extensions (like themes of OSses that don't like you to duplicate their Aqua look *cough*), and I've also found themes not hosted on either site that were on the author's site. This would be very painless if all I had to do was click on a little plugin icon in the status bar and click "add site" to make it able to install, and I would appreciate the problems it prevents (no more XXX Toolbar or Free Access Plugin trying to download!). But, having to about:config for it to add the site is very painful, and I know most newbies will just disable the system, along with myself, and anyone too lazy to about:config and do it.
UI is in different bugs, please comment there. Being able to launch XPIs direct from the net is a minor convenience only seeing as you can still download them and drop them onto the web browser to install (or use file|open). The potential for abuse is not theoretical, and I think this is absolutely the right thing to do. The world will not end if for one release you must manually install XPIs without web integration. It might get a lot worse if we do not react strongly and swiftly to those who would abuse our infrastructure like this.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040609 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2) Is the new code enabled here? I tried creating "xpinstall.whitelist.add" and adding "extensionsmirror.nl" to the default list mentioned in attachment 149726 [details] [diff] [review], but I can't generate an installation popup on that domain when installing extensions - I have to download them first and start the install from a local folder.
Do not change the default prefs file, you need to change your profile copy using about:config. Otherwise the empty string stored in your profile will continue to trump whatever changes you're making to the default file.
(In reply to comment #67) > Do not change the default prefs file, you need to change your profile copy using > about:config. Otherwise the empty string stored in your profile will continue to > trump whatever changes you're making to the default file. That was how I did it - I changed it using about:config and then added it to user.js, and it didn't seem to have any effect.
Oh, I was under the impression that it wouldn't even allow you to download the XPI unless it was whitelisted. In that case, I vote this bug should make it to 1.7 ASAP :)
Set xpinstall.whitelist.required to false for the 1.7 branch (reverts this change) If I change nsInstallTrigger::HandleContent() so it only casncels the request if XPInstall is really going to handle it then on non-whitelisted links the user gets the unknown-content handler. In some respects this is better: - much less mysterious, /something/ happens - matches what users of other browsers would see on the link - user can easily download, and then launch the install from the download manager - equivalent to executable install experience - users are a few clicks further from disaster. - More obvious to naive users that something unusual is going on (download dlg rather than a confirm prompt), while making it easier for Mozilla-savvy folks like those using this bug to get the stuff they want than the current do-nothing form of whitelisting. But, once we have an unobtrusive "an install attempt was blocked" indicator with a whitelist UI and possibly a restart for blocked installs then these dialogs might be just another way to annoy users. WIll have to think about it as we create the whitelisting UI
There is no point in trying to make XPI install any more 'safe' or more difficult than running an executable. It's just over-engineering. And sure, it should not be any easier either to prevent abuse. Why not consider XPI == executable and handle all files the same way (i.e. download dialog)? Associate XPI with Mozilla on all platforms so when the file is launched it starts the install process (as we see from clicking on a link). If users download and install an XPI the same way as an executable (download, launch file) then they will be just as careful as they would with an executable. Is there anything to be gained from special casing XPI installs?
(In reply to comment #70) > Set xpinstall.whitelist.required to false for the 1.7 branch (reverts this change) Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040610 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2) does not change its behavior on a known non-whitelisted site after I set that pref.
Can you get more specific about what doesn't work? In the test cases above the "ftp" link will not work with whitelisting on (netscape.com), does work if you set required to false. I've only tried the suite (trunk and branch) not Firefox, but it shouldn't matter for this feature. http: links should /always/ work if you type them by hand in the url bar, whether whitelisting is required or not (unless you've turned referrers off, in which case it'll work like ftp: links).
If this whitelisting is turned on and there is no UI for it, then it will effectively KILL my website (http://www.mozthemes.tk). I already had one user report that the install link doesn't work, and now I know why. I think that theme links like: InstallTrigger.installChrome(InstallTrigger.SKIN, fname, tname); should be allowed since it's only for themes. Otherwise I'll be getting about 50-75 emails a day with people asking "The install link doesn't work on your site -- how do I install your themes??" I am not looking forward to this.
Is there a particular reason why there is such a rush to get this bug fixed. Although I recognise that there is a hypothetical risk from dodgy plugins, I am unware of instances of people trying to cause harm by abusing the mozilla plugin system. Please enlighten me if such activity is actually taking place. If this is just a case of trying to shut the gates before the horse has bolted (a noble aim), I don't think that alienating users and developers with a rushed UI (or lack thereof) is justified. I know that 1.7 is supposed to be the next stable release and that in an ideal world this issue would be resolved now rather than later but by the same argument do you really want the latest stable release to scare off new users (and possibly some old ones) because they don't understand why they can't install the latest and greatest plugin. I should probably point out that I am in no way against the idea of plugin control, whether through whitelisting or signing or other methods. If it is possible to get this implemented properly now then that would be good, but it shouldn't be tagged on only half finished.
Please read the entire bug before commenting. The link in comment 11 documents why we're doing this: scumware attempts targetted at Mozilla users found in the wild. It's here.
I understand the need to whitelist xpi's but what about jar files? There's no code in jar files, just css, xml, and images....
(In reply to comment #77) > I understand the need to whitelist xpi's but what about jar files? There's no > code in jar files, just css, xml, and images.... I just filed bug 246375 "Themes should not be required to be whitelisted."
Never mind. TBP is the culprit - when links are forced into new tabs, the installation popups fail. When they are not, the installation popups appear. The new whitelist code works perfectly fine.
Addendum: XPI links with target=_blank, when suppressed and opened in new tabs by TBP, lose their installation popups. This is undoubtedly a bug in TBP.
Earlier we fixed bug 238684 which prevents launching an XPInstall during page load or in a timeout. That'll kick in if you try to open an install in a new window. Not that opening an install link in a new window makes much sense, you'll just get a blank window.
(In reply to comment #81) > Earlier we fixed bug 238684 which prevents launching an XPInstall during page > load or in a timeout. That'll kick in if you try to open an install in a new > window. Not that opening an install link in a new window makes much sense, > you'll just get a blank window. Right. What I was referring to was the way that sboulema's Extension Mirror links to the XPI files. Because the target=_blank attribute is specified in the XPI link, when clicking on the link it launches a new window and then shows the installation popup. When TBP is configured to force this new window into a new tab in the current window, the popup never appears, and only a blank tab is spawned.
I don't think this is not on the aviary branch yet, if it's not I want to release 0.9 first before adding it.
Whiteboard: needed-aviary1.0
(In reply to comment #0) > We want to initially be able to configure Firefox so that xpinstall attempts > from sites other than *.mozilla.org are blocked by default. This requires a > separate permission type for xpinstall requests. Forgive me for posting - I'm not a developer, but I've used Firefox daily since Phoenix 0.2, and I have an idea about this. It occurs to me that what we're really trying to address is the vast ocean of completely ignorant users out there who have been 'okey-doking' EULAs and install warnings since IE handed them the keys to internet security almost 10 years ago. "Signed code" just isn't cutting it. So, to that end, does anyone see any value in augmenting the whitelist idea with a dedicated "install mode"? I.e., when you want to install extensions, you have to manually turn on 'install mode' (which requires a manual (unscriptable) menu or button click). This causes the browser to completely restart with a specially themed (Red and yellow caution border?) browser window and appropriate instruction text that will only load special install pages on whitelisted install sites. When you are done installing and removing extensions, the browser closes and restarts in normal mode. This should prevent drive-by installs and reinforce in the user's mind that installing software is very specifically **NOT** something you do because some web site said it was a good idea. Also, if you can't figure out how to get into install mode, you probably shouldn't be installing extensions anyway. Just a thought. If you wanna talk about it, I'm at www.slashdot.org/~Asprin. Peace out, and keep up the good work.
I landed the patch that landed on the 1.7 branch (including the later checkin to disable whitelisting) on the aviary 1.0 branch, but I'm not sure if additional changes are needed to files that are forked.
Whiteboard: needed-aviary1.0 → needed-aviary1.0?
David, none of these files are forked. Ben is not going to activate this feature until he's got some UI for it (which would be forked).
David, browser-prefs.js is the Seamonkey-specific prefs file. Firefox uses /browser/app/profile/firefox.js. You might want to add the prefs "xpinstall.whitelist.add" and "xpinstall.blacklist.add" to firefox.js as well.
I'm currently writing an extension to add rudimentary UI for modifying the XPI whitelist preference in Firefox 0.9. When will the whitelist code appear on the Aviary branch?
So, if you allow *.mozilla.org, then you allow someone to post malicious extensions on bugzilla.mozilla.org in the form of attachments. I don't think we can control or properly police all of bugzilla.mozilla.org to prevent it being used as a way to subvert this whitelist. The same may be true of the mailing list archives on mail.mozilla.org. If we limit ourselves to update.mozilla.org, then we have to be careful to thoroughly review every extension posted to update.mozilla.org. It would be very unfortunate if update.mozilla.org happened to host malware because we (who is the extension sheriff?) was not able to keep up with all the extensions that are being updated for each release. In fact, I am willing to bet that no one has done a code review on each and every extension on update.mozilla.org. It's just not practical given our resources. As the number of contributed extensions grows, this problem will grow. Should the Mozilla Foundation have some sort of EULA to protect itself against malicious extensions hosted on update.mozilla.org? I agree whole-heartedly with Brodie's comments (comment #63 and comment #71). XPIs and EXEs should be treated equivalently (as much as possible). Moreover, whitelisting is not a scalable solution. What happens when some third party wishes to host Mozilla extensions? (see comment #74) Do they have to get mozilla.org to approve a {some-name}.mozilla.org DNS mapping? Or, do they have to hope that users will set some magic pref / hostperm.1 setting? Neither option sounds very good. Sucks to be you if you want to host Mozilla extensions. update.mozilla.org cannot be the only source of extensions or else the extension story is extremely limited. We are trying to build an extensible platform. I suspect that we'll hurt adoption if we require all extensions to come from update.mozilla.org. Also, it seems to me that if this whitelist prevents download of an XPI from triggering the install UI that we should at least show the user some informative prompt. Otherwise, the user is left thinking that the site or the browser is broken. That seems like a terrible user experience to me.
(In reply to comment #87) > David, browser-prefs.js is the Seamonkey-specific prefs file. Firefox uses > /browser/app/profile/firefox.js. You might want to add the prefs > "xpinstall.whitelist.add" and "xpinstall.blacklist.add" to firefox.js as well. I was just ensuring that everything that landed on the 1.7 branch was also on the aviary 1.0 branch. If additional work needs to be done to make the fix work, then somebody else needs to do that.
(In reply to comment #89) > I suspect that we'll hurt adoption if we require all extensions to > come from update.mozilla.org. I know none of you want to get into centralized management, but it looks like you already are. :) So, instead of trying to hardwire the browser to download extensions from just one site in the universe, why not make Firefox download THE WHITELIST from updates.mozilla.org and use that list to find authorized mirrors? Firefox could check for updates automatically at startup and download a new list when it is available. That would decentralize the downloads, but not the download authority. You could even have mozilla.org encrypt/cert-sign the whitelist to prevent tampering and authenticate it to the browser (to prevent against man-in-the-middle proxy and local DNS site misdirection attacks). This has the added bonus that it gives you a mechanism for REVOKING servers and extensions that lie and host malware anyway.
What if a cracker were to spoof update.mozilla.org? Any XPI install mechanism will not be secure enough without the use of digital signatures. Given that XPIs are as dangerous as EXEs, from a corporate user's perspective, IE seems to have a good model for installing ActiveX controls / extensions: In the IE world, ActiveX controls are digitally signed, with the added benefits that the publisher can be authenticated, the XPI can be checked for tampering and the installer gets proof of what was actually released by the publisher (i.e. non-repudiation). The browser can be configured to always trust a publisher like the Mozilla Foundation for a given purpose like installing software. This allows the installation to be performed without the need to get any input (e.g. their permission) from a user. This is absolutely _critical_ for large scale rollouts. IE can be configured to prevent ActiveX controls from being installed and executed and all these settings can also be 'locked down' by administrators to prevent 'normal' users from installing just anything. These settings are configured according to sites falling within 4 different 'zones' (intranet, trusted sites, internet and restricted sites), which AFAICS is more flexible than a single 'trusted sites' whitelist for installation purposes only. Whitelists may be a good first step. However, IMHO an even more important second step would be to introduce XPI digital signing and the ability to silently install XPIs from publishers who are 'trusted' to perform installs.
This is going far afield. Checking with the permission manager is an anti-annoyance/anti-abuse mechanism, not a substitute security mechanism. XPInstalls /can/ be digitally signed, and consumers should insist that they are. Unfortunately none that I know of are, in fact, signed. The Mozilla Foundation should set a good example by signing its own stuff. XPinstall will never support silent installs from the web. Even with a trusted provider there are lots of legitimate reasons not to want a particular thing installed at a time of the provider's choosing. XPInstall can be completely turned off if wished. The ability for administrators to "lock" prefs is a different discussion entirely. Netscape 4.x had this ability so it would surprise me if it isn't in there somewhere, but I have not had the chance to really examine the "CCK" tools. Off topic here though. There are several efforts to implement some kind of "zones" system for permissions in Mozilla (cookies, image loading, flash content, etc.). Since these all build on the permission manager used by XPinstall whitelisting the benefits will extend here as well. How do we get providers to start signing their installs? It's been suggested we simply block unsigned installs, but at this point that would effectively equate to turning off the feature which you can already do.
I hate to add to a closed bug, but Daniel added an intersting point about signing. What prevents a malware author from signing a malicious XPI? Does signing really increase security by any degree?
Signing is not a magic cure. Think of it like the plastic wrap on a bottle of Tylenol: if it's intact you can be pretty sure some sicko didn't poison it while is was sitting on the store shelf. The wrap does not, however, protect you from: - manufacturing malfuntion poisoning or weakening the pills - sabotage/intentional poisoning at the plant - counterfeit product (wrapper says "Tyleno1") Given that Mozilla Foundation releases are distributed over various mirrors it would be great if they were signed just in case someone hacks one or more of those mirrors. Signing does not help if someone is able to hack the Mozilla CVS repository. Signing does not help if someone manages to steal the cert. Signing does not help to the extent people would be willing to install things signed by "The Mozi11a Foundation". Signing doesn't help if hackers are distributing old releases with known exploits. If I get a Chatzilla or Venkman from hacksrus.com signed by Robert Ginda and the cert is issued by a reputable certificate authority I'm happy. If I'm on some random site and it wants to install something signed by "Bob" it might as well not be signed as far as I'm concerned. If people I trust tell me "Bob" is a good guy and his extensions is nifty then I'm glad it's signed.
In reply to comment #93: >This is going far afield. Checking with the permission manager is >an anti-annoyance/anti-abuse mechanism, not a substitute security >mechanism. I didn't claim it was. My point is I believe that whitelists in themselves do not go far enough to prevent abuse. >XPinstall will never support silent installs from the web. Even with a trusted >provider there are lots of legitimate reasons not to want a particular thing >installed at a time of the provider's choosing. That's not what I meant. The install should always be triggered / driven by the user agent. Consider that I wish to install Mozilla / Firefox to 2000 Windows desktops in my organisation and I also wish to install various extensions over the next few years. How can I acheive this automatically when XPInstall always requires interaction with a user? >The ability for administrators to "lock" prefs is a different discussion >entirely. Netscape 4.x had this ability so it would surprise me if it isn't in >there somewhere, but I have not had the chance to really examine the "CCK" >tools. Off topic here though. Agreed and my appologies. >There are several efforts to implement some kind of "zones" system for >permissions in Mozilla (cookies, image loading, flash content, etc.). Since >these all build on the permission manager used by XPinstall whitelisting the >benefits will extend here as well. Excellent! But will I be able to have a whitelist/blacklist per zone? In reply to comment #95: >Signing is not a magic cure. Think of it like the plastic wrap on a bottle of >Tylenol: if it's intact you can be pretty sure some sicko didn't poison it >while is was sitting on the store shelf. The wrap does not, however, protect >you from: > - manufacturing malfuntion poisoning or weakening the pills > - sabotage/intentional poisoning at the plant > - counterfeit product (wrapper says "Tyleno1") That's why signing should be coupled with trust for a particular purpose. Mozilla's security system already enables you to trust certificates for certain purposes, like identifying websites, identifying mail users and identifying software makers. I am arguing for this to be extended to include trusting a software maker not to manufacture poison. >Signing does not help if someone is able to hack the Mozilla CVS repository. I.e. "sabbotage". Presumably this would affect some people (nothing is infallible), but I would like to think it would get spotted pretty quickly and rectified. >Signing does not help if someone manages to steal the cert. That's where certificate revocation lists come in. >Signing does not help to the extent people would be willing to install things >signed by "The Mozi11a Foundation". Signing doesn't help if hackers are >distributing old releases with known exploits. I.e. "counterfeit". Arguably these are the users' lookout. You can never write code that protects from stupidity.
My question to signing the XPIs was how do we authenticate that the person who signed it is trust worthy? I mean, say it's a spambot that's inside the XPI. It'd be trivial for a spammer to spend a hundred dollars and buy a cert to sign the XPI with. Do we limit who can sign, or what?
Digital signatures are not the whole story. They enable you to be certain who a package came from and that the contents have not been tampered with by anyone else. It is up to you if you trust the package provider. To use an analogy, if I receive a package in the post with the seal intact that was registered as being sent from Al'Qaeda I choose not to open it.
Signing does not guarantee that anyone is trustworthy. At best signing tells you something calling itself "Bob's widget" really came from Bob. That is a very useful thing to know, but trustworthiness has to be established in the usual social ways (reviews, reputation, etc). > Consider that I wish to install Mozilla / Firefox to 2000 Windows desktops in > my organisation and I also wish to install various extensions over the next > few years. How can I acheive this automatically when XPInstall always > requires interaction with a user? How did you get 2000 copies of Firefox installed in the first place? Can't you use that mechanism for updates? How do you update other software on those 2000 machines?
>Signing does not guarantee that anyone is trustworthy. At best signing tells >you something calling itself "Bob's widget" really came from Bob. That is a >very useful thing to know, but trustworthiness has to be established in the >usual social ways (reviews, reputation, etc). I agree. We would like to configure Mozilla / Firefox to trust the contents of any XPI signed by our organisation. This is what we do currently for ActiveX / IE. >How did you get 2000 copies of Firefox installed in the first place? Can't you >use that mechanism for updates? How do you update other software on those 2000 >machines? We are not currently using Firefox - we are holding out for the 1.0 stable release. We roll out software using MS Software Management Server (SMS) currently, which requires us to use compatible installer technology. It is not a big deal for us to work around this and create a 'wrapper' installer in InstallShield that simply executes the Mozilla installer. The key is the installer has to be fully automatic (or even silent) and cannot ask the user for any input. The Mozilla installer can do this (you specify -s -a -s command line parameters for a silent install). Presumably the core XPIs get installed at this stage by the 'xpi stub' component? Whilst SMS is good for bulk, it is not without its issues. If a single user wants some certified software, they have to contact the support desk and there is up to a 2 hour delay before it reaches their PC. Ideally, I would like the ability to publish extensions that we have certified so users can install them on-demand, as they do with some of our ActiveX controls / apps today.
(In reply to comment #32) > Created an attachment (id=149726) > 1.7 branch patch to restrict XPInstalls to whitelisted sites if you set xpinstall.whitelist.enable.required to 'true', javascript calls to InstallTrigger.enabled() will return false. in the past, this function only returned false if 'Software Installation' was disabled. overloading error codes and return values only causes confusion for end-users and the developers trying to make their web-browsing experience as clear and intuitive as possible. InstallTrigger.enabled() should return true unless 'Software Installation' is disabled. if features - such as xpinstall whitelist - are added, clear and distinct functions should be added to determine if these 'features' are enabled or disabled. for me, overloading InstallTrigger.enabled()'s return code prevents me from properly determining what is preventing my ( legitimate ) plugin from being installed and working with the end-user to determine what is interfering with their ability to use my web-based application.
This was a conscious decision, it is no business of the web site whether the user doesn't want to install things in general or doesn't want to install things from them particularly. InstallTrigger.enabled() answers the question "can I (the site) launch an install?"; the answer is accurate.
This caused bug 257633, "Online installation of extensions fails when pref 'network.http.sendRefererHeader' has not the value 2".
Despite what I wrote in comment 102, the return value of enabled() no longer uses the whitelist value. It caused too many problems. (see bug 258798)
I never find this, adding keywords to summary
Summary: Make nsInstallTrigger::UpdateEnabled check with permission manager → Make nsInstallTrigger::UpdateEnabled check with permission manager (in effect block XPI installs from non-whitelisted sites)
Product: Core → Core Graveyard
See Also: → 257055
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: