GitHub Security Advisory: GHSA-p8mm-23gg-jc9r
Package: github.com/lxc/incus/v6/client (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-295: Improper Certificate Validation, CWE-354: Improper Validation of Integrity Check Value
Vulnerable versions: < 6.23.0
Patched in: 6.23.0

Summary: Incus does not verify combined fingerprint when downloading images from simplestreams servers

Details:
### Summary
A 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.

### Details
Incus 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 server
 - That server to NOT have been configured with `restricted.image.servers` or an equivalent firewall or HTTP proxy policy
 - Some ability to predict what image may be used by other users in the near future
 - Other users that are actively deploying new Incus instances on the system

Having 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 published
 - Immediately create a compromised image with the same fingerprint on an attacker controlled image server
 - Get the target Incus environment to download that image BEFORE any legitimate instance creation had the time to pull the legitimate image

But this again assumes an environment lacking either `restricted.image.servers` or equivalent firewall or proxy policies.

### Mitigation
As 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 bu