8

I very rarely see websites provide a SHA-2 hash that's signed to ensure file integrity for the user downloaded side file, and show that the file has not been manipulated or out right replaced with a malicious version, such as the incident that occured with CCleaner last year. The only recent ones I've seen provided are Jetbrains products and KeePass, and you had to scroll pretty far to find it tucked under the page.

Edit: Like the Certificate Authority, can we not have a Hash Authority which signs the hash that the company provides for their product so the issue of a server takeover would be mitigated dramatically?

  • 3
    Maybe because 'the mass' don't care at all about that, and it results that companies dont want to bother doing so... – DevMoutarde May 21 '18 at 12:46
  • I get you... but look, do you think your grand ma or even your mother, or your little brother, would care about making sure the release is the same as the original one ? certainly not :( That said, it would be a good idea to do that to make people aware of these risks, yes – DevMoutarde May 21 '18 at 12:58

5 Answers5

3

You mention CCleaner, so it is relevant to link to Would a digital signature have prevented the CCleaner compromise? The short answer is that it would not have prevented this particular compromise.

This gives us our first problem with providing hashes: Who are we trusting to sign the build, and what are we trusting them to check? Does the signature simply represent the official build server, which could be compromised? Or does it represent an actual security audit by some pre-trusted party?

However, there are other attacks that such a hash would guard against - for instance, a compromised or fraudulent mirror offering a tampered build. In this case, it would be enough for the primary project page to publish a hash, which could be verified against the download offered by any mirror.

However, this leads us to the second problem, which is one of the hard problems of cryptography: key distribution (or, in this case, signature distribution).

For an unsigned hash, you are simply trusting the page that displays that hash not to have been tampered with. A signed hash at first sight seems better, but you still have to download the public key from somewhere, so you are still trusting the source of that key. If an attacker can direct a user to a fake download page, they can add a link to a public key of their choosing, and the user will get a false sense of security by verifying the hash of a compromised download.

The alternative is to have some central authority that you trust for multiple different applications - this is the principle behind Windows driver signing, Linux package managers, and phone app stores (and also behind the certificates used for HTTPS websites). Now you have a new problem: why do you trust those central authorities? Are they directly auditing the source code and build processes of the files you're downloading? Or are they delegating the trust, via a counter-signed certificate, based on some assurance from the party actually producing the software? Plus, you still need to acquire the root public key somehow - presumably it was included in some trusted installation media when you installed the OS / app store / package manager.

In the end, publishing a hash will be most useful for large projects, where:

  • the same user is likely to download and verify multiple versions, or different applications, with the same public key;
  • and, the source of the public key is likely to be different from the server offering the download (a different server, or some physical medium)

But even then, it cannot fix all exploits, as CCleaner demonstrated; and there is a danger in giving users a false sense of security.

IMSoP
  • 3,790
  • 1
  • 15
  • 19
2

Because most users won't check the hash anyway.

It would take a common download protocol that automates and enforces signature verification for this to actually make a dent in malware spread.

That still wouldn't be perfect - a hacked server could also post a different hash. Signing the software itself, as with Windows drivers, probably has more potential for making an impact. Both could be done as well.

Therac
  • 2,610
  • 11
  • 18
  • We could. But when you have a solid and agreed-upon CA (the main issue with PKI), it's more straightforward to sign the software file itself, rather than its separately posted hash. – Therac May 21 '18 at 13:07
  • We should be using a common protocol in which sites provide a separate hash to their software for validation. Security Professionals need to stop blaming people for poor security when it within out power to implement changes that impact them positively without them noticing. – Shane Andrie May 21 '18 at 16:18
  • I agree. I just think signing the software itself would be an even more effective step, but it has obvious limitations too. – Therac May 21 '18 at 17:06
  • 1
    I would have thought the distinction between "signing a hash" and "signing the software itself" is a bit of an arbitrary one: don't most algorithms for signing a large piece of data start by hashing it, and then signing that hash? – IMSoP May 21 '18 at 17:28
  • The hash is signed either way; the difference is that embedding the signature in the software keeps verification independent of the download source. I.e. it will work even if the software comes from a thumbdrive, gets DL'ed by an outdated browser, etc. Changing one OS function in a way that's been done seems more straightforward than blocking each individual point of entry. – Therac May 21 '18 at 17:50
  • So if I follow right, what you're actually saying is that it's easier to add an automatic protocol on *execution*, than on *download*? That's not really to do with *how the signature is delivered*; it being bundled in the same file is just part of that protocol. Nor is it what protects against a hacked server posting a different hash - that's about having a known set of public keys to trust. What both have in common is that they need a central authority (e.g. Microsoft) managing and enforcing the protocol. – IMSoP May 21 '18 at 20:44
  • The check on execution is basically already there. It's easier to *enforce* than to block every possible way to get malware on the machine at all. And shares the same problems (PKI). – Therac May 21 '18 at 21:05
  • Well, the check is already there because someone added it, so that seems a bit circular. It is, however, a convenient bottleneck in the flowchart where you can add a check. Other OSes have other bottlenecks, e.g. mobile OSes with app stores can simply enforce that only the app store can install new software, then place the real enforcement in the app store upload infrastructure. "Where should it be enforced" is an interesting question, but not one your answer really seems to capture. – IMSoP May 22 '18 at 08:27
2

I am seeing more hash (commonly md5) being shown on site related to linux. Mainly, when iso are provided.

You don't want to install an OS from a corrupted ISO, do you ?

You'll find the hash also of the Windows 10 ISO too, on the download page.

The hash is used here only to check the integrety of the downloaded file(s).

When you need to check that the file has not been tampered with, serious site, provide a GPG key signature that you need to check with a GPG key. For example, tails.boum.org does that.

solsTiCe
  • 231
  • 2
  • 10
2

They do! Many Windows executables have a built-in certificate signed by a CA trusted by Microsoft. The operating system checks this certificate before running the software. Additional configuration can be made to prevent unsigned software from running, rather than just showing a warning. Furthermore, it is possible to create even further restrictions that only allow Microsoft-signed executables to run, not just executables that are signed by a Microsoft-trusted publisher.

Linux and related operating systems do not support this yet (ELF, unlike PE32, does not support embedded certificates), but there is very little push to do so because most software installations are done using its native package manager which usually does verify the software. In this case, there is no certificate from a trusted CA. Rather, the signature is provided by the maintainers of the software repository and verified by the package manager at during installation.

For security-sensitive downloads that are necessarily not provided by package managers and cannot have embedded signatures, signed hashes are often provided. This is the case with bootable ISO images in particular, though some only provide unsigned hashes, not signed ones. Unfortunately, there are still numerous examples of executables provided over insecure connections that are unsigned simply because the website administrators do not understand the importance of integrity and underestimate the risk of compromise.

forest
  • 65,613
  • 20
  • 208
  • 262
  • @Azxdreuwa No. As other answers have discussed at length, an admin posting a hash on their home page provides very little security. All the examples in this answer require *a central authority*, and a process for that central authority to vet the things they're signing (or the certificates they're countersigning); failing to create or belong to such an authority is not "incompetence". – IMSoP May 22 '18 at 16:11
  • @Azxdreuwa But in the absence of a central hashing authority, a self-signed hash proves no such thing. In most cases, any party able to replace the download would also be able to replace that hash, or the public key, with whatever they wanted, and most users would never know the difference. And, as I pointed out in my answer, *even a trusted hash wouldn't have solved the CCleaner incident anyway*. – IMSoP May 22 '18 at 16:57
  • @Azxdreuwa Yes, Microsoft are acting as the central hashing authority for certain types of software; as are Google, for Android apps; such hashes are, by definition, not "self-signed". The problem is that the majority of the admins you are branding as "incompetent" have no such authority they can get to sign their releases, or countersign their certificates, so just posting a random hash on their homepage gives a completely false sense of security. – IMSoP May 22 '18 at 17:00
  • 3
    @Azxdreuwa I think you have the cart before the horse: the problem with introducing a counter-signature on hashes is not "admins can't be bothered to hash code", it's "there isn't anybody set up to do the counter-signing". Saying people should put up self-signed hashes in the hope that some authority will come and counter-sign them is like saying that people should print their own passports at home, in the hope that their government will come along later and stamp them as official. Trust is not something that can be automated away - you've got to have some process for who you trust and why. – IMSoP May 22 '18 at 17:09
  • 1
    @Azxdreuwa As one final thought, these articles about Extended Validation website certificates are a great example of why the hard part of being a central authority is not doing the signing, but deciding what you should and shouldn't sign: https://scotthelme.co.uk/are-ev-certificates-worth-the-paper-theyre-written-on/ https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/ – IMSoP May 22 '18 at 17:28
