+++ This bug was initially created as a clone of Bug #401292 +++ XPInstall attempts to restrict the set of certificates trusted for the update server to certificates that chain to certs in our root program. However, at least in theory, the user could have a set of certificates in his certificate database that our certificate path building logic would always use over the certs in the built-in roots module. For example, the user could have installed a different version of the root certificate (e.g. one with a SHA256 signature instead of a SHA1 signature, as StartCom provides on its website) in his certificate database. And/or, the user may run into a situation in which the expected root certificate is cross-signed by a root that isn't in the root module. Either of these scenerios would result in a false positive identification of the attack that we are trying to prevent, and unnecessarily prevent update checking. I don't know if either of these scenerios is actually possible with the CA that is currently used on these servers; it is possible that the current CA doesn't have alternative versions of its root certificate that would cause these problems to happen. With libpkix, we could restrict the set of certificates considered as trust anchors at the time the certificate is built. Doing this would ensure that any path returned would chain to a root in our builtin root module, avoiding these issues.
Component: Installer: XPInstall Engine → Application Update
Product: Core → Toolkit
QA Contact: xpi-engine → application.update
Does this need to be security sensitive? This situation would just stop a user receiving add-on updates, wouldn't allow any other server to provide them. Presumably this would be fixed by switching to cert attribute checking a la bug 643461
Component: Application Update → Add-ons Manager
QA Contact: application.update → add-ons.manager
I haven't looked into the details to see if it is just Add-ons updating or whether Firefox updating is also affected. I marked it as security-sensitive because it might be possible for a site to purposely create this situation (by having its intermediate certs stuffed into the cert cache and/or by having the user add a security exception for a different version of a root certificate) so that updates would stop working.
XPInstall is the old code for installing and updating add-ons, application updates never used it.
I admit I don't know a lot about this part of the application so I don't know what is disused. There are two instances of the check that I found: mozapps/shared/CertUtils.jsm:137 xpinstall/src/nsXPInstallManager.cpp:1111
(In reply to comment #4) > I admit I don't know a lot about this part of the application so I don't know > what is disused. There are two instances of the check that I found: > > mozapps/shared/CertUtils.jsm:137 This is used by add-on update and install, the blocklist request and application update > xpinstall/src/nsXPInstallManager.cpp:1111 This is no longer used, I really need to remember to take the time to remove it all soon.
If an attacker can get a user to install a different root cert (which would be non-builtin) then the user has problems that go beyond not getting updates. Otherwise the best an attacker could do would be to confuse us about the intermediate chain, but the install cert is either going to validate or not validate just the same. Improving the current cert check hack with libpkix would be a great idea, but doesn't need to be security sensitive.
You need to log in before you can comment on or make changes to this bug.