Is verifying ISOs downloaded from the official website worthwhile?

Question

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?

Answer 1

Yes it's worthwhile.

It takes only seconds to sha256sum/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 sha256sum 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 sha256sum 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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

Media Checks

Modern releases (20.04 and later) automatically scan. I for sure let that scan occur (on the first boot of the day; I tend to skip it if rebooted in the same box on the same day).

If you don't want to check beforehand, you can switch to a terminal (post-install) and always do a

dmesg |grep squashfs

and look for errors. A standard install should find only the copyright messages when dmesg is scanned; if any other lines appear with squashfs I'd read them as the install is likely not trustworthy.

If using an older release (pre-20.04), I'll always also do a manual CD integrity check, primarily as the write to USB-media I've found the most troublesome (I have 10+ failures per year, even if that's a smallish percentage of writes; it's still significant).

Ubuntu 23.04 Desktop

The way you verify actually varies on release, with a Ubuntu 23.04 Desktop system I'll use the following

sudo journalctl |grep casper-md5check

And what I look for is

May 11 08:37:42 ubuntu casper-md5check[3924]: Checking ./casper/install-sources.yaml..../casper/install-sources.yaml: OK
May 11 08:37:42 ubuntu casper-md5check[3924]: Checking ./casper/vmlinuz..../casper/vmlinuz: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Checking ./casper/initrd......./casper/initrd: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Checking ./boot/memtest86+x64.bin..../boot/memtest86+x64.bin: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Checking ./boot/grub/grub.cfg..../boot/grub/grub.cfg: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Checking ./boot/grub/loopback.cfg...../boot/grub/loopback.cfg: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Check finished: no errors found.
May 11 08:37:47 ubuntu systemd[1]: Finished casper-md5check.service - casper-md5check Verify Live ISO checksums.

Where the key message I look (& wait for; ie. I may need to run this command a few times as the process will continue to run as a background task) is

Check finished: no errors found.

ISO image Validation

As for ISO image validation pre-write, or How to verify your Ubuntu download, I download using zsync and it checks the integrity of the ISO image at the conclusion of download; I tend to trust that, and just do the self-scan on boot.

If I download via a torrent, I tend to do a quick sha256sum check against the checksum file I downloaded using wget on a different device. I tend to perform this check on ISO image files downloaded previously anyway.

Why do it?

The checks take seconds to maybe a minute. If you have a single bit wrong, the debugging the installation or corrupted data could take hours if you're lucky, but more likely days-weeks-months.

There are generally at least one bug report filed per day (on launchpad; I monitor via #ubuntu-bugs-announce), reported by users who've been having problems with they consider a bug that would have been prevented by these checks. The bug reports are just marked INVALID and given a quick paste with a couple of lines from their dmesg output). So I see on a very regular basis users wasting hours trying to repeat processes that will never work (often over days), because they skipped these checks and thus are starting with corrupted media where problems should be expected.

I see it as a very cheap insurance.

Answer 6

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.

Answer 7

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.

Answer 8

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