ghsa-jpmc-7p9c-4rxf
Vulnerability from github
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.
{ "affected": [ { "package": { "ecosystem": "Go", "name": "github.com/canonical/lxd" }, "ranges": [ { "events": [ { "introduced": "0" }, { "fixed": "0.0.0-20240403103450-0e7f2b5bf4d2" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2024-6219" ], "database_specific": { "cwe_ids": [ "CWE-287" ], "github_reviewed": true, "github_reviewed_at": "2024-12-09T22:43:13Z", "nvd_published_at": "2024-12-06T00:15:04Z", "severity": "LOW" }, "details": "### Summary\nIf 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. \n\nThe 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.\n\nWhen a restricted certificate is added to the trust store in this mode, it\u0027s restrictions are not honoured, and the client has full access to LXD.\n\n### Details\nWhen 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. \n\nThe 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. \n\nWhen `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`.\n\n### PoC\n```\n# Install/initialize LXD\n$ snap install lxd --channel 5.21/stable\n$ lxd init --auto\n$ lxc config set core.https_address=127.0.0.1:8443\n\n# Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa\n$ cp -R /usr/share/easy-rsa \"/tmp/pki\"\n$ export EASYRSA_KEY_SIZE=4096\n$ cd /tmp/pki\n$ ./easyrsa init-pki\n$ echo \"lxd\" | ./easyrsa build-ca nopass\n$ ./easyrsa build-client-full lxd-client nopass\n$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca\n$ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt\n$ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key\n\n# Restart daemon.\n$ systemctl reload snap.lxd.daemon\n\n# Add a restricted certificate to the trust store.\n$ token=\"$(lxc config trust add --name ca-test --quiet --restricted)\"\n$ lxc remote add tls \"${token}\"\n\n# Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config.\n$ lxc config get tls: core.https_address\n127.0.0.1:8443\n```\n\n### Impact\nI believe this vulnerability is low impact because PKI mode is:\n1. Not the standard or recommended mode of operation for LXD.\n2. 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.\n\n*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.\n", "id": "GHSA-jpmc-7p9c-4rxf", "modified": "2024-12-09T22:43:13Z", "published": "2024-12-09T22:43:13Z", "references": [ { "type": "WEB", "url": "https://github.com/canonical/lxd/security/advisories/GHSA-jpmc-7p9c-4rxf" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6219" }, { "type": "WEB", "url": "https://github.com/canonical/lxd/pull/12313" }, { "type": "PACKAGE", "url": "https://github.com/canonical/lxd" }, { "type": "WEB", "url": "https://pkg.go.dev/vuln/GO-2024-3313" }, { "type": "WEB", "url": "https://www.cve.org/CVERecord?id=CVE-2024-6219" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N", "type": "CVSS_V3" } ], "summary": "lxd has a restricted TLS certificate privilege escalation when in PKI mode" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.