How to authenticate a startup disk image?

Question

The process of creating a startup disk on Ubuntu looks really vulny to me. It's scary in a number of ways. Please either (1) refute my assertions with contrary evidence or (2) tell me how to avoid these pitfalls (hopefully without giving up on Ubuntu as a quasisecure OS).

First of all, here's what I tried to do:

1. Write an Ubuntu ISO (hash authenticated) through Pen Drive Linux on Windows, to a USB stick, resulting in a bootable image.

2. Install the resulting boot image on Computer A.

3. Write the same ISO to another USB stick on another machine using Startup Disk Creator from within an existing different Ubuntu context.

4. Install the resulting boot image on Computer B.

5. Use Startup Disk Creator on Computer A to make a new bootable USB stick using the original ISO above, resulting in Image A.

6. Use Startup Disk Creator on Computer B to make a new bootable USB stick using the same ISO, resulting in Image B.

7. Compare Image A and Image B. In other words, if I start with 2 different ways of creating a boot image, do their children boot images then match up, if in fact I use only Startup Disk Creator and not Pen Drive Linux on the second round?

Here's what I learned, in no particular order:

1. Startup Disk Creator has an "Erase Disk" button, but it doesn't seem to work because it seems to preserve the file system type. Is it really erasing the boot sector (not to mention the partition table), or just leaving the latest boot virus there, ready to infect the newly minted startup disk when it's used for installation? Yeah, we can use the Disk Utility to format media, but it would be nice if Startup Disk Creator told me that it wasn't actually initializing anything in a manner suitable for secure boot. (EFI boot might partially mitigate this threat, but probably wouldn't eliminate it.)

2. We have various pages on ubuntu.com which provide various hashes for the ISO. But this irrelevant, because ultimately, we all want an authenticated boot image, not an authenticated compressed file which eventually evolves into the aforesaid boot image (after passing through an infected machine etc. etc.).

3. We have md5sum.txt in the boot image. MD5 has been deprecated for years as a secure hash. Not to mention that a virus could easily modify this file, so it can't replace the necessity for file hashes which are downloadable from https://ubuntu.com/i-dont-know-where, not unlike http(not s!)://releases.ubuntu.com/14.04/SHA256SUMS. Yeah sure, it's great for protecting against accidental errors, but that doesn't address security.

4. ldlinux.sys is not even mentioned in md5sum.txt. It's the only file which differs between Image A and Image B (again, even though everything came from the same ISO). I don't even have a checksum for this file, let alone a secure hash. For all I know, Computer A and Computer B are both infected, but with different viruses that infect this file differently.

Here's what I want to know how to do:

1. A way to authenticate the child image (online, not via local means that might have become infected).

2. Some sort of standard that ensures that Startup Disk Creator and Pen Drive Linux and Whatever Random Boot Maker can adhere to, so that anyone can easily inspect the resulting startup disk and say "this was signed by Ubuntu" or at least "these hashes look the same as the ones I see on https://ubuntu.com/hashes".

3. If nothing else, then the SHA256 and correct size of ldlinux.sys for various Ubuntu versions.

4. Yeah I can compile it all myself, but there's no reason to believe that viruses would not infect source code as well as binary code. Same authentication problem.

Answer 1

ldlinux.sys is for booting Linux from MSDOS formatted floppy disks. Modern Ubuntu images (like 14.04) do not use ldlinux.sys. Instead they use isolinux.bin which is part of the El Torito Boot image of the ubuntu.iso. To dump the El Torito header do:

$  xorriso -indev ubuntu-14.04-desktop-amd64.iso -toc
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 507 nodes read in 1 seconds
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev 'ubuntu-14.04-desktop-amd64.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Media summary: 1 session, 493568 data blocks,  964m data, 11.2g free
Volume id    : 'Ubuntu 14.04 LTS amd64'
Drive current: -indev 'ubuntu-14.04-desktop-amd64.iso'
Drive type   : vendor 'YOYODYNE' product 'WARP DRIVE' revision 'FX01'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media blocks : 493568 readable , 5895012 writable , 6388580 overall
Boot record  : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Boot catalog : '/isolinux/boot.cat'
Boot image   : '/isolinux/isolinux.bin' , boot_info_table=on
Boot image   : '/boot/grub/efi.img' , platform_id=0xEF 
TOC layout   : Idx ,  sbsector ,       Size , Volume Id
ISO session  :   1 ,         0 ,    493568s , Ubuntu 14.04 LTS amd64
Media summary: 1 session, 493568 data blocks,  964m data, 11.2g free
Media nwa    : 493568s

If you modify any of this boot structure, the checksum (SHA256) of the ubuntu.iso would be different. You can get the SHA256SUMS, SHA256SUMS.gpg, and the ubuntu.iso from releases.ubuntu.com. You can verify a USB flash image on a USB drive by using dd to write the image, and then reading it back and comparing it to the original:

# checksum downloaded image (check this matches the published hash)
$ sha256sum ubuntu-14.04-desktop-amd64.iso
cab6b0458601520242eb0337ccc9797bf20ad08bf5b23926f354198928191da5  ubuntu-14.04-desktop-amd64.iso

# write image to USB flash
$ dd if=ubuntu-14.04-desktop-amd64.iso of=/dev/sdb

# read image from USB flash and checksum it
$ /bin/ls -l ubuntu-14.04-desktop-amd64.iso
-rw-r--r-- 1 user user 1010827264 Apr 17 10:51 ubuntu-14.04-desktop-amd64.iso
$ dd if=/dev/sdb bs=512 count=1974272 | sha256sum
1974272+0 records in
1974272+0 records out
cab6b0458601520242eb0337ccc9797bf20ad08bf5b23926f354198928191da5  -
1010827264 bytes (1.0 GB) copied, 34.1066 s, 29.6 MB/s

dd makes an exact binary copy, so you can easily compare original image to the image on the drive. You will need to specify an exact length to read back from the USB drive, otherwise the checksum will be different.

If you use a different tool (not dd) to write to the USB drive, then it might write different binary data, and you will need to generate your own checksum by writing using your tool, and then reading the drive with dd. If you do not trust a single PC, but trust several, then you will have to recreate your image on several PCs, and ensure the image generates the same checksum on all.

---

If you assume that the computer that you use to download the image and write the USB has been compromised, then you can never trust anything that it does. It could report that the checksum was fine, and that the image had not been tampered with - but you could never trust it, because it had already been compromised. Researchers have managed to develop systems that can infect EFI firmware, and thus survive a full format wipe of the hard drive, and at the same time report that Secure Boot is enabled and working fine, even though the system has been entirely subverted. Once a system has been compromised, you can never fully ensure that it has been cleaned. Hence why the NSA has a program in place to redirect, intercept and compromise target systems whilst still in the hands of a courier, before being delivered to the customer.