Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Details An attacker can set a configuration key named something like systemd.credential.../../../../../../root/.bashrc to cause Incus to write outside of the credentials directory associated with the container. This makes use of the fact that the Incus syntax for such credentials is systemd.credential.XYZ where XYZ can itself contain more periods. While it's not possible to read any data this way, it's possible to write to arbitrary files as root, enabling both privilege escalation and denial of service attacks. Credit This issue was discovered and reported by the team at 7asecurity
Recommended action: Upgrade to 6.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 majority of Linux systems, this will result in a "Permission denied" error when requesting a screenshot. That's because the Linux kernel has a security feature designed to block such attacks, protectedsymlinks. On the rare systems with this purposefully disabled, it's then possible to trick Incus intro truncating and altering the mode and permissions of arbitrary files on the filesystem, leading to a potential denial of service or possible local privilege escalation. Details The incusd daemon contains a local privilege escalation (LPE) primitive in the Virtual Machine VGA screenshot handling routine. When…
Recommended action: Upgrade to 6.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details When passing environment variables in the config block of a new container, values are not checked for the presence of newlines [1], which can result in newline injection inside the generated container lxc.conf. This can be used to set arbitrary additional configuration items, such as lxc.hook.pre-start. By exploiting this, a user with the ability to launch a container with an arbitrary config can achieve arbitrary command execution as root on the host. Exploiting this issue on IncusOS requires a slight modification of the payload to change to a different writable directory for…
Recommended action: Upgrade to 6.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 to Incus. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unpriivleged user on the host to gain root privileges. Patches A patch for this issue is available here: https://github.com/lxc/incus/pull/2642 The first commit changes the permissions for any new storage pool, the second commit applies it on startup to all existing storage pools. Workarounds Permissions can be manually restricted until a…
Recommended action: Upgrade to 6.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using an ACL on a device connected to a bridge, Incus generates nftables rules that partially bypass security options security.macfiltering, security.ipv4filtering and security.ipv6filtering. This can lead to ARP spoofing on the bridge and to fully spoof another VM/container on the same bridge. Details In commit d137a063c2fe2a6983c995ba75c03731bee1557d, a few rules in the bridge input chain are moved to the top of the chain: ct state established,related accept iifname "{{.hostName}}" ether type arp accept iifname "{{.hostName}}" ip6 nexthdr ipv6-icmp icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } accept However, these rules accept packets that should be filtered and maybe dropped by later rules in the "MAC filtering", "IPv4 filtering" and "IPv6 filtering" snippets: iifname "{{.hostName}}" ether type arp arp saddr ether != {{.hwAddr}} drop iifname "{{.hostName}}" ether type ip6 icmpv6 type 136 @nh,528,48 != {{.hwAddrHex}} drop ... iifname "{{.hostName}}" ether…
Recommended action: Upgrade to 6.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.macfiltering, security.ipv4filtering and security.ipv6filtering. This can lead to DHCP pool exhaustion and opens the door for other attacks. Details In commit a7c33301738aede3c035063e973b1d885d9bac7c, the following rules are added at the top of the bridge input chain: iifname "{{.hostName}}" ether type ip ip saddr 0.0.0.0 ip daddr 255.255.255.255 udp dport 67 accept iifname "{{.hostName}}" ether type ip6 ip6 saddr fe80::/10 ip6 daddr ff02::1:2 udp dport 547 accept iifname "{{.hostName}}" ether type ip6 ip6 saddr fe80::/10 ip6 daddr ff02::2 icmpv6 type 133 accept However, these rules accept packets that should be filtered and maybe dropped by later rules in the "MAC filtering" snippet: iifname "{{.hostName}}" ether type arp arp saddr ether != {{.hwAddr}} drop iifname "{{.hostName}}" ether type ip6 icmpv6 type 136…
Recommended action: Upgrade to 6.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.