Hacker News new | comments | ask | show | jobs | submit login

They should just stop publishing MD5SUMS for new releases. By now, everybody should have gotten the word that MD5 has been broken.

The security of the MD5 has been severely compromised, with its weaknesses having been exploited in the field, most infamously by the Flame malware in 2012. The CMU Software Engineering Institute considers MD5 essentially "cryptographically broken and unsuitable for further use". [1]

[1] https://en.wikipedia.org/wiki/MD5

You're conflating collision attacks like the Flame malware with a preimage attack that would be necessary to produce a malicious Ubuntu release with the same MD5SUM.

I.e. what's "broken" about MD5 is if you have a lot of CPU time and I allow you to give me two unrelated blobs, you can craft those blobs to have the same MD5 sum.

What's not "broken" (beyond a theoretical 2^123.4 attack) with MD5 and not broken at all for SHA1 is preimage attacks. E.g. if I work for Canonical, make an Ubuntu ISO and you have to produce a malicious ISO with the same MD5 sum.

We should be considerate of collision / preimage attacks, but please don't spread FUD by conflating the two. Publishing MD5 sums for ISOs is just fine.

What? Pretty sure you're wrong.

Yes, MD5 preimage resistance is not broken (to a reasonable degree).

If you have the Ubuntu 16.04 ISO (you do), and if you have its hash, the attack to craft a different ISO with the same hash is a collision attack.

A preimage attack is if you had some hash y where y=H(x) where x is some file/whatever, and trying to find out possible values of u that give rise to y when you do H(u), without the knowledge of x.

No. What you're describing is just a subset of preimage attacks.

Not having knowledge of x is just one type of preimage attack, a "preimage resistance". You can also know x, then it's a "second-preimage resistance".[1]

Which is not the same as a collision attack. Where you're trying to find x and y such that h(x) = h(y) without anyone specifying x or y in advance.

By definition a collision attack is an attack where you specifically craft both x and y such that they exploit weaknesses in the algorithm.

It's not enough to know an arbitrary x or y that someone else has made, because that value isn't going to be exploiting the weakness.

1. https://en.wikipedia.org/wiki/Preimage_attack

yeah, you're right. my bad.

(how many sites on the internet have a discussion where people are both patient and civil with each other, and the discussion results in mutual understanding?)

Hmm, I personally haven't seen action in discussion where this kinda stuff doesn't happen; maybe I just pick the comments I reply well.

You should think about this in terms of collision resistance. Canonical doesn't write most of the packages that go into a release.

How deterministic is the build process for an entire distro like this? And wouldn't updating just a single letter in a README just before release thwart the efforts of an external attacker?

Collision attacks matter if you don't (want to) trust the Ubuntu release team.

If you don't trust the Ubuntu release team, why are you downloading Ubuntu to begin with? Your threat model makes no sense.

It is not trust in Canonical itself that is the problem, but the constant threat of coercion it puts on both the organization and the people that compromise it. This is why I work on generalized multi-signature schemes and deterministic builds.


I've always wondered this but felt too embarrassed to ask, screw it. Let's say the ubuntu 16 iso is infected with some kind of malware by a 3rd party. If they have control of the file, would they not have control of the checksum displayed on the site? I can understand if the checksum is spread to other sites for cross-reference but I'm having trouble seeing why a checksum from the same location as the file you're downloading is worth anything.

Any insight?

If you have an existing Ubuntu system you trust, you can verify the authenticity of this release via:

  $ gpg --no-default-keyring --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --verify SHA256SUMS{.gpg,}
  gpg: Signature made Thu 21 Apr 2016 10:40:38 UTC using DSA key ID FBB75451
  gpg: Good signature from "Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>"
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the owner.
  Primary key fingerprint: C598 6B4F 1257 FFA8 6632  CBA7 4618 1433 FBB7 5451
  gpg: Signature made Thu 21 Apr 2016 10:40:38 UTC using RSA key ID EFE21092
  gpg: Good signature from "Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>"
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the owner.
  Primary key fingerprint: 8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092

  $ sha256sum --ignore-missing -c SHA256SUMS
  ubuntu-16.04-desktop-amd64.iso: OK
(You can ignore the `WARNING`s above, since you're explicitly telling `gpg` to use a keyring you trust)

I see. I'll do that from now on, that's pretty reassuring.

They GPG-sign the cryptographic checksums, see the .gpg files. If you don't verify the GPG sig, with Canonical's signing key obtained out of band, the checksum by itself is pretty useless as you describe.

PS. anyone know of a CLI download tool that supports this format of GPG signatures?

edit: why the downvotes for the parent? it's a fine question

`gpg` is a command line tool for verifying these signatures and it is what `apt-key verify` uses in it's backend. you can download the signatures with `curl` or `wget`

It doesn't protect against a malware being included by default, it protects against a malware being inserted on the wire, ie between Canonical's HDD and your HDD; if a malware is inserted at this point then the checksum should fail.

Coincidentally it requires the checksum to be propagated through an other, more secure mean, so distributing the checksum on the very same site increases the chance for an attacker to act, however there is no other way as widespread as this to give the checksum anyway.

If they infect at the source, yes. But if just one mirror is infected, or one of the CDN servers, the attacker may not be able to change the checksum on the official site.

Ah - that makes sense. I knew their had to be an easy answer but I couldn't see it.


It's worth it for error-checking.

the checksums are gpg signed.

They do provide SHA256SUMS. I guess MD5SUMS are there for legacy purposes. It is on users to stop using MD5SUMS and move to SHA256SUMS

i thought the use of md5 here was just to check that your download wasn't damaged, by comparing your hash to theirs.

The purpose of publishing a public MD5 sum of a software release from the developer is to prevent tampering with an image. If I download an ISO of Ubuntu and check the MD5 value, and it doesn't match what Canonical says it should, then it's been tampered with.

I'd argue that there aren't any good reasons to use MD5 over sha256 today, but either way -- the plain checksums are mostly useful to make sure that iso's etc downloaded without error. The chance of a bad network connection or other random problem leaving you with an ISO and matching md5 in case of some random download error are extremely slim.

For verifying downloads, you should be using the gpg signatures. And again, I don't think there's much of a reason to provide both signatures and plain hashes today, but: you might be in a jurisdiction where gpg is illegal (but then, you wouldn't be allowed to use Ubuntu anyway), or you might be bootstrapping from a system without gpg installed (eg: vanilla windows), but with sha256 installed, and a set of trusted CA-certs, so that you feel you can trust the downloaded hash. I'd argue it's probably a false sense of security -- in general the gpg-signatures (or more precisely the secret keys behind those signatures) -- should be easier to secure, and easier to tie to the trust-worthiness of the builds, than some random web server not being compromised. Or, put another way, in a scenario where the gpg signing key is compromised, it seems likely an attacker would also be able to to other stuff, like embed a back door etc. While there are many, many ways a mirror might be compromised, or TLS subverted.

That's not to say that gpg is perfect, I just think verifying the gpg signatures get you closer to verifying what you (probably) care about: that you indeed have an install iso that is made in good faith by the Ubuntu release team, and to the best of their knowledge is ok.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact