CVE-2024-6219 – github.com/canonical/lxd

Package

Manager: go
Name: github.com/canonical/lxd
Vulnerable Version: >=0 <0.0.0-20240403103450-0e7f2b5bf4d2

Severity

Level: Low

CVSS v3.1: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

CVSS v4.0: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

EPSS: 0.00023 pctl0.04593

Details

lxd has a restricted TLS certificate privilege escalation when in PKI mode ### 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.

Metadata

Created: 2024-12-09T22:43:13Z
Modified: 2025-03-20T18:52:08Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2024/12/GHSA-jpmc-7p9c-4rxf/GHSA-jpmc-7p9c-4rxf.json
CWE IDs: ["CWE-287", "CWE-295"]
Alternative ID: GHSA-jpmc-7p9c-4rxf
Finding: F039
Auto approve: 1