4 ms·

I ran the checksum for the current ISO file of the full Xubuntu desktop version on the Xubuntu website, and the checksum appears to be valid. https://mirror.us

I ran the checksum for the current ISO file of the full Xubuntu desktop version on the Xubuntu website, and the checksum appears to be valid. https://mirror.us.leaseweb.net/ubuntu-cdimage/xubuntu/releases/24.04/release/ https://mirror.us.leaseweb.net/ubuntu-cdimage/xubuntu/releas... [user@host]$ ls SHA256SUMS SHA256SUMS.gpg xubuntu-24.04.3-desktop-amd64.iso [user@host]$ cat SHA256SUMS b61e083d8a5ab003bad6ef7ea31ec21d7bfdf19b99d75987ab3fa3bbe85ec1bf *xubuntu-24.04.3-desktop-amd64.iso [user@host]$ sha256sum xubuntu-24.04.3-desktop-amd64.iso b61e083d8a5ab003bad6ef7ea31ec21d7bfdf19b99d75987ab3fa3bbe85ec1bf xubuntu-24.04.3-desktop-amd64.iso [user@host]$ echo $? 0

trebligdivad 1y ago
And where did you get the reference SHA256SUMS from ? Did you check the gpg signature on them against a good sig from somewhere?
- tuhgdetzhh 1y ago
  Good Point. The checksums posted on Xubuntu.org could also compromised.
- diogenes_atx 1y ago
  I downloaded the checksums and the ISO image from the Xubuntu website: https://mirror.us.leaseweb.net/ubuntu-cdimage/xubuntu/releases/24.04/release/ 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.
- ntoskrnl_exe 1y ago
  According to the SHA256SUMS from Canonical's official download page at https://cdimage.ubuntu.com/xubuntu/releases/24.04.3/release/ https://cdimage.ubuntu.com/xubuntu/releases/24.04.3/release/ that is the correct checksum.
- ranger_danger 1y ago
  how does one know any signature they find is "good"?
  - SV_BubbleTime 1y ago
    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.
  - _def 1y ago
    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.
  - kwk1 1y ago
    If you're using a Debian derivative these keys should be in packages distributed with your distro with trust coming from that
    - SAI_Peregrinus 1y ago
      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.
      - kwk1 1y ago
        The packages in question don't come from the distro's homepage.
zvmaz 1y ago
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/ 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."
- zahlman 1y ago
  > opened the .exe with file-roller ... This is a thing?
  - unleaded 1y ago
    don't know about file roller but you can do this in 7-zip to peek at self-extracting archives
    - creshal 1y ago
      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.
    - zahlman 1y ago
      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).
  - 1718627440 1y ago
    Yes, an exe is just some glorified container format.
__turbobrew__ 1y ago
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.
- normie3000 1y ago
  > 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?
  - basilikum 1y ago
    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.
  - __turbobrew__ 1y ago
    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.
- kbolino 1y ago
  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.

trebligdivad 1y ago

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

tuhgdetzhh 1y ago
Good Point. The checksums posted on Xubuntu.org could also compromised.
diogenes_atx 1y ago
I downloaded the checksums and the ISO image from the Xubuntu website: https://mirror.us.leaseweb.net/ubuntu-cdimage/xubuntu/releases/24.04/release/ 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.
ntoskrnl_exe 1y ago
According to the SHA256SUMS from Canonical's official download page at https://cdimage.ubuntu.com/xubuntu/releases/24.04.3/release/ https://cdimage.ubuntu.com/xubuntu/releases/24.04.3/release/ that is the correct checksum.
ranger_danger 1y ago
how does one know any signature they find is "good"?
- SV_BubbleTime 1y ago
  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.
- _def 1y ago
  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.
- kwk1 1y ago
  If you're using a Debian derivative these keys should be in packages distributed with your distro with trust coming from that
  - SAI_Peregrinus 1y ago
    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.
    - kwk1 1y ago
      The packages in question don't come from the distro's homepage.

zvmaz 1y ago

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/ 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."

zahlman 1y ago
> opened the .exe with file-roller ... This is a thing?
- unleaded 1y ago
  don't know about file roller but you can do this in 7-zip to peek at self-extracting archives
  - creshal 1y ago
    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.
  - zahlman 1y ago
    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).
- 1718627440 1y ago
  Yes, an exe is just some glorified container format.

__turbobrew__ 1y ago

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.

normie3000 1y ago
> 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?
- basilikum 1y ago
  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.
- __turbobrew__ 1y ago
  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.
kbolino 1y ago
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.