Missing validation logic in the storage volume import logic allows an authenticated user with access to Incus' storage volume feature to cause the Incus daemon to crash. Repeated use of this issue can be used to keep Incus offline causing a denial of service.
Uploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system. The impact here is limited for anyone using storage.images_volume and storage.backups_volume as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS.
User provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory.
Missing error handling could lead an authenticated Incus user to cause a daemon crash through the import of a truncated storage bucket backup file.
A partial implementation of our restricted.images.servers project restriction allows users in such restricted projects to still cause Incus to send HEAD requests to arbitrary endpoints. The actual image download will be rejected by the project restriction, but the ability to trigger arbitrary HTTP requests inside of the Incus environment can still be used as a way to discover otherwise hidden details about the environment.
Broken TLS validation logic in the OVN database connection logic could allow connections to an attacker's OVN database. OVN uses mTLS for authentication, so the attacker cannot actually perform a full man in the middle attack as they won't be able to authenticated with the real OVN deployment. At best they can provide a replacement empty database which Incus will briefly interact with before hitting errors due to the rest …
Missing validation logic in the storage volume import logic allows an authenticated user with access to Incus' storage volume feature to cause the Incus daemon to crash. Repeated use of this issue can be used to keep Incus offline causing a denial of service.
Missing validation logic in the storage bucket import logic allows an authenticated user with access to Incus' storage bucket feature to cause the Incus daemon to crash. Repeated use of this issue can be used to keep Incus offline causing a denial of service.
The web server spawned by incus webui incorrectly validates the authentication token such that an invalid value will be accepted.
Incus provides an API to retrieve VM screenshots, that API relies on the use of a temporary file for QEMU to write the screenshot to which is then picked up and sent to the user prior to deletion. As Incus uses predictable paths under /tmp for this, an attacker with local access to the system can abuse this mechanism by creating their own symlinks ahead of time. On the vast …
A specially crafted storage bucket backup can be used by an user with access to Incus' storage bucket feature to crash the Incus daemon. Repeated use of this attack can be used to keep the server offline causing a denial of service of the control plane API. This does not impact any running workload, existing containers and virtual machines will keep operating.
Instance template files can be used to cause arbitrary read or writes as root on the host server.
Incus instances have an option to provide credentials to systemd in the guest. For containers, this is handled through a shared directory. An attacker can use the name of a systemd credential to escape that directory and overwrite arbitrary files on the host system. This can in turn be used to perform local privilege escalation or cause a DoS.
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.
A user with the ability to launch a container with a custom image (e.g a member of the ‘incus’ group) can use directory traversal or symbolic links in the templating functionality to achieve host arbitrary file read, and host arbitrary file write, ultimately resulting in arbitrary command execution on the host. This can also be exploited in IncusOS.
A user with the ability to launch a container with a custom YAML configuration (e.g a member of the ‘incus’ group) can create an environment variable containing newlines, which can be used to add additional configuration items in the container’s lxc.conf due to the newline injection. This can allow adding arbitrary lifecycle hooks, ultimately resulting in arbitrary command execution on the host.
This affects any Incus user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the security.shifted property set to true as well as access to the host as an unprivileged user. The most common case for this would be systems using incus-user with the less privileged incus group to provide unprivileged users with an isolated restricted access …
When using an ACL on a device connected to a bridge, Incus generates nftables rules that partially bypass security options security.mac_filtering, security.ipv4_filtering and security.ipv6_filtering. This can lead to ARP spoofing on the bridge and to fully spoof another VM/container on the same bridge.
When using an ACL on a device connected to a bridge, Incus generates nftables rules for local services (DHCP, DNS…) that partially bypass security options security.mac_filtering, security.ipv4_filtering and security.ipv6_filtering. This can lead to DHCP pool exhaustion and opens the door for other attacks.