GHSA-p8mm-23gg-jc9r Incus does not verify combined fingerprint when downloading images from simplestreams servers
SummaryA lack of validation of the image fingerprint when downloading from simplestreams image servers opens the door to image cache poisoning and under very narrow circumstances exposes other tenants to running attacker controlled images rather than the expected one.DetailsIncus image fingerprints are computed as the SHA256 of the concatenated image files.
When downloading from a public image server using a simplestreams index, Incus requires an HTTPS connection and validates the SHA256 of the individual files but is lacking validation that the concatenated hash of the files matches the fingerprint listed in the simplestreams index.This missing check allows an attacker with access to an Incus environment lacking suitable image source restrictions (`restricted.image.server` or equivalent firewall rules) to cause Incus to download from an attacker controlled image server which would provide different image files for an other well known image fingerprint.Such an attack can be used to poison the global image cache, leading to another user on the system wanting to use the legitimate image to be provided the compromised one instead.For this to be successful, the attacker requires:Access to an Incus serverThat server to NOT have been configured with `restricted.image.servers` or an equivalent firewall or HTTP proxy policySome ability to predict what image may be used by other users in the near futureOther users that are actively deploying new Incus instances on the systemHaving to predict what image may be used in the future which doesn't have its legitimate copy already cached on the system (or somewhere within the cluster) makes this attack quite difficult to pull off. It's made even harder by not having any control as to when a given image may be used by another user.An example of a somewhat easy target would be a server that's known to run ephemeral instances for Ci or build purposes, as those will get created very frequently and the images they use may be public knowledge, it would be possible to get a compromised image in place with the right timing:Monitor the legitimate image server for a new image being publishedImmediately create a compromised image with the same fingerprint on an attacker controlled image serverGet the target Incus environment to download that image BEFORE any legitimate instance creation had the time to pull the legitimate imageBut this again assumes an environment lacking either `restricted.image.servers` or equivalent firewall or proxy policies.MitigationAs mentioned above, any server using `restricted.image.servers` in project configuration, as would be strongly recommended in multi-tenant environments will be immune to this attack. As would any server going through equivalent network restriction whether implemented through firewalling or through an HTTP proxy server.The updated Incus versions will now validate not just the individual files during download but also that the hash of the concatenated files does match the image fingerprint, fully preventing such an attack in the future.PoCTo create a PoC, simply download `https://images.linuxcontainers.org/streams/v1/{index,images}.json` and `https://images.linuxcontainers.org/images/DISTRO/RELEASE/ARCH/default/NEWEST/{incus.tar.xz,rootfs.squashfs}` or similar paths, put them in suitable locations in a folder, and then use a server to serve them through https. The TLS certificate used by the server may need to be signed by a trusted CA of the client system.Then change the content of `rootfs.squashfs` by `unsquashfs`/`mksquashfs`, add one line in `/root/.bashrc`: `echo 'PoC: hacked!'`, and then update corresponding `sha256` and `size` fields for that individual file in `images.json`.Using `incus-simplestreams` first and then altering the `combined_xxx` fields should also be OK.After that, check the following commands:
CVSS v4.0 score: 7