Closed Bug 238960 Opened 17 years ago Closed 5 months ago
Require XPIs to be signed
Doug T suggested requiring XPIs to be signed. I don't think this is a good idea, but I've tried to present a balanced argument below. Requiring XPIs to be signed... * would *not* protect against installs by malicious sites. Evidence: ActiveX spyware is signed and very common. * would protect against spoofed installs, slightly. For example, suppose a router between you and mozilla.org is compromised. Without signing required, the spoofer can make mozilla.org appear to point to an unsigned critical-update XPI. With signing required, the malicious XPI has to say "Signed by [someone other than the Mozilla Foundation]", which might make users more suspicious than seeing "Unsigned". (Of course, the spoofer doesn't have to use XPI. He could make mozilla.org point to a .exe for download or make mozilla.org give the user instructions that lead to a compromise instead.) * would make life harder for theme and extension authors. * would bring Mozilla in line with IE, for better or worse.
- Most people think that "signed" means "secure", which is fatally wrong. (This notion of "signed" = "secure" is forwarded by the language of a lot of corporate propaganda, e.g. TPM.) So, I think that signing might actually make matters worse for the people we try to protect here (I assume this suggestion is because of bug 238684.) > * would make life harder for theme and extension authors. - It would make life unbearably hard for extension authors. Such a certificate is quite expensive (I think you need a special software author cert?). If all of mozdev shares one, it would lessen the security and force people to use mozdev. It would still be an annoyance, and a hidden pref would be demanded to disable it, and then other authors would ask users to do that, because they can't / don't want to sign, and we're back at square one or worse.
I don't think the problem with the ActiveX dialog is that it contains the word "signed". I think the problem is that it's dominated by security imagery (lock and key) and phrases like "Publisher authenticity verified by VeriSign [incomprehensible jargon]" rather than concentrating on the fact that a site is asking for permission to install and run unsandboxed software on your computer. (It also has an extremely vague warning and labels the Install button "Yes".) Btw, if users think "Signed by foo" implies "safe", I'd expect malicious sites to sign XPIs even when it's optional. Ben Bucksch, are you arguing for removing the signing capability from XPI altogether?
> Ben Bucksch, are you arguing for removing > the signing capability from XPI altogether? No. But as-is, I think it's only really useful for advanced users. Maybe we could remove the newbie confusion, if we removed the word "signed" and just said "Do you fully trust <source>?", where source is either the cert owner (if correctly signed) or the hostname (if not signed). (There are may be schemes thinkable where it's more useful for newbies, e.g. Mozilla being CA and actually checking trustworthyness of signers, not just the name, but I'm not sure that's feasible and I guess it's offtopic here.)
On ben's points: A) a signed install is much more secure in the sense that you proof of who the author or distributor is. I am not going to play any sementic games without regarding the term "secure". B) mozilla.org, mozdev.org, or other organization can verify the claim that some set of bits are a "trusted" extensions to the product and sign the install. Our experiences with security dialogs is that the user just clicks through. So, assume that any scary dialog will just be viewed as cruft in the way of what the user already had determined she/he wants to do. Doug
One serious flaw of the current signed-XPI implementation is that there is no way to view the certificate details. Even knowing what CA would be a help. Signing is a good feature, but it was not an accident that when we reimplemented Netscape 4.x's SmartUpdate as XPInstall we dropped the signing requirement. How many SmartUpdate .jar's did anyone ever see? Granted, a large part of .xpi popularity has to do with how much easier it is to create something useful and interesting for Mozilla than Communicator, but that's not all of it.
Assignee: security-bugs → dveditz+bmo
I wouldn't mind changing the confirmation dialog to make unsigned packages look scarier, but this one is WONTFIX
Status: NEW → RESOLVED
Closed: 17 years ago
Component: Security: General → Installer: XPInstall Engine
Resolution: --- → WONTFIX
I think the intention was that the cert info wasn't going to be looked at by the typical user. Also, it was a hope that we wouldn't just drop every wanna-to-ba ca into mozilla's ca list.
I read the commenst against signing on this bug, and I think they are fighting a strawman when they say signing is no good WRT what can be done to make signed xpi work well. - XPI *needs* security - white-listing has a number of problems regarding scaling, and in order to both really control the site in the list, but not close the xpi door to outside parties. - Signing can be a solution to this problems, but it requires to implements a number of things to avoid the problem current code signing implementation have. Namely : = Strictly control the CA that can sign XPI archive. Maybe configure the install so that only one Mozilla controlled CA can sign them. Not allow user to add a CA to this list through ordinary preferences. = Offer certs for free. If the CA that can emit them is Mozilla controlled, this is no problem. For free doesn't mean instantly, and a framework where the requester must first say who he is, what the extension he develops is, and show the extension at least partially exists could be a solution (specific bug entry in Mozilla ?). Before that stage, developer would have a method to allow their install to load unsigned XPI (Codebase Principals) = Have revocation and make sure revocation is disseminated. How ? Have the CRL manager be preconfigured to update the Mozilla CA CRL. Make it available for update through a single click on the main page of Mozilla-user popular sites (mozilla.org, mozillazine, etc...). Block XPI install if there's not a reasonnably up-to-date CRL available (with an 'explanation'/'link to crl' pop-up). I'm not completely sure about that point, but a central place for XPI signing, developer only owning a authentication that enables them to send their code for automated signing, coud be worth the hassle. It would enable to insert a secure time-stamp in the signature (useful to allow XPI to be still valid after cert expiration), and it would make sure that all signed xpi can be reviewed, so that it's a lot harder to create an evil XPI that is not noticed and whose signing cert is never revoked.
I would add that the attitude of avoiding security measures because they make more work for the developer is what got IE into its present situation.
Reopening for further discussion. If we did this it would have to be in such a way that we don't kill off the explosion of creativity and goodwill in the extension community. Perhaps a hidden setting, like codebase principals for signed scripts, which would let developers create and share unsigned installs. The cost of a cert is no roadblock to folks installing keyloggers and sending your bank password off to Russia; it's an insurmountable barrier to many broke college students who otherwise have the time and energy to create something cool.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
XPI signing is a nice thing indeed. Hey, I even made a few hundred, if not a thousand XPI's by now, but you need better documentation to start with. Also, signing XPI's is just one thing, but what about all security patches that go into the mozilla source code, but are left alone by most extension developers? Note that I have to do a lot of hunting to get to this kind of information, and that doesn't help people like me..
Is there a specification for signed XPI files? If so, please cite the URL. It is often said that XPI files are JAR files, but with respect to signed XPI files, as presently implemented in mozilla, there are a number of subtle but (possibly) important differences from signed JAR files. If we were to seriously consider requiring signed XPI files, I think we ought to explicitly address some of these issues/questions. A mozilla specification for signed XPI files might be the place to do it. Alternatively, we might want to reconsider the differences between signed XPI and JAR files. Either way, I think this bug is the right place to raise these issues and questions. Various versions of Sun's Jar file specification may be found at http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Signed%20JAR%20File http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Signed%20JAR%20File The JAR file specification allows multiple signatures. It allows signatures to sign mere subsets of the JAR file. It allows parts of the JAR to be separately signed. Any given file in the JAR may be signed zero, one, or more times in a JAR file. Multiple signatures were intended to allow a single JAR file to contain signed Java classes from multiple sources, each signed by their creator, and a signed Java applet that uses those classes, signed by its creator, without requiring the applet's creator to sign the other creators' classes. Each signature is effectively represented by two files, the .sf file (which specifies the subset of the manifest that is signed by a particular signature, and hashes of those files), and the .rsa (or .dsa) file that contains the actual signature of the info (including the hashes) in the corresponding .sf file. IIRC, it is possible to combine the contents of two signed JAR files into a single JAR file containing two signatures, in which some files are signed with one signature, some files are signed with the other signature, some files are signed with both signatures, and some files are unsigned. This can be done without re-signing any of the files, and without a special signature tool (ordinary text editor and zip tools suffice). IINM, mozilla's present implementation of signatures on XPI files requires that a .rsa file (or .dsa file, the file containing an actual signature) come first. It seems to decide whether the JAR file is signed (or not) based on its processing of that first signature file. This has some implications and raises some questions. Here are some of the questions. a) Does it require that ALL the JAR's files be signed by that one signature? b) Does it permit (and verify) multiple signatures, with no one signature signing all files? c) Does it detect the presence of files that are not signed by any signature? d) Does it install unsigned files from a JAR in which some files are signed? I'd guess that the present implementation only verifies one signature. If that is so, then I'd *HOPE* that it checks that all files in the JAR are indeed signed by that signature. If mozilla some day requires signatures on XPI files, then I'd ask: Does mozilla *intend* to require that all files in the JAR be signed with a single signature? And if so, will this intent be enforced?
With UMO pumping out so many extensions each day, it would be good to know that the mirror network that we use is trusted. We have about 1300 authors with accounts (500 extensions). That's a lot of certificates. I think we can all acknowledge that people tend to just click-through. I do like what Microsoft does in these situations, both for drivers and for installers. This could be further restricted to "only trust MyCompany.com as a signer" which would be good for corporations. http://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html
*** Bug 265358 has been marked as a duplicate of this bug. ***
If signing did something more than just verify identity, this might be worthwhile. As it stands, if I sign an XPI, install it, modify the XPI, restart Firefox, the XPI still works fine. So the core purpose of signing (avoiding tampering) doesn't work on Firefox.
(In reply to Michael Kaply (mkaply) from comment #15) > If signing did something more than just verify identity, this might be > worthwhile. > > As it stands, if I sign an XPI, install it, modify the XPI, restart Firefox, > the XPI still works fine. > > So the core purpose of signing (avoiding tampering) doesn't work on Firefox. The core purpose of signing is to verify the author of the XPI. The only way it could also avoid tampering is if we did exactly what this bug suggests and only installed add-ons signed by valid certs.
But what about tampering after the install? Since in most case with Firefox 4 and beyond, the XPI is still intact, should Firefox recheck to make sure the XPI is still valid? I thought tampering was one of the purposes of signing as well, otherwise why does the signing depend on the structure of the XPI?
> But what about tampering after the install? That was never the purpose. The purpose is to protect the user from malware and outright security attacks that modify binaries between their author and the time of installation. You are trying to protect against users or programs running on the user's machine and who have the ability to modify the binaries. Such attempts are bound to fail, as they can always modify Firefox protection code (or cert database), too. In fact, exactly that is happening in practice. With current Windows/Mac/Linux, it is *impossible* to protect against other applications on the same machine. It's useless to even try, and we won't.
(In reply to Michael Kaply (mkaply) from comment #17) > But what about tampering after the install? Since in most case with Firefox > 4 and beyond, the XPI is still intact, should Firefox recheck to make sure > the XPI is still valid? We've talked about doing this, it's possible even if the XPI is unpacked. I'm not really sure of the point though. If something has managed to modify the files on your machine then you're in trouble that we can't do much about already. > I thought tampering was one of the purposes of signing as well, otherwise > why does the signing depend on the structure of the XPI? The entire contents of the XPI is signed so that we can say for sure that it hasn't been modified since the author signed it and therefore the XPI was totally created by the author. But signing an XPI doesn't stop people from tampering with it since I can easily take a signed XPI, remove the signature and tamper with it to my hearts content. What I cannot do is make that XPI still appear to be signed by the original author.
Yeah, I'm not even thinking. A malicious app could simply unzip the XPI, remove all the signing information and rezip and Firefox would be none the wiser. Going back to the original subject of this bug, requiring signing and obtaining certs for all add-on developers would certainly be an undue hardship. Google solves this problem by signing everything on the store end and by requiring developers to pay $5 to sign up to participate in the store, verifying the identity.
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: parity-ie security → [parity-IE]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Status: REOPENED → RESOLVED
Closed: 17 years ago → 5 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.