GHSA-jpmc-7p9c-4rxf

Описание

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

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.