Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-jpmc-7p9c-4rxf
No affected components available
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:
- Not the standard or recommended mode of operation for LXD.
- While
core.trust_ca_certificatesdefaults to false, we believe that users who enable PKI mode will generally havecore.trust_ca_certificatesenabled 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 vulnerability requires local access to the device to be exploited. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The vulnerability can affect other systems as well, not just the initial system. There is a low impact on the confidentiality of the information.
Limited exploitation activity has been observed. Close monitoring and planned remediation are recommended.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard