Closed Bug 240552 Opened 16 years ago Closed 16 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)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugs, Assigned: dveditz)

References

Details

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

Attachments

(4 files)

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: 16 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
You need to log in before you can comment on or make changes to this bug.