37

I downloaded the ISO from https://www.ubuntu.com/download, selecting the default "Ubuntu Desktop" option.

The website links the page https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu which gives instructions how to verify ubuntu.

This seems pretty tedious, and I am wondering how realistic it is that there is a problem with ISO downloaded from the official website. I note that the process of verification itself requires me to download software that is new to me, thus introducing another attack vector on me even as I am closing another one.

For what it's worth, I am planning to use Live USB only and not to fully install Ubuntu. Does that make a difference?

| improve this question | |
  • 8
    My political answer is "YES DO IT". I've never done it except maybe once on the first download many moons ago. I'm always downloading and evaluating software or patches/bug fixes and just can't be bothered with the extra steps. Plus my systems are all non-production and if they go "poof" tomorrow I would just shrug and move on. – WinEunuuchs2Unix Jan 8 '18 at 5:07
  • 14
    Torrent is an alternative, if you don't want to check the md5sum. When you get a file via torrent, it will be checked automatically :-) It is often faster to use the torrent method (compared to ordinary downloads), but some internet service providers block it because they think that it is only used for illegal purposes. – sudodus Jan 8 '18 at 6:09
  • 2
    The primary use of MD5 checksums over large files is to ensure the integrity of the downloaded file (e.g. to detect if transfer cancelled prematurely), not to mitigate the chance of MITM attacks. – rexkogitans Jan 8 '18 at 12:31
  • 1
    @rackandboneman No, that's not the underlying question at all. – David Richerby Jan 8 '18 at 12:31
  • 16
    Fun fact: you'll probably spend more time asking this question than computing checksums in your whole life. – el.pescado Jan 8 '18 at 12:58
58

Yes it's worthwhile.

It takes only seconds to md5sum/etc a downloaded ISO, and it provides reassurance you weren't attacked by MITM etc. Beyond that, those seconds are insurance for the [hours of] time wasted if you had a few bit errors and debugging necessary chasing errors no-one else gets because of your download (eg. you have network issues & so try to debug; but networking is stuffed because that's what the few bits wrong were...) Think of checksum-checks as very cheap insurance.

The software needed to md5sum something will be from another source usually (an older version, even different os/distro on occasion), is very small and is already present for many/most of us.

Further it allows me to download from a local mirror, but because I grab the md5sum from the Canonical source; I've insurance that the mirror didn't play with it. Again very cheap insurance that costs me ~3secs of time.

| improve this answer | |
  • 12
    However, if the download used the HTTPS transfer method, then all the integrity checks have took place already. – Nayuki Jan 8 '18 at 5:07
  • 15
    @Nayuki these integrity checks would be worthless if the file is somehow damaged on the server (disk/FS-driver failure, bad mirroring etc.). – Ruslan Jan 8 '18 at 9:14
  • 6
    @Nayuki Just because you are accessing a web site over HTTPS doesn't mean the entire link from your PC to the storage holding the file you're downloading is end to end encrypted. See the Google data center interlinks debacle some years ago. – user Jan 8 '18 at 14:07
  • 31
    If someone has MITM'd the ISO, whose to say they didn't MITM the checksum when you viewed it on the website? (If you're using a mirror, it's useful.) It's not too rare to see the checksum and download served from the same entity. – Lan Jan 8 '18 at 15:18
  • 14
    NEVER make the assumption that a checksum will detect MitM. The given checksums could be fake too. The proper way is to verify the signature, but that requires GPG (I've only done this once and it's a pain to do). – Micheal Johnson Jan 9 '18 at 14:27
21

Yes, it is VERY RECOMMENDED that you verify the image you downloaded, here are some reasons:

  • Just takes a few seconds and can tell you if the integrity of the file is correct, I mean, the file is not corrupted. (A common cause of corruption is a transfer error because of technical reasons such as a flaky internet connection from @sudodus comment.)
  • If the file is corrupted and you burn this ISO image into a CD/USB drive, and it won't work, or during an installation could fail, this results in a waste of time and CDs.
  • You are sure that you're using the official CLEAN version of any kind of ISO image or software and not a modified version (maybe by attackers), see this report: Watch Dogs pirates hit by scurvy Bitcoin-mining malware

If you already have a GNU Linux distro, you can use md5sum, if you're in Windows you can use: WinMD5Free.

Hope it helps.

| improve this answer | |
  • 3
    For windows you can use the built-in certutil: superuser.com/a/898377/521689 – Kanchu Jan 8 '18 at 8:56
  • 1
    I also answered, but I'm upvoting your answer because I feel it answers the question well too and it is useful to more readers since it does not go into too technical details like the other answers. – bitoolean Jan 8 '18 at 15:49
  • @sudodus Networks have their own integrity checks. While it's not impossible for errors to get past them (TCP just uses a simple checksum, which won't detect word swaps, but most links use CRC), it's not something one generally worries about. – Barmar Jan 8 '18 at 18:40
  • If an attacker is able to corrupt a file, changing the value in an MD5 box should be within reach too, though. – Pascal Engeler Jan 8 '18 at 23:28
2

Yes it is, but Ubuntu seems to make it harder than it should be.

In the best case you would just download foo.iso and foo.iso.sig and click the .sig file (or use gpg on the shell on the .sig file) after you imported the key one time. This costs a few seconds.

