From what I understood, it's the torrent link that downloads a compromised zip file rather then the authentic image:

"Torrent downloads over at https://xubuntu.org/download/ are serving a zip file with a suspicious exe and a tos.txt inside. The TOS starts with Copyright (c) 2026 Xubuntu.org which is sus, because it is 2025. I opened the .exe with file-roller and couldn't find any .torrent inside."

> opened the .exe with file-roller

... This is a thing?

don't know about file roller but you can do this in 7-zip to peek at self-extracting archives

Ah. Those work by having a valid zip at the end (and extraction code in front), taking advantage of the zip format allowing for arbitrary data before the actual zip data (which in turn was intended to facilitate this sort of thing).

It hadn't occurred to me that the .exe in question would be a self-extracting archive (or malicious code that also involves self-extracting an archive as part of the malicious working).

File roller does use 7z internally, so no real surprise here.

But both implementations can be vulnerable to malicious exe files, so it's not a great idea to do this with a file you already suspect to be malicious.

And where did you get the reference SHA256SUMS from ? Did you check the gpg signature on them against a good sig from somewhere?

According to the SHA256SUMS from Canonical's official download page at https://cdimage.ubuntu.com/xubuntu/releases/24.04.3/release/ that is the correct checksum.

Good Point. The checksums posted on Xubuntu.org could also compromised.

I downloaded the checksums and the ISO image from the Xubuntu website: https://mirror.us.leaseweb.net/ubuntu-cdimage/xubuntu/releas...

This url is on the main Xubuntu website, under "Xubuntu 24.04": click "Release page," then select United States. From there, you download the following files: SHA256SUMS, SHA256SUMS.gpg, xubuntu-24.04.3-desktop-amd64.iso

The output of the other checksum commands is shown here:

[user@host]$ gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

gpg: Signature made Thu 07 Aug 2025 06:05:22 AM CDT

gpg: using RSA key 843938DF228D22F7B3742BC0D94AA3F0EFE21092

gpg: Can't check signature: No public key

[user@host]$ sha256sum --check SHA256SUMS

xubuntu-24.04.3-desktop-amd64.iso: OK

(output omitted for results of Xubuntu minimal version, which was not downloaded)

The checksum is a cryptographic hash generated from the ISO file's contents. While the checksum for a specific, unchanged ISO file is fixed, the checksum that is published on a website could be deliberately altered by an attacker to hide a modified, malicious ISO.

how does one know any signature they find is "good"?

Generally speaking, a signature is cryptographically signed, when a checksum value is encrypted with the owners private key. The according public key should ideally be distributed in a chain-of-trust, so it can be obtained through a trusted channel.

If you're using a Debian derivative these keys should be in packages distributed with your distro with trust coming from that

Since the distro's site was compromised you also have to check that any keys it distributes haven't changed. And that the compromise wasn't done by a legitimate maintainer.

The packages in question don't come from the distro's homepage.

We are in a perpetual loop of inefficient check methods, a bunch of steps, rediscovering what a supply chain attack is, a bunch of steps and just loop back over again.

If an attacker can upload a compromised ISO I assume they can also upload a compromised checksum? In the age of https downloads — where the payload cannot be modified in transit — it never made sense to me why ISO checksums are a thing. For checksums to actually do anything there needs to be a chain of trust back to a trusted entity.

Mirrors.

Lots of small, volunteer-run, low/zero-budget open-source projects cannot afford to pay for the server/CDN bandwidth they would need to host all their binary artifacts (ISOs, packages, etc.). They end up relying on mirrors provided for free by third parties instead. By publishing the checksums, they allow you to verify that the ISO image you downloaded from some mirror is the same one that they originally published.

> In the age of https downloads — where the payload cannot be modified in transit — it never made sense to me why ISO checksums are a thing.

Is there no way a download over HTTPS can be corrupted non-maliciously, or can fail to complete?

TLS uses message authentication codes which should detect tampering or bit errors. In theory, a cosmic ray could hit the RAM of the device on the receiving end and bit flip after the ISO has been decrypted but still in RAM. Checksumming does not rule bit flips out though as you could checksum the ISO and the bitflip happens between then and when the ISO is actually used to install the system.

Maybe in theory you could checksum the post installed filesystem, but Im not sure if any distros actually do that or not and it would require deterministic install layouts.

It can fail mid-way of course, but it really shouldn't corrupt in any other way. HTTPS is authenticated after all and malicious manipulation is harder to defend against than accidental corruption. But this is reality and you can have bugs and errors outside the transport of course. Your file system could corrupt data, your drive could be bad etc.

For security you want signatures with a known, trusted key.