[Project_owners] Secure Updates for Firefox 3

Scott sgrayban at gmail.com
Wed Jul 18 11:03:42 PDT 2007

Douglas E. Warner wrote:
> On Wednesday 18 July 2007, Scott wrote:
>>> (not speaking from experience here)
>>> I think the problem is that Firefox does not enforce code signing
>>> certificates; it only checks them if they're presented.
>>> This means that the certificates only purpose is to verify that *this
>>> extension* came from *this person/group* - it doesn't verify that it was
>>> tampered with during the download, or that the file that was originally
>>> selected to be downloaded was the intended one.
>> I don't think that this is correct. Looking at how the XPI get's signed
>> the file * META-INF/manifest.mf * holds all the checksums.
> [snip]
>> This clearly shows that the XPI and the files can not be altered without
>> having to re-sign the XPI all over again.
>> The file * META-INF/zigbert.sf * also holds the same information.
>> I don't think it is possible to tamper with the XPI file without
>> completely breaking the update because on my tests here Firefox refused
>> to install the XPI because the checksums didn't match when it was signed.
> You're correct; signing the extension prevents tampering within that file, but 
> it doesn't prevent someone from completely replacing the XPI with something 
> else.
> Without some external way to verify that the extension you downloaded is the 
> same one you intended to download, the signing just verifies that it was 
> tampered with (either on the server or mid-stream).
So how will signing just the updates.rdf be a better way then?

Let's just assume that at some point a hacker figures out a way to
bypass that little bit of info, which is entirely possible, and sends an
botnet addon in its place?

I just do not see how just signing the RDF will make anything *safer*.
If you want real security then I would implement signing both files.
That would guarantee that everything is coming from the right place and

- Scott

More information about the Project_owners mailing list