CVE-2024-6156

Mark Laing discovered that LXD's PKI mode, until version 5.21.2, could be bypassed if the client's certificate was present in the trust store.

Mark Laing discovered that LXD's PKI mode, until version 5.21.2, could be bypassed if the client's certificate was present in the trust store.

Summary

If a server.ca file is present in LXD_DIR at LXD start up, LXD is in "PKI mode". In this mode, only TLS clients that have a CA-signed certificate should be able to authenticate with LXD.

We have discovered that if a client that sends a non-CA signed certificate during the TLS handshake, that client is able to authenticate with LXD if their certificate is present in the trust store. - The LXD Go client (and by extension lxc) does not send non-CA signed certificates during the handshake. - A manual client (e.g. cURL) might send a non-CA signed certificate during the handshake.

Versions affected

LXD 4.0 and above.

Details

When PKI mode was added to LXD it was intended that all client and server certificates must be signed by the certificate authority (see https://github.com/canonical/lxd/pull/2070/commits/84d917bdcca6fe1e3191ce47f1597c7d094e1909).

In PKI mode, the TLS listener configuration is altered to add the CA certificate but the ClientAuth field of tls.Config is not changed. The ClientAuth field is set to tls.RequestClientCert, which configures the TLS connection to request a certificate from the client, but not require one. This is necessary because untrusted requests are allowed for some endpoints.

If a client certificate is present in the trust store before PKI mode is enabled, calls to LXD using that certificate fail when using the Go client for LXD. I believe that what is happening is as follows:

• During the TLS handshake, the server requests a certificate from the client. The server includes in it's request a list of acceptable CAs.
• The go client receives the request from the server, but does not have any certificates that match what the server requires, and so does not send any.
• The server considers the handshake complete because it does not absolutely require the client certificate (see above).
• In the (*Daemon).Authenticate method, when checking for TLS clients, there are no PeerCertificates in the request. So util.CheckTrustState is never called and the request is denied.

Importantly, the above does not apply if the client sends a certificate during the handshake anyway. If this occurs and the certificate is present in the trust store, the request is trusted and is allowed to continue. It is possible to do this using cURL*.

PoC

The follow snippet demonstrates the vulnerability:

# Install/initialize LXD
$ snap install lxd --channel 5.21/stable
$ lxd init --auto
$ lxc config set core.https_address=127.0.0.1:8443

# Add a certificate to the trust store before enabling PKI.
$ token="$(lxc config trust add --name ca-test --quiet)"
$ lxc remote add tls "${token}"

# 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
$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca

# Restart daemon.
$ systemctl reload snap.lxd.daemon

# Using curl with the client certificate we expect a 403 Forbidden response.
# Instead we get a 200 OK and we are able to view the response body.
$ cat ~/snap/lxd/common/config/client.crt ~/snap/lxd/common/config/client.key > ~/snap/lxd/common/config/client.pem
$ curl -s --cert ~/snap/lxd/common/config/client.pem --cacert /var/snap/lxd/common/lxd/server.crt https://127.0.0.1:8443/1.0" | jq '.metadata.config."core.https_address"'

Impact

I believe this has a low impact for the following reasons:

• PKI mode is unlikely to have a large user base.
• PKI is likely to be configured at start up without any previous certificates in the trust store.
• Authentication is not bypassed entirely, the client certificate must already be trusted.

Notes

• I am not certain why cURL sends the certificate during the handshake but we can see it in the logs:

*   Trying 127.0.0.1:8443...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
       …

Mark Laing discovered that LXD's PKI mode, until version 5.21.2, could be bypassed if the client's certificate was present in the trust store.

Mark Laing discovered that LXD's PKI mode, until version 5.21.2, could be bypassed if the client's certificate was present in the trust store.

Mark Laing discovered that LXD's PKI mode, until version 5.21.2, could be bypassed if the client's certificate was present in the trust store.