Open Bug 1531165 Opened 1 year ago Updated 1 year ago

Firefox windows builds are authenticode signed with SHA-1 hashes

Categories

(Release Engineering :: Release Automation: Signing, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: dveditz, Assigned: catlee)

Details

Attachments

(4 files)

In bug 1079859 we switched Firefox to use a SHA-2 --certificate-- for authenticode signing, but apparently are still using sha-1 digests in the authenticode signature itself.

This was reported by Jeremy Barton in mozilla.dev.security:
https://groups.google.com/forum/#!topic/mozilla.dev.security/2b-V9XsnfeM

Our timestamp countersignatures are also whack. Fixing both should be simple argument changes to our Firefox signing script. We will need to figure out the URL for sha-2 timestamping from our CA

https://blog.didierstevens.com/2015/11/24/authenticode-and-timestamping-and-sha256/

IIRC this was done intentionally at the time to allow Windows Vista users to be able to validate the new certificates:

https://support.globalsign.com/customer/portal/articles/2169296-windows-code-signing-hash-algorithm-support

We no longer support Vista on any of our active branches, so this should be a safe change to make.

https://www.digicert.com/code-signing/signcode-signtool-command-line.htm describes how to use a different/more recent timestamp server.

Looks like this is supported with osslsigncode with the /ts option.

I successfully signed the Windows 32-bit 65.0.2 stub installer with the dummy certs, using a sha256 digest and a different timestamping service.

https://drive.google.com/open?id=1_O5herJljMHtT6r_VoCCYl0U-djJhWkV

Dan, can you verify that the signature is good (aside from the fact that I'm using a self-signed cert to do the signing)?

Flags: needinfo?(dveditz)

Yes, both the signature and the timestamp signature are using sha256 (the certificate does as well, but we had that right before). Looks great.

Flags: needinfo?(dveditz)
Assignee: nobody → catlee

Deployed to try/autoland.

According to https://docs.microsoft.com/en-us/security-updates/securityadvisories/2014/2949927, Win7 without SP1 does not have support for verifying SHA2 digests. We still officially support all versions of Win7.

I'll see if we can verify if the new files are verifiable with vanilla Win7.

If it helps, Microsoft stopped supporting Windows 7 (without SP1) back in 2013 (https://support.microsoft.com/en-us/lifecycle/search?alpha=%5C%22windows%207%5C%22).

Anyone in that configuration hasn't gotten security patches in coming up on 6 years.

Windows 10 Pro:

Windows 2012 pgo

  • digicert sha2 ok

  • countersingature missing (expected for autoland)

  • setup starts & installs

  • installed firefox starts

    Windows 2012 x64 pgo

  • digicert sha2 ok

  • countersingature missing (expected for autoland)

  • setup starts & installs

  • installed firefox starts

Windows 8.1 x64

Windows 2012 x64 pgo

  • digicert sha2 ok
  • countersingature missing (expected for autoland)
  • setup starts & installs
  • installed firefox starts

Windows 2012 pgo

  • digicert sha2 ok
  • countersingature missing (expected for autoland)
  • setup starts & installs
  • installed firefox starts

Windows 10 Home Arm64 (lenovo yoga):

  • digicert sha2 ok
  • countersingature missing (expected for autoland)
  • firefox installer for aarch 64 completes successfully, but firefox is not installed - i'm guessing the aarch setup is @ fault

Windows 7 Pro sp1 x32:

Windows 2012 pgo

  • digicert sha2 ok
  • countersingature missing (expected for autoland)
  • setup starts & installs
  • installed firefox starts

The above was tested using: https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=sign&revision=781fba7bac687ef83bc40bfa4f8e7f7800eaff27&selectedJob=234092826

For Windows 7 before Sp1, that's still uncertain if we can find any image to verify the sha2 behavior. I am curious though if there are any users actually using Windows 7 <sp1.

Additionally to the above I did a comparison test using the stubs installer for Nightly:

  1. official nightly stub installer: https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/Firefox%20Installer.en-US.exe
  2. stub installer signed by :catlee

Environments: Windows 10 x64, Windows 7 SP1 32b, Windows 7 Vanilla (before SP1), Windows 8.1 x64
The behavior of sha1 and sha2 stubs are the same:

Windows 7, Windows 7 sp1, Windows 8.1, Windows 10

  • "Open File security" warning
  • UAC gets triggered after the security file warning

**default UAC settings

Is this only about main binaries? We no longer "supports" running installer (and show a mesage suggesting update) on older systems?
https://searchfox.org/mozilla-central/source/browser/locales/en-US/installer/custom.properties#51

(In reply to Masatoshi Kimura [:emk] from comment #14)

Is this only about main binaries? We no longer "supports" running installer (and show a mesage suggesting update) on older systems?
https://searchfox.org/mozilla-central/source/browser/locales/en-US/installer/custom.properties#51

:emk, could you please elaborate on the above, not sure what that actually means?

Flags: needinfo?(VYV03354)

Currently, if users run the installer on Windows Vista or earlier, it will display a message explaining about minimum operating system requirements. If we sign with installers with SHA-2 signature, it will no longer run at all on Windows Vista or earlier. It may confuse users because no messages will be shown. Is it OK?

Flags: needinfo?(VYV03354)

(In reply to Masatoshi Kimura [:emk] from comment #16)

Currently, if users run the installer on Windows Vista or earlier, it will display a message explaining about minimum operating system requirements. If we sign with installers with SHA-2 signature, it will no longer run at all on Windows Vista or earlier. It may confuse users because no messages will be shown. Is it OK?

Will it be impossible to run, or will the user be presented with a warning that the signature cannot be verified?

It will not run at all. No messages will be shown.

The tools & puppet changes have been deployed. These introduce a new signing format 'sha2signcode-v2', which will sign with the new timestamp service and uses sha2 digests. We can land that change on nightly when we decide we want to switch formats.

We still see significant installs on Win7 SP0 per https://sql.telemetry.mozilla.org/queries/62194/source#159844 so this is probably something to treat with caution to avoid impacting overall installs and MAU negatively.
Jim, catlee and adrian tested that SHA2 downloads work fine on Win7 SP0 despite Microsoft docs that seem to tell us SHA2 support started only with SP1. They consider testing on Nightly and beta to measure impact on download/install ratio in order to validate the theory though do you know the best way to measure download/install ratio? Is that Google analytics download events VS stub install numbers or do we have anything better?

Flags: needinfo?(jimthomas)

Thanks for the heads up. I think GA download to Stub install numbers is still the best way, although Justin did just work through this again for one of our download experiments so he can help confirm.

Flags: needinfo?(jimthomas) → needinfo?(hoosteeno)

The two ways we've done this are with a funnelcake (since we can track download clicks and later look at distributions) and attribution (since we can track download clicks and later look at attribution environment). I don't have any reason to prefer one over the other; both have some hard biases. Attribution is ongoing, so it may be easier to use as a spot check. I would not trust Nightly/Beta to give us a good model of Release for install rates.

Flags: needinfo?(hoosteeno)
You need to log in before you can comment on or make changes to this bug.