-2

Because it's almost pointless form a security perspective. Hashes next to downloads are a one-stop-shop for compromises; the attacker updates the hash in the exact same place as the download is linked. The download need not even be replaced, it can be linked to a third party site since the user-facing html is what's under attack.

It's some comfort if a 3rd-party site hosts the hash, but it's been a long time since I've seen that implemented and even then, it just means two sites need compromised instead of one. If the hash is next to the file in an FTP folder, how hard is it to replace both, considering they have the same perms? Unless one is a hardened target off-site, what's to make it any safer than just the link-offering page/folder?

The idea of validating download hashes is good, it's just not easy to get the hash to the user in a manner any more trusted than the link itself. They are still good for integrity, just not authentication on a single-authority basis. A central authority would be nice, but afaik, there's not one yet.

dandavis
  • 2,693
  • 10
  • 16
  • OP explicitly mentioned _signed_ hashes, not plain hashes. – forest May 22 '18 at 04:19
  • @forest: given the title and edit-added info, it's not entirely clear what is meant by that, without an example of such a download page. My point is that without a central authority, hashes and even signatures are only as trustworthy as the origin. that's an important consideration and if it cost me a few -2s to get that out there, so be it. – dandavis May 22 '18 at 05:09
  • The original post (pre-edit) contained `a SHA-2 hash that's signed`. – forest May 22 '18 at 05:10