526431 - Signing process should use SHA-1 or better digital signature (stop using MD5 RSA)

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Reed Loden [:reed]]

We received a mail to security@m.o from the File Reputation Service team at F-Secure today. The main issue mentioned in the e-mail is as follows:

------------------------
As we are continuously improving our products and services, we noticed some
Firefox binaries signed with a rather weak digital signature (MD5 RSA) while
we were processing files to be white-listed. Since the MD5 RSA digital
signature can be easily compromised, we would strongly recommend to increase
the strength of the digital signature, such as SHA1 RSA.
------------------------

Couple of thoughts:
* Would like to know how hard it would be to change the algorithm in use. If somebody can point me to the code that does this, I can take a look for myself...
* Would this also require a new signing certificate (depending on how the private key was generated and other various factors)?
* Any idea on how long would it take to get this fixed (so I can offer some type of ETA to F-Secure)?

Comment 1

[Reed Loden [:reed]]

Doing some research under http://mxr.mozilla.org/build-central/source/tools/release/signing/, it looks like we're still using `signcode` for signing? Is that correct? If we want to stay with signcode, I believe we'll need to add "-a sha1" to the options specified in signfile() [http://mxr.mozilla.org/build-central/source/tools/release/signing/sign-release.py#10].

However, MSFT has deprecated Signcode.exe (only available in .NET Framework 1.0 and 1.1) and now only supplies SignTool.exe in later .NET Framework releases, so it may be in our best interest to look into swapping to the newer tool.

Comment 2

[Reed Loden [:reed]]

Attachment: possible patch for signcode impl - v1

Comment 3

[Reed Loden [:reed]]

Expanding on one of my questions from comment #0, I would like to know exactly how the private key was generated. Besides the private key, is anything else generated/created on Mozilla's end before the certificate request is made? When getting an SSL certificate, one has to create a CSR (Certificate Signing Request). I'm unsure of the process for requesting a code signing certificate, so I don't know what exactly has to be done on the requester's end besides (obviously) creating the private key.

Comment 4

[Reed Loden [:reed]]

(In reply to comment #3)
> Expanding on one of my questions from comment #0, I would like to know exactly
> how the private key was generated.

Hmm, Comodo's site actually uses the browser's <keygen> method. VeriSign's site seems to use a similar process, so maybe the private key is generated on the fly during the registration process? That just seems weird to me, but maybe so...

Comment 5

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Can you find out which version of Firefox they were looking at? 

We just renewed signing keys&certs on Friday, so if they are looking at FF3.5.4, they are looking at the old cert&key. If they are looking at FF3.5.5 binaries, those are signed with the new cert&key.

Comment 6

[Reed Loden [:reed]]

(In reply to comment #5)
> Can you find out which version of Firefox they were looking at? 
> 
> We just renewed signing keys&certs on Friday, so if they are looking at
> FF3.5.4, they are looking at the old cert&key. If they are looking at FF3.5.5
> binaries, those are signed with the new cert&key.

Sorry, I should have been more clear. From reading the code in sign-release.py, it's obvious that we're using MD5 as our hashing algorithm (Signcode.exe defaults to MD5 unless SHA-1 is explicitly requested, as per http://msdn.microsoft.com/en-us/library/9sh96ycy%28VS.80,lightweight%29.aspx), so that's definitely a problem. This is what F-Secure has specifically reported to us.

However, I, personally, want to make sure we don't have MD5 or some other deprecated algorithm lurking elsewhere, which is why I'm requesting information on the certificate and private key themselves. Does that make better sense?

I can ask F-Secure what binaries they used if you really want, but I don't think it really matters as to what they actually reported.

Comment 7

[Lucas Adamski [:ladamski]]

Even though we should fix this, marking sg:nse as I believe an actual exploit would require a second preimage attack.  So far everything thrown against MD5 has been just a collision attack AFAIK.

Comment 8

[Daniel Veditz [:dveditz]]

Forgot to comment yesterday. Both our old and new signing certificates use 2048-bit keys and are signed by the CA using SHA1. That isn't the problem here, Reed is right that the problem is _our_ use of weak md5 hashes when signing the executable.

STR:
1. in windows explorer right-click on a signed Firefox installer or firefox.exe
2. select properties
3. select the "Digital Signatures" tab
4. select the "Mozilla Corporation" line and click Details
5. View the "Advanced" tab

Expected: strong digest algorithm such as sha1
Actual: "Digest algorithm: md5"

6. Back on the "general" tab click the "View Certificate" button
7. select the "Details" tab
8. Check the "Signature algorithm" line
    Actual: "sha1RSA" -- this is good.
9. Check the "public key"
    Actual: "RSA (2048 Bits)" -- this is good

We do not need a new certificate, we just need to fix our own signing process.

I agree with Lucas that this is not an immediate threat. But it's good hygiene and appears to be a simple parameter change to our signing tool so it shouldn't be unreasonable to try to fix before the next round of releases (e.g. 3.5.6).

Comment 9

[Reed Loden [:reed]]

Comment on attachment 410177 [details] [diff] [review]
possible patch for signcode impl - v1

No idea who to request review from on this, so tagging a few people. First to get to it wins. :)

Comment 10

[Chris Cooper [:coop] (he/him)]

Reed: I should be able to test your patch tomorrow AM.

Comment 11

[Chris Cooper [:coop] (he/him)]

Comment on attachment 410177 [details] [diff] [review]
possible patch for signcode impl - v1

http://hg.mozilla.org/build/tools/rev/0b149c0ad18d

Comment 12

[Chris Cooper [:coop] (he/him)]

I followed Dan's steps above and verified that the signed builds show sha1 as the digest algorithm. 

The next round of releases will be signed this way.

Comment 13

[Chris Cooper [:coop] (he/him)]

Reed: not sure if you still want the blocking flags here or not. I don't think this is something we wouldn't want, and it's not really something we want or need to toggle per branch IMO. Up to you, though.

Comment 14

[Reed Loden [:reed]]

(In reply to comment #13)
> Reed: not sure if you still want the blocking flags here or not. I don't think
> this is something we wouldn't want, and it's not really something we want or
> need to toggle per branch IMO. Up to you, though.

What does that mean exactly with regards to branch builds? All builds from this point forward (including older branches) will be signed using SHA-1 as the digest algorithm? That's what I hope you mean, but just double-checking.

Comment 15

[Chris Cooper [:coop] (he/him)]

(In reply to comment #14)
> What does that mean exactly with regards to branch builds? All builds from this
> point forward (including older branches) will be signed using SHA-1 as the
> digest algorithm? That's what I hope you mean, but just double-checking.

Yes, that is what I mean.

Comment 16

[Chris Cooper [:coop] (he/him)]

And to make sure we cover Fx3.0.x and Tb2.0.0.x:

Checking in sign-release.pl;
/mofo/release/signing/tools/sign-release.pl,v  <--  sign-release.pl
new revision: 1.35; previous revision: 1.34
done

Comment 17

[Reed Loden [:reed]]

(In reply to comment #15)
> Yes, that is what I mean.

Ok, I'll follow-up with F-Secure to let them know. Thanks for the review.

Dan, when do you want to open this bug? Could do it now, or should we wait until after the next set of releases?