SHA256 checksum for Firefox downloads
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.
Todas las respuestas (13)
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:
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
I downloaded
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?
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:
- http://releases.mozilla.org/pub/firefox/releases/78.8.0esr/ - not HTTPS
- https://ftp.mozilla.org/pub/firefox/releases/78.8.0esr/
- https://download.mozilla.org/?product=firefox-esr-latest&os=win64&lang=en-US
- https://archive.mozilla.org/pub/firefox/releases/78.8.0esr/
- https://download-installer.cdn.mozilla.net/pub/firefox/releases/78.8.0esr/
- http://download-origin.cdn.mozilla.net/pub/firefox/releases/78.8.0esr/
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.
I downloaded from the main page (screenshot). I don't know why you didn't get the identical file.
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.
See also this older thread.
- [/questions/1321281] Checksum for Firefox ESR 78.6.1 - Software Supply Chain Security
Could this be because I'm actually running Firefox 86 when I download the ESR and you are running ESR? Still, that's strange.
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.
When I do a compare file compare between
and
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.
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.
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??
@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.