Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

SHA256 checksum for Firefox downloads

  • 13 replies
  • 1 has this problem
  • 51 views
  • Last reply by linden1

more options

In order to mitigate supply chain attacks it would be useful to have a checksum published so that we can verify the file has downloaded appropriately. This should be included within the release notes.

In order to mitigate supply chain attacks it would be useful to have a checksum published so that we can verify the file has downloaded appropriately. This should be included within the release notes.

All Replies (13)

more options

There are many, many, many builds of Firefox. You can go to either of the following URLs to get the list. Whether there is an automated lookup, I don't know:

more options

Thanks those links are useful, not sure I understand why there are so many different places to download these builds from.

Interestingly, none of those links show a SHA256 that matches the file from the main website https://www.mozilla.org/en-US/firefox/all/#product-desktop-esr where downloading win64/en-US/Firefox Setup 78.8.0esr.exe version yields: 09103F716E60E98D9F444E0E93E37048D0BA1FC80B68EDA85A038CE65F2C348D

more options

I downloaded

https://download-installer.cdn.mozilla.net/pub/firefox/releases/78.8.0esr/win64/en-US/Firefox%20Setup%2078.8.0esr.exe

The provided SHA256 hash is:

cf9e4278d38dc7665c4877dedcd5eb869206619a8f7eebe7dece0a3eb490790e win64/en-US/Firefox Setup 78.8.0esr.exe

The SHA256 hash computed in Windows PowerShell using Get-FileHash is:

CF9E4278D38DC7665C4877DEDCD5EB869206619A8F7EEBE7DECE0A3EB490790E

How are you computing the hash?

more options

I have been getting the same results (using PowerShell > Get-FileHash), although that seems a circular logic.

I would like to download the file from the main website as I attribute a higher level of trust to that source (rightly or wrongly) as I expect there's a higher degree of scrutiny that is given to the build files that get loaded there as opposed to these other locations:

In the wake of the SolarWinds hack I think any discrepancy here should be explained. It could be that the main version has been compromised by a Nation State or vice versa.

more options

I downloaded from the main page (screenshot). I don't know why you didn't get the identical file.

more options

Strange, when I download from the main page (screenshot) on my work computer (via VPN) it downloads from:

But using the exact same link on my personal computer it downloads from:

What causes this discrepancy I have no idea.

more options

See also this older thread.

more options

Could this be because I'm actually running Firefox 86 when I download the ESR and you are running ESR? Still, that's strange.

more options

That is consistent with my results.

I note visiting https://cdn.stubdownloader.services.mozilla.com view source points as an S3 bucket: http://doc.s3.amazonaws.com/2006-03-01

Conspiracy theory: if I were a Nation State, I would attack the ESR source to point at this potentially vulnerable S3 bucket where I could plant a corrupted version of the ESR knowing that the less sophisticated enterprises will just download from there without checking the checksum and those enterprises would be less likely to detect any issues.

Change my mind.

more options

When I do a compare file compare between

https://download-installer.cdn.mozilla.net/pub/firefox/releases/78.8.0esr/win64/en-US/Firefox%20Setup%2078.8.0esr.exe

and

https://cdn.stubdownloader.services.mozilla.com/builds/firefox-esr-latest-ssl/en-US/win64/66a02f034d1b03f49af5be8e3329d1e943c821c856405aeefc200e7476643813/Firefox%20Setup%2078.8.0esr.exe

the latter has some non-null content in its __MOZCUSTOM__ section. I don't know exactly what it means, but it seems to decode to:

campaign=(not+set)&content=(not+set)&experiment=(not+set)&medium=(direct)&source=(other)&ua=firefox&variation=(not+set)

I think there must be different hashes for the files served from the stubdownloader CDN, but I ran out of time to look it up.

more options

Thanks, that's some real insight, which may mean we needn't ring the alarm bells. Although that doesn't answer the question why there are two different files being served up depending on what browser you run?

This seems fishy to me, while it doesn't appear to be serving up a malicious file now, it may have under different circumstances.

Per my older question, I've noticed this same issue for prior versions of Firefox ESR.

more options

It looks like the __MOZCUSTOM__ section was added by this bug, starting with Firefox 81 at the earliest:

https://bugzilla.mozilla.org/show_bug.cgi?id=1630809

It's not clear why this is only used when you are downloading with ESR, but since ESR is targeted toward enterprise deployments, it might be to make sure your download matches your existing (possibly custom) distribution??

more options

@jscher2000 I read through that thread, this seems like an incomplete feature. I would have thought a better way of implementing this functionality would be via a server side query similar to how the latest ESR version is requested.

Although the work around is relatively trivial, I don't think it's acceptable to have unsuspecting ESR users have their downloads of Firefox ESR hijacked with with this unverifiable version. I'm not sure what the path of escalation is here, but this seems like it would be a relatively simple server side fix.