### Summary If a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in "PKI mode". In this mode, all clients must have certificates that have been signed by the CA. The LXD configuration option `core.trust_ca_certificates` defaults to `false`. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS. When a restricted certificate is added to the trust store in this mode, it's restrictions are not honoured, and the client has full access to LXD. ### Details When authorization was refactored to allow for generalisation (at the time for TLS, RBAC, and OpenFGA, see https://github.com/canonical/lxd/pull/12313), PKI mode did not account for the `core.trust_ca_certificates` configuration option. When this option is enabled, all CA-signed client certificates are given full access to LXD. [This cherry-pick from Incus](https://github.com/canonical/lxd/pull/12513/commits/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd) was added to LXD to fix the issue. The cherry-pick fixed the immediate issue and allowed full access to LXD for CA-signed client certificates when `core.trust_ca_certificates` is enabled, but did not consider the behaviour of LXD when `core.trust_ca_certificates` is disabled. When `core.trust_ca_certificates` is false, restrictions that are applied to a certificate should be honoured. Instead, they are being ignored due to the presence of a `server.ca` file in `LXD_DIR`. ### PoC ``` # Install/initialize LXD $ snap install lxd --channel 5.21/stable $ lxd init --auto $ lxc config set core.https_address=127.0.0.1:8443 # Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa $ cp -R /usr/share/easy-rsa "/tmp/pki" $ export EASYRSA_KEY_SIZE=4096 $ cd /tmp/pki $ ./easyrsa init-pki $ echo "lxd" | ./easyrsa build-ca nopass $ ./easyrsa build-client-full lxd-client nopass $ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca $ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt $ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key # Restart daemon. $ systemctl reload snap.lxd.daemon # Add a restricted certificate to the trust store. $ token="$(lxc config trust add --name ca-test --quiet --restricted)" $ lxc remote add tls "${token}" # Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config. $ lxc config get tls: core.https_address 127.0.0.1:8443 ``` ### Impact I believe this vulnerability is low impact because PKI mode is: 1. Not the standard or recommended mode of operation for LXD. 2. While `core.trust_ca_certificates` defaults to false, we believe that users who enable PKI mode will generally have `core.trust_ca_certificates` enabled to allow for passwordless PKI with CRL revocation (see https://github.com/canonical/lxd/issues/3832). When this mode is enabled, all clients with CA-signed certificates have root access* anyway. *Note: If a restricted certificate is added before `core.trust_ca_certificates` is enabled, the certificate becomes unrestricted. We believe this was the original intention of the PR, but this should be changed to disallow any unintended permission change.
### Summary If a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in "PKI mode". In this mode, all clients must have certificates that have been signed by the CA. The LXD configuration option `core.trust_ca_certificates` defaults to `false`. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS. When a restricted certificate is added to the trust store in this mode, it's restrictions are not honoured, and the client has full access to LXD. ### Details When authorization was refactored to allow for generalisation (at the time for TLS, RBAC, and OpenFGA, see https://github.com/canonical/lxd/pull/12313), PKI mode did not account for the `core.trust_ca_certificates` configuration option. When this option is enabled, all CA-signed client certificates are given full access to LXD. [This cherry-pick from Incus](https://github.com/canonical/lxd/pull/12513/commits/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd) was added to LXD to fix the issue. The cherry-pick fixed the immediate issue and allowed full access to LXD for CA-signed client certificates when `core.trust_ca_certificates` is enabled, but did not consider the behaviour of LXD when `core.trust_ca_certificates` is disabled. When `core.trust_ca_certificates` is false, restrictions that are applied to a certificate should be honoured. Instead, they are being ignored due to the presence of a `server.ca` file in `LXD_DIR`. ### PoC ``` # Install/initialize LXD $ snap install lxd --channel 5.21/stable $ lxd init --auto $ lxc config set core.https_address=127.0.0.1:8443 # Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa $ cp -R /usr/share/easy-rsa "/tmp/pki" $ export EASYRSA_KEY_SIZE=4096 $ cd /tmp/pki $ ./easyrsa init-pki $ echo "lxd" | ./easyrsa build-ca nopass $ ./easyrsa build-client-full lxd-client nopass $ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca $ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt $ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key # Restart daemon. $ systemctl reload snap.lxd.daemon # Add a restricted certificate to the trust store. $ token="$(lxc config trust add --name ca-test --quiet --restricted)" $ lxc remote add tls "${token}" # Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config. $ lxc config get tls: core.https_address 127.0.0.1:8443 ``` ### Impact I believe this vulnerability is low impact because PKI mode is: 1. Not the standard or recommended mode of operation for LXD. 2. While `core.trust_ca_certificates` defaults to false, we believe that users who enable PKI mode will generally have `core.trust_ca_certificates` enabled to allow for passwordless PKI with CRL revocation (see https://github.com/canonical/lxd/issues/3832). When this mode is enabled, all clients with CA-signed certificates have root access* anyway. *Note: If a restricted certificate is added before `core.trust_ca_certificates` is enabled, the certificate becomes unrestricted. We believe this was the original intention of the PR, but this should be changed to disallow any unintended permission change.
Update github.com/canonical/lxd to 0.0.0-20240403103450-0e7f2b5bf4d2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanlxd has a restricted TLS certificate privilege escalation when in PKI mode affects github.com/canonical/lxd (go). Severity is low. ### Summary If a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in "PKI mode". In this mode, all clients must have certificates that have been signed by the CA. The LXD configuration option `core.trust_ca_certificates` defaults to `false`. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS. When a restricted certificate is added to the trust store in this mode, it's restrictions are not honoured, and the client has full access to LXD. ### Details When authorization was refactored to allow for generalisation (at the time for TLS, RBAC, and OpenFGA, see https://github.com/canonical/lxd/pull/12313), PKI mode did not account for the `core.trust_ca_certificates` configuration option. When this option is enabled, all CA-signed client certificates are given full access to LXD. [This cherry-pick from Incus](https://github.com/canonical/lxd/pull/12513/commits/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd) was added to LXD to fix the issue. The cherry-pick fixed the immediate issue and allowed full access to LXD for CA-signed client certificates when `core.trust_ca_certificates` is enabled, but did not consider the behaviour of LXD when `core.trust_ca_certificates` is disabled. When `core.trust_ca_certificates` is false, restrictions that are applied to a certificate should be honoured. Instead, they are being ignored due to the presence of a `server.ca` file in `LXD_DIR`. ### PoC ``` # Install/initialize LXD $ snap install lxd --channel 5.21/stable $ lxd init --auto $ lxc config set core.https_address=127.0.0.1:8443 # Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa $ cp -R /usr/share/easy-rsa "/tmp/pki" $ export EASYRSA_KEY_SIZE=4096 $ cd /tmp/pki $ ./easyrsa init-pki $ echo "lxd" | ./easyrsa build-ca nopass $ ./easyrsa build-client-full lxd-client nopass $ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca $ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt $ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key # Restart daemon. $ systemctl reload snap.lxd.daemon # Add a restricted certificate to the trust store. $ token="$(lxc config trust add --name ca-test --quiet --restricted)" $ lxc remote add tls "${token}" # Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config. $ lxc config get tls: core.https_address 127.0.0.1:8443 ``` ### Impact I believe this vulnerability is low impact because PKI mode is: 1. Not the standard or recommended mode of operation for LXD. 2. While `core.trust_ca_certificates` defaults to false, we believe that users who enable PKI mode will generally have `core.trust_ca_certificates` enabled to allow for passwordless PKI with CRL revocation (see https://github.com/canonical/lxd/issues/3832). When this mode is enabled, all clients with CA-signed certificates have root access* anyway. *Note: If a restricted certificate is added before `core.trust_ca_certificates` is enabled, the certificate becomes unrestricted. We believe this was the original intention of the PR, but this should be changed to disallow any unintended permission change.
AI coding agents often install or upgrade packages automatically in go. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/canonical/lxdgo | <0.0.0-20240403103450-0e7f2b5bf4d2 | 0.0.0-20240403103450-0e7f2b5bf4d2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/canonical/lxd to 0.0.0-20240403103450-0e7f2b5bf4d2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanlxd has a restricted TLS certificate privilege escalation when in PKI mode affects github.com/canonical/lxd (go). Severity is low. ### Summary If a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in "PKI mode". In this mode, all clients must have certificates that have been signed by the CA. The LXD configuration option `core.trust_ca_certificates` defaults to `false`. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS. When a restricted certificate is added to the trust store in this mode, it's restrictions are not honoured, and the client has full access to LXD. ### Details When authorization was refactored to allow for generalisation (at the time for TLS, RBAC, and OpenFGA, see https://github.com/canonical/lxd/pull/12313), PKI mode did not account for the `core.trust_ca_certificates` configuration option. When this option is enabled, all CA-signed client certificates are given full access to LXD. [This cherry-pick from Incus](https://github.com/canonical/lxd/pull/12513/commits/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd) was added to LXD to fix the issue. The cherry-pick fixed the immediate issue and allowed full access to LXD for CA-signed client certificates when `core.trust_ca_certificates` is enabled, but did not consider the behaviour of LXD when `core.trust_ca_certificates` is disabled. When `core.trust_ca_certificates` is false, restrictions that are applied to a certificate should be honoured. Instead, they are being ignored due to the presence of a `server.ca` file in `LXD_DIR`. ### PoC ``` # Install/initialize LXD $ snap install lxd --channel 5.21/stable $ lxd init --auto $ lxc config set core.https_address=127.0.0.1:8443 # Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa $ cp -R /usr/share/easy-rsa "/tmp/pki" $ export EASYRSA_KEY_SIZE=4096 $ cd /tmp/pki $ ./easyrsa init-pki $ echo "lxd" | ./easyrsa build-ca nopass $ ./easyrsa build-client-full lxd-client nopass $ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca $ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt $ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key # Restart daemon. $ systemctl reload snap.lxd.daemon # Add a restricted certificate to the trust store. $ token="$(lxc config trust add --name ca-test --quiet --restricted)" $ lxc remote add tls "${token}" # Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config. $ lxc config get tls: core.https_address 127.0.0.1:8443 ``` ### Impact I believe this vulnerability is low impact because PKI mode is: 1. Not the standard or recommended mode of operation for LXD. 2. While `core.trust_ca_certificates` defaults to false, we believe that users who enable PKI mode will generally have `core.trust_ca_certificates` enabled to allow for passwordless PKI with CRL revocation (see https://github.com/canonical/lxd/issues/3832). When this mode is enabled, all clients with CA-signed certificates have root access* anyway. *Note: If a restricted certificate is added before `core.trust_ca_certificates` is enabled, the certificate becomes unrestricted. We believe this was the original intention of the PR, but this should be changed to disallow any unintended permission change.
AI coding agents often install or upgrade packages automatically in go. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/canonical/lxdgo | <0.0.0-20240403103450-0e7f2b5bf4d2 | 0.0.0-20240403103450-0e7f2b5bf4d2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard