GitHub Advisoryadvisory · Go

GHSA-jpmc-7p9c-4rxf lxd has a restricted TLS certificate privilege escalation when in PKI mode

LOW Published 2024-12-09 Modified 2026-06-26 Official page ↗
Aliases
CVE-2024-6219
Ecosystem
Go
Packages
github.com/canonical/lxd
Severity
Low
CVSS vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Weaknesses
CWE-287, CWE-295
Reviewed
2024-12-09

Affected packages

• Go github.com/canonical/lxd: < 0.0.0-20240403103450-0e7f2b5bf4d2 → fixed in 0.0.0-20240403103450-0e7f2b5bf4d2

Description

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

Related

Alias · CVE (1)

  • CVE-2024-6219 Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its… vulnerability

Weakness · CWE (2)

  • CWE-287 Improper Authentication weakness
  • CWE-295 Improper Certificate Validation weakness

References