Ubuntu seems to make it more complicated by forcing you to check the sha256 sums from a file while only the file itself is signed. That's convenient for them, but more work for their users.

On the other hand, when the file was generated just by sha256sum * >SHA256SUMS, you can check it using sha256 -c and get OK/Bad/Not-Found as output.

| improve this answer | |
2

Check your /proc/net/dev and see how many bad TCP frames you have received so far. If you see a single-digit value (hopefully a zero), read on. If you have lots or network errors, then by all means use MD5 to verify your downloads (though I would rather investigate the root cause, since unreliable network means you can't trust anything you receive via HTTP).

When you're downloading over TCP which checksums all transmitted data, there's very little chance of having a corrupt download with exactly the same size. If you're confident you're downloading from the official site (you normally are if you're using HTTPS and the certificate check passes), verifying that your download is complete is normally enough. Decent web browsers usually do the check for you anyway, saying something along the lines of "download failed" if they don't get the amount of data they expect, though I have seen browsers which just decide to keep the incomplete file without saying anything to the user, in which case you could check the file size manually.

Of course, verifying a checksum still has its value, covering you in cases where the file you're downloading is corrupt on the server, but that doesn't happen too often. Still, if you're going to use your download for something important, that's a step worth taking.

As @sudodus said in the comments, using Bittorrent instead of HTTPS is another option, since torrent clients do a much better job when dealing with incomplete/corrupt data as web browsers do.

Note that checksums don't really prevent you from being attacked, that's what HTTPS is for.

| improve this answer | |
  • 5
    The TCP checksum isn't big enough for something as large as an ISO file. It's only 16 bits; on a noisy link, there's a good chance that some corruption got through. – Mark Jan 8 '18 at 23:46
  • 1
    @Mark for a large ISO, there will be many TCP checksums: one for each individual TCP segment required to transmit the data. – Anthony Geoghegan Jan 9 '18 at 22:39
  • 3
    @AnthonyGeoghegan, exactly. Each segment has an independent chance to be corrupted, and given how many segments are involved in an ISO file, there's a pretty good chance that one of them will be corrupted in a way that still matches that segment's checksum. – Mark Jan 9 '18 at 22:43
  • 1
    @Mark can you check your /proc/net/dev and tell how many bad TCP frames you have received? My computer got 0, with an uptime of 140 days. If I'm not mistaken, certified Gigabit Ethernet equipment provides bit error rate of 10^-10 or better. Of course, it all depends on what you call a "good chance"... – Dmitry Grigoryev Jan 10 '18 at 9:59
  • 1
    @Mark What kind of layer 2 are you using that doesn't have a CRC or similar? With ethernet you get CRC checks and the TCP checksum. Haven't done the math for that one, but I can't see how you arrive at "pretty good chances" there. – Voo Jan 10 '18 at 10:08
0

I found out the hard way about not check summing. I would burn a CD with an ISO that got corrupted during a download, and could not get it to boot or it had errors when running.

Like the others said, it takes little time.

| improve this answer | |
  • The worst thing about that experience is if you burn the ISO again, you get the same error on the CD – thomasrutter Jan 8 '18 at 3:47
  • 1
    That why I use RW CDs and DVDs. :-) – fixit7 Jan 8 '18 at 5:01
  • 7
    I've never written any CD/DVD for more than a decade. Not worth the time to write and cost to buy when there are tons of cheap pendrives – phuclv Jan 8 '18 at 5:43
0

You are seeing it with only one use case, in a set up with mass automation it helps to have it verified; scripts that run the check , before proceeding with what ever we need to do with the image

| improve this answer | |
0

The others have given answers with technical details that I forgot although I'm a programmer (my work doesn't involve communication over networks), so I'm just going to let you know a personal experience.

A long time ago, when I used to burn CDs frequently, it once happened to me to have downloaded this linux distribution ISO which appeared to have downloaded correctly. The CD failed me, so I checked the downloaded file and it did not match. So, I downloaded again and it worked. So, this only happened once in 15 years since I've been an advanced computer user and programming (have been using computers since the age of 11, 19 years ago, and I've burnt more than a thousand discs). But it is proof that it can happen.

It also happened to me through BitTorrent once or twice, so that is not fail-safe either. When forcing recheck of the downloaded file, it identified the corrupt piece.

My conclusion is HTTP (relying on TCP) may be as safe as it gets, but the Internet means there are intermediary nodes between your device and the server, and there is no telling what can happen on the way (packets are even lost all the time), and sometimes computers can't tell that the data is wrong I guess.

No one can answer whether it would be worth the trouble for you - it depends on context and I'm sure you can judge that for yourself. For me, it's not worth it most of the time. If I was going to install an OS though, I would check the downloaded image before.

Note: the fact that I only once or twice noticed a corrupt download doesn't mean that it only happened then. Maybe other times it doesn't get in the way so you don't notice.

EDIT: I even had other more experienced programmers at work argue (with quite some indignation even) that these data integrity verification hashes make it possible to know whether a file is bit-identical to the original, but I know (I have read) that the fact that two files result in the same hash does not mean that they are identical - it just means it is extremely unlikely they are different. The way they are useful is that when files are not identical, and especially when they are very different, their resulting hash codes will practically never be the same (it is even less likely this test would fail). In less words - if hash codes are different, you know the files are different.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.