CVE-2026-6420: Hardcoded attestation challenge nonce allows replay attacks

Impact

The CertificationParameters.generatechallenge() method in the push attestation protocol uses a hardcoded challenge nonce instead of generating a cryptographically random value. This removes the nonce-based replay protection from TPM quote attestation.

An attacker with root access on a monitored agent node can exploit this by stockpiling valid TPM quotes (using tpm2quote with the known nonce) before compromising the system, then replaying them to evade detection by the verifier. The push attestation timeout (~10s) constrains the generation window, but TPM throughput allows stockpiling ~50-200 quotes, enabling approximately 8-33 minutes of undetected compromise with default settings.

The attack is limited to a single agent node (AK signature binding prevents cross-agent replay). The pull-mode (legacy) attestation path is not affected.

Affected versions: >= 7.14.0, <= 7.14.1

CVSS: 6.3 Medium (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L)

| Metric | Value | Rationale | |---|---|---| | AV | Local | Exploitation requires local access to the agent machine (stop agent, access TPM, run replacement). The network transmission of quotes to the verifier is normal protocol operation. | | AC | Low | Deterministic attack: publicly visible nonce, standard tpm2-tools, no race conditions. | | PR | High | Root on a legitimate enrolled node is required. The vulnerability does not help gain access -- it only helps evade detection after root is obtained. No value against a machine the attacker already controls. | | UI | None | Fully automated after initial setup. | | S | Unchanged | AK signature binding confines impact to the single compromised agent. | | C | High | Compromised node continues receiving bootstrap keys, payloads, and secrets intended for trusted nodes. | | I | High | Verifier cannot distinguish a healthy system from a fully compromised one during the evasion window. | | A | Low | Only the compromised agent's revocation and incident response are suppressed; the system as a whole remains operational. |

The base score does not fully capture the operational severity: Keylime exists to detect machine compromise, so 8-33 minutes of undetected compromise is operationally critical. The fix is a one-line change and should be applied immediately regardless of the base score.

Patches

The fix restores the original random nonce generation (one-line change in keylime/models/verifier/evidence.py):

python Before (vulnerable): def generatechallenge(self, bitlength): # self.challenge = Nonce.generate(bitlength) self.challenge = bytes.fromhex("49beed365aac777dae23564f5ad0ec")

After (fixed): def generatechallenge(self, bitlength): self.challenge = Nonce.generate(bitlength)

Users should upgrade to the version containing this fix (7.14.2).

Workarounds

There is no complete workaround. The following existing mechanisms provide partial mitigation and are already active by default (no configuration needed):

1. TPM clock monotonicity check limits each distinct stockpiled quote to a single use, bounding the total evasion time. 2. Push attestation timeout (default 10s) prevents the attacker from going silent and constrains the quote generation window.

Reducing quoteinterval increases the attestation frequency but does not prevent the stockpiling attack.

References

- CWE-329: Generation of Predictable IV/Nonce (primary -- hardcoded nonce in cryptographic attestation protocol) - CWE-547: Use of Hard-Coded, Security-relevant Constants (hardcoded constant left in production code) - CWE-294: Authentication Bypass by Capture-replay (consequence -- enables replay attacks) - CWE-1241: Use of Predictable Algorithm in Random Number Generator - Introducing commit: 2bf91197 via PR #1814 - TCG TPM 2.0 Library Specification, Part 1, Section 18.4 (TPM2Quote) - IETF RATS Architecture (RFC 9334), Section 8 (Freshness)

Keylime verifier uses a hardcoded challenge nonce for TPM quote attestation instead of generating a cryptographically random value. An attacker with root access on an enrolled monitored machine (where the Keylime agent runs) can stockpile valid TPM quotes using tpm2quote with the known nonce during the push attestation timeout window (defaulting to 10 seconds). The attacker can then compromise the system and replay these quotes to evade detection. Only the push model deployment is affected, the pull model does not use the affected code.

Requirements for exploitation: Root access on a legitimate, monitored machine (running a previously enrolled Keylime agent). The attacker stops the agent, generates quotes via tpm2quote with the known nonce (system still clean, so PCR values are trusted), starts a replacement agent before the ~10s timeout expires, then compromises the system. Each stockpiled quote is usable once (clock monotonicity check prevents reuse).

Impact

The Keylime registrar does not enforce mutual TLS (mTLS) client certificate authentication since version 7.12.0. The registrar's TLS context is configured with ssl.CERTOPTIONAL instead of ssl.CERTREQUIRED, allowing any client to connect to protected API endpoints without presenting a valid client certificate.

Who is impacted: - All Keylime deployments running versions 7.12.0 through 7.13.0 - Environments where the registrar HTTPS port (default 8891) is network-accessible to untrusted clients

What an attacker can do: - List all registered agents (GET /v2/agents/) - enumerate the entire agent inventory - Retrieve agent details (GET /v2/agents/{uuid}) - obtain public TPM keys, certificates, and network locations (IP/port) of any agent - Delete any agent (DELETE /v2/agents/{uuid}) - remove agents from the registry, disrupting attestation services

Note: The exposed TPM data (EK, AK, certificates) consists of public keys and certificates. Private keys remain protected within TPM hardware. The HMAC secret used for challenge-response validation is stored in the database but is not exposed via the API.

Affected versions: >= 7.12.0, <= 7.13.0

Fixed versions: 7.12.2, >= 7.13.1

Patches

A patch for the affected released versions is available. It removes the line that override the configuration of ssl.verifymode, leaving the CERTREQUIRED value set by webutil.initmtls():

diff diff --git a/keylime/web/base/server.py b/keylime/web/base/server.py index 1d9a9c2..859b23a 100644 --- a/keylime/web/base/server.py +++ b/keylime/web/base/server.py @@ -2,7 +2,6 @@ import asyncio import multiprocessing from abc import ABC, abstractmethod from functools import wraps -from ssl import CERTOPTIONAL from typing import TYPECHECKING, Any, Callable, Optional

import tornado @@ -252,7 +251,6 @@ class Server(ABC): self.httpsport = config.getint(component, "tlsport", fallback=0) self.maxuploadsize = config.getint(component, "maxuploadsize", fallback=104857600) self.sslctx = webutil.initmtls(component) - self.sslctx.verifymode = CERTOPTIONAL

def get(self, pattern: str, controller: type["Controller"], action: str, allowinsecure: bool = False) -> None: """Creates a new route to handle incoming GET requests issued for paths which match the given

Users should upgrade to the patched version once it is released.

Workarounds

If upgrading is not immediately possible, apply one of the following mitigations:

1. Network isolation (Recommended)

Restrict access to the registrar HTTPS port (default 8891) using firewall rules to allow only trusted hosts (verifier, tenant):

Example using iptables iptables -A INPUT -p tcp --dport 8891 -s <verifierip> -j ACCEPT iptables -A INPUT -p tcp --dport 8891 -s <tenantip> -j ACCEPT iptables -A INPUT -p tcp --dport 8891 -j DROP

2. Reverse proxy with mTLS enforcement

Deploy a reverse proxy (nginx, HAProxy) in front of the registrar that enforces client certificate authentication:

Example nginx configuration server { listen 8891 ssl; sslcertificate /path/to/server.crt; sslcertificatekey /path/to/server.key; sslclientcertificate /path/to/ca.crt; sslverifyclient on; # Enforce client certificates

location / { proxypass https://localhost:8892; # Internal registrar port } }

A vulnerability has been identified in keylime where an attacker can exploit this flaw by registering a new agent using a different Trusted Platform Module (TPM) device but claiming an existing agent's unique identifier (UUID). This action overwrites the legitimate agent's identity, enabling the attacker to impersonate the compromised agent and potentially bypass security controls.

The Keylime registrar allows registration of another agent (different TPM device, different EK certificate) with a duplicate UUID. This presents a critical security vulnerability that allows an attacker to take over an existing agent's identity by re-registering with the same UUID though a different TPM's EK certificate.

A flaw was found in Keylime. Due to added strict type checking, Keylime fails to read data from a database populated by a previous version of Keylime. This flaw allows an attacker to make the service unavailable by populating the database before an update to the affected version. Affected component: Keylime Affected version of Keylime: 7.12.0

Impact

A security issue was found in the Keylime registrar code which allows an attacker to effectively bypass the challenge-response protocol used to verify that an agent has indeed access to an AIK which in indeed related to the EK.

When an agent starts up, it will contact a registrar and provide a public EK and public AIK, in addition to the EK Certificate. This registrar will then challenge the agent to decrypt a challenge encrypted with the EK.

When receiving the wrong "authtag" back from the agent during activation, the registrar answers with an error message that contains the expected correct "authtag" (an HMAC which is calculated within the registrar for checking). An attacker could simply record the correct expected "authtag" from the HTTP error message and perform the activate call again with the correct expected "authtag" for the agent.

The security issue allows an attacker to pass the challenge-response protocol during registration with (almost) arbitrary registration data. In particular, the attacker can provide a valid EK Certificate and EK, which passes verification by the tenant (or registrar), while using a compromised AIK, which is stored unprotected outside the TPM and is unrelated to former two. The attacker then deliberately fails the initial activation call to get to know the correct "authtag" and then provides it in a subsequent activation call. This results in an agent which is (incorrectly) registered with a valid EK Certificate, but with a compromised/unrelated AIK.

Patches Users should upgrade to release 7.5.0

Impact Keylime registrar is prone to a simple denial of service attack in which an adversary opens a connection to the TLS port (by default, port 8891) blocking further, legitimate connections. As long as the connection is open, the registrar is blocked and cannot serve any further clients (agents and tenants), which prevents normal operation. The problem does not affect the verifier.

Patches Users should upgrade to release 7.4.0

A flaw was found in the keylime attestation verifier, which fails to flag a device's submitted TPM quote as faulty when the quote's signature does not validate for some reason. Instead, it will only emit an error in the log without flagging the device as untrusted.

Impact

This vulnerability creates a false sense of security for keylime users -- i.e. a user could query keylime and conclude that a parcitular node/agent is correctly attested, while attestations are not in fact taking place.

Short explanation: the keylime verifier creates periodic reports on the state of each attested agent. The keylime verifier runs a set of python asynchronous processes to challenge attested nodes and create reports on the outcome.

The vulnerability consists of the above named python asynchronous processes failing silently, i.e. quitting without leaving behind a database entry, raising an error or producing even a mention of an error in a log. The silent failure can be triggered by a small set of transient network failure conditions; recoverable device driver crashes being one such condition we saw in the wild.

Patches

The problem is fixed in keylime starting with tag 6.5.1

Workarounds

This patch can be retroactively applied to any running keylime deployment. Only running verifiers need to be patched. After the patch is applied, the keylime verifier needs to be restarted.

References

The problem, as well as the proposed fix, are described in detail here. Further details about the system where the bug was found, and the conditions in which the bug was found, are available from @galmasi on demand.

For more information

If you have any questions or comments about this advisory, please comment at the bottom of the advisory itself.

In Keylime before 6.3.0, current keylime installer installs the keylime.conf file, which can contain sensitive data, as world-readable.

In Keylime before 6.3.0, quote responses from the agent can contain possibly untrusted ZIP data which can lead to zip bombs.

In Keylime before 6.3.0, Revocation Notifier uses a fixed /tmp path for UNIX domain socket which can allow unprivileged users a method to prohibit keylime operations.

In Keylime before 6.3.0, unsanitized UUIDs can be passed by a rogue agent and can lead to log spoofing on the verifier and registrar.

A vulnerability in Keylime before 6.3.0 allows an attacker to craft a request to the agent that resets the U and V keys as if the agent were being re-added to a verifier. This could lead to a remote code execution.

A flaw was found in Keylime before 6.3.0. The logic in the Keylime agent for checking for a secure mount can be fooled by previously created unprivileged mounts allowing secrets to be leaked to other processes on the host.

Hello Team, please check the below report: --------

Keylime does not enforce that the agent registrar data is the same when the tenant uses it for validation of the EK and identity quote and the verifier for validating the integrity quote.

This allows an attacker to use one AK, EK pair from a real TPM to pass EK validation and give the verifier an AK of a software TPM.

Affects all versions of Keylime <6.4.0

Thanks

Hello list,

I have been reviewing the Keylime TPM remote attestation solution [1] which resulted in a number of security related findings, including an arbitrary remote code execution in the Keylime Agent component. The upstream project published security advisories, fixes and an update strategy to Keylime version 6.3.X today. Please find the details in the following full report:

1) Scope of Review ==================

I've been looking into the four main components of Keylime: the Agent, Registrar, Verifier and Tenant applications. I have been looking into version 6.2.0. Any source code locations mentioned in this report relate to this version.

2) Findings in the Agent Component ==================================

a) checkmounted() Function Logic can be Fooled by Unprivileged Mounts (CVE-2022-23948) -----------------------------------------------------------------------------------------

The checkmounted() function in securemount.py attempts to make sure that a "secure" tmpfs is mounted at /var/lib/keylime/secure to store sensitive data on that never gets written to disk. To do so the function parses the output of the mount utility to determine whether this file system is already mounted at the desired location.

There can exist the possibility of unprivileged users performing certain mount operations, one of the most prominent examples being the fusermount setuid-root binary for mounting FUSE file systems. In view of this, parsing mount table output needs prudence. I described the basic issue previously already in another report [2].

The following is a reproducer using fusermount that shows the basic local attack vector:

user$ export FUSECOMMFD=0 user$ fusermount some/path/ -ononempty,fsname="tmpfs on /var/lib/keylime/secure"

This will fool the parsing logic in checkmounted() and thus the function assumes that the "secure" tmpfs is already mounted, while it actually isn't. Thus this will allow a local attacker on the system to prevent this security feature to be effective, if the local attacker manages to create such a mount entry before the keylimeagent is starting up.

The attack vector can also be used to perform a local DoS against keylimeagent by claiming a different fsname than tmpfs. checkmounted() will throw an Exception in this case and the Agent won't start.

On a side note there are calls to securemount.mount() spread throughout the Keylime codebase (for example three times in keylimeagent.py, two times in tpmmain.py and two times in caimplcfssl.py. There is no code to clean up this mount again, however. So it potentially leaves behind a stale mount after services are shutdown. Furthermore, if multiple Keylime processes should operate in parallel this could result in a race condition where the "secure" tmpfs is mounted twice, in the worst case mounting a fresh tmpfs over previously stored content there.

My recommendation is to parse the /proc/self/mountinfo pseudo file for mount table information instead. Whitespace is specially encoded in this file. Furthermore the responsibility of mounting and unmounting this file system should be more clearly defined during startup/shutdown of processes and maybe a reference counting / locking scheme to prevent race conditions should be used.

Upstream Security Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-wj36-qcfg-5j52

Upstream Fixes

https://github.com/keylime/keylime/commit/1a4f31a6368d651222683c9debe7d6832db6f607 https://github.com/keylime/keylime/commit/d37c406e69cb6689baa2fb7964bad75209703724

b) Possible Information Leaks via Unauthenticated Agent Quote Interface -----------------------------------------------------------------------

A TPM quote can be requested without authentication from the Agent service via the network:

$ curl "keyagent-host:9002/?apiversion=500&quotes=myquote&nonce=mynonce" { "code": 200, "status": "Success", "results": { "quote": <base64-data>, "hashalg": "sha256", "encalg": "rsa", "signalg": "rsassa", "pubkey": <PEM key>", "boottime": 1639999864 } }

This exposes for example the boottime of the host where the Agent is running, information that is not otherwise easily publicly available. Furthermore: Could the contents of the TPM quote data also be interesting data? Could it for example allow deductions about which kind of operating system kernel is running on the host?

I recommend to somehow authenticate and cryptographically secure this Agent interface to prevent information leaks of this kind.

Upstream Fixes

This issue did not receive a dedicated CVE and fix. It is covered together with the following issue 2.c).

c) Arbitrary Remote Code Execution in the Agent via Unauthenticated Bootstrap Interface (CVE-2021-43310) --------------------------------------------------------------------------------------------------------

Note that this issue has been discovered in parallel also by Thore Sommer, a Keylime upstream developer.

It looks like it is possible to simply post arbitrary new values for the U and V key parts and provide a new configuration payload to the Agent, only knowing the Agent's UUID. The Agent's UUID can be public or semi-public information like when agentuuid=hostname is configured. From the Keylime paper [3] (section 3.2.2) it sounds like the UUID HMAC check is not considered a security feature but only a sanity check: This provides the node with a quick check to determine if Kb is correct. When extractpayloadscript=true (default) and payloadscript=autorun.sh (default) are configured in keylime.conf then the provided payload will be unzipped and a potentially contained autorun.sh script is executed with full root privileges. Attached you can find a reproducer script postkey.py that demonstrates the issue by creating a file /tmp/evil on the Agent host by only providing the Agent hostname and UUID as input parameters.

Even if payloadscript is disabled then the extraction of a ZIP file as root might result in a remote root exploit by extracting files outside of the intended target directory. I did not test this variant of the attack vector, though. Furthermore by providing a ZIP bomb as payload the Agent process can be subjected to a remote DoS through memory exhaustion.

Retrieving the full symmetric key previously stored in /var/lib/keylime/secure/derivedtcikey should not be possible this way, because when performing the bootstrap protocol, the previous data is removed in keylimeagent.py:242. A skillful attacker might attempt to first compromise the Agent node and then wait for the Tenant to re-deploy the Agent using authentic keys and payload. Should this succeed then the attacker can obtain the secret symmetric key from the compromised Agent node after all.

Similar to issue b) I recommend to somehow authenticate and cryptographically secure this Agent interface to prevent these attacks. As a hotfix disabling the relevant configuration features should at least prevent the remote code execution and memory exhaustion attack vectors. Setting non-predictable UUID values can also help (but one should also consider item 3.a in this context). Even then this interface still allows to disrupt the operational state of the Agent host by simply overwriting its current configuration.

Upstream Security Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-2m39-75g9-ff5r

Upstream Fixes

The fix consists of a larger number of upstream commits regarding introduction of "mTLS" for the Agent interface. This means the connection towards the Agent will in the future be cryptographically secured and thus only trusted actors can use the Agent interface.

The upgrade path is a bit complicated because of this (see upstream advisory). Upstream version 6.3.X will introduce the new mTLS support but not enforce it, to allow upgrading of all Keylime components on all nodes. Only upstream version 6.4.x will enforce the new protocol.

d) Key Exchange and Bootstrap Protocol Susceptible to Replay Attacks --------------------------------------------------------------------

Authentic payloads being passed from the Tenant to the Agent should be reasonably safe from attackers (when not considering issue c)), since the two halves of the symmetric key are encrypted using the per-agent node RSA public key. The bootstrap protocol seems to be susceptible to certain replay attacks, however. Since the interface does not employ transport security, the bootstrap protocol can simply be recorded and replayed to activate an authentic configuration payload. This could e.g. be used by an attacker to activate an outdated or even insecure older configuration of the Agent node.

Upstream Fixes

This issue did not receive a dedicated CVE and fix. It is covered together with the previous issue 2.c).

3) Findings in the Registrar Component ======================================

a) UUID of Agents is Received on Unprotected HTTP Interface -----------------------------------------------------------

The Registrar provides two separate HTTP interfaces, a TLS protected one and an unprotected one. Part of the unprotected interface is the Agent registration. As part of the Agent registration the Agent UUID is passed unencrypted (processed in registrarcommon.py:229).

This is not a security issue in its own but relates to issue 2.c where the knowledge of the UUID facilitates remote code execution on the Agent nodes. This means if an attacker can listen in on the Registrar's Agent registration communication then even unpredictable Agent UUIDs no longer hinder the attack described in issue 2.c).

As outlined in 2.c) the UUID does not seem to have been thought of as a security property in the first place so I see no urge to change anything here. Although when the bootstrap protocol should get TLS protection then for completeness it could also make sense to protect this Registrar interface as well the same way.

Upstream Fixes

This specific aspect is covered by the following commit:

https://github.com/keylime/keylime/commit/e5f033c66403a899685b81a3af03cd59f76e455f

There is no dedicated CVE but it is covered together with the overarching introduction of mTLS as outlined in issue 2.c).

b) Unsanitized UUID passed on Unprotected HTTP Interface Facilitates Log Spoofing (CVE-2022-23949) --------------------------------------------------------------------------------------------------

Since the Registrar's unprotected HTTP interface requires no authentication, anybody can post arbitrary Agent registrations with arbitrary parameters. The Agent ID (UUID) parameter is not sanitized in any way and is used unfiltered in log messages (e.g. registrarcommon.py:107).

As a result the Agent ID parameter can be used to inject seemingly valid additional log lines that appear e.g. in journalctl -u keylimeregistrar.service. The attached reproducer script postagent.py can be used to demonstrate this:

$ ./postagent.py --host registrar-host --log-line "Please run rm -rf / to protect your system"

In the journal we will then see:

Dec 21 11:44:22 registrar-host keylimeregistrar[1426]: 2021-12-21 11:44:22.281 - keylime.registrar - WARNING - POST for trusted-agent Dec 21 11:44:22 registrar-host keylimeregistrar[1426]: 2021-12-21 11:44:22.931 - keylime.registrar - WARNING - Please run rm -rf / to protect your system Dec 21 11:44:22 registrar-host keylimeregistrar[1426]: 2021-12-21 11:44:22.940 - keylime.registrar - DEBUG - returning 400 response. [...]

Such log spoofing could be used to entice Administrators to perform actions that can be harmful or otherwise in the interest of an attacker.

My recommendation is on the one hand to diligently sanitize untrusted input parameters. On the other hand it might make sense to authenticate this currently untrusted interface.

Upstream Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-87gh-qc28-j9mm

Upstream Fixes

The UUID sanitazion is introduced via these commits:

https://github.com/keylime/keylime/commit/387e320dc22c89f4f47c68cb37eb9eec2137f34b https://github.com/keylime/keylime/commit/e429e95329fc60608713ddfb82f4a92ee3b3d2d9 https://github.com/keylime/keylime/commit/65c2b737129b5837f4a03660aeb1191ced275a57

Otherwise the introduction of mTLS as outlined in issues 3.a) and 2.c) further protect this.

4) Findings in the Verifier Component =====================================

a) Revocation Notifier Uses Fixed /tmp Path for UNIX Domain Socket (CVE-2022-23950) -----------------------------------------------------------------------------------

In revocationnotifier.py a fixed path in the world writable location /tmp/keylime.verifier.ipc is used. The code (in this case the third party zeromq Python module) forcefully removes any file object found there earlier. Should the program be running as non-root, or if another local user simply places a directory at this location, then this serves as a local DoS attack against the revocation notifier process, because the socket cannot be created.

This situation doesn't even seem to be noticed by the Verifier main process, because the child process brokerproc is never waited on. This means that the local attacker could even replace the "blocking" directory by his own UNIX domain socket later on and will then receive revocation events from invocations of the notify() function in the main Verifier process. The full impact of this would have to be researched further. It looks like failed quote notifications would longer be sent out.

I recommend to place UNIX domains sockets in a dedicated safe directory in /run that cannot be staged with attacks by other local users in the system.

Upstream Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-9r9r-f8xc-m875

Upstream Fixes

This fix places the socket into a private /run/keylime directory:

https://github.com/keylime/keylime/commit/ea5d0373fa2c050d5d95404eb779be7e8327b911

b) Get Quote Response Contains Possibly Untrusted ZIP Data (CVE-2022-23951) ---------------------------------------------------------------------------

The Verifier process periodically performs quote operations on registered Agents. As part of this processquoteresponse() is called and furthermore checkquote() and finally tpm2checkquote(). In tpmmain.py:1018 a couple of ZIP data streams are uncompressed via zlib.decompress().

Since this is processing possibly untrusted data - the Verifier is attempting to verify the current trust status of the node after all - it needs to be assumed that malicous data can also be supplied here.

Therefore the question arises whether zlib.decompress() is robust against processing invalid ZIP data streams. One thing I already found out is that it is not robust against delivering ZIP bombs that will cause a memory exhaustion in the Verifier process.

This finding also is valid similarly for all other Keylime interface that process ZIP data, like in the Agent.

Upstream Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-6xx7-m45w-76m2

Upstream Fixes

This fix simply removes the ZIP compression from the Verifier interface:

https://github.com/keylime/keylime/commit/6e44758b64b0ee13564fc46e807f4ba98091c355

5) General Findings ===================

This section contains findings that apply to all keylime components alike.

a) World-Readable keylime.conf Contains Potentially Sensitive Data (CVE-2022-23952) -----------------------------------------------------------------------------------

The configuration /etc/keylime.conf is installed world-readable:

$ ls -l /etc/keylime.conf -rw-r--r-- 1 root root 26770 Dec 16 14:54 /etc/keylime.conf

This is the case for installations performed manually via the provided installer.sh script as well as for the RPM packaging found in both openSUSE Tumbleweed and Fedora 35 Linux distributions. Further distributions might be affected.

keylime.conf contains a lot of information, some of it sensitive like the TPM ownership password (tpmownerpassword), TLS certificate private key passwords (privatekeypw, registrarprivatekeypw) or the database password for the Registrar (databasepassword). Thus this is a local information leak, because arbitrary local users can obtain these passwords from the configuration file.

My recommendation is to make this file only accessible to root and adjust all installation routines and possibly documentation. The Keylime code could perform a sanity check of the permissions of the configuration file before reading it in.

Upstream Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-fchm-5w2v-qfm8

Upstream Fixes

The following fix explicitly sets the permissions for the configuration file in the installer:

https://github.com/keylime/keylime/commit/883085d6a4bcea3012729014d5b8e15ecd65fc7c

b) Lack of Privilege Separation -------------------------------

All keylime services are currently designed to run as root all the time (except for testing purposes, see REQUIREROOT in config.py). Only few bits of the keylime components actually should need root privileges. Most notably the bootstrapping scripts in the Agent component or the ability to bind privileged ports.

Implementing a privilege separation approach would increase the defense in depth for keylime considerably, avoiding smaller security issues to become severe fast.

Upstream Statement

Keylime upstream states that it is already possible to run Keylime as non-root. The REQUIREROOT bits are not strictly necessary any more and can be removed from the code. The Debian packaging already makes use of the privilege separation.

6) Timeline ===========

2021-12-09: I started the review on the code 2021-12-23: I contacted the upstream security contact and upstream developer Thore Sommer privately by email and provided them the report results, offering coordinates disclosure. 2022-01-04: Upstream confirmed most of my findings and work on the fixes began. Alberto Planas, a SUSE colleague and maintainer of the SUSE Keylime packaging also contributed some fixes. 2022-01-28: Publication of the security advisories and fixes by upstream took place. Upstream also discovered some further security issues themselves in the meanwhile.

[1]: https://github.com/keylime/keylime [2]: https://www.openwall.com/lists/oss-security/2020/06/04/5 [3]: https://www.ll.mit.edu/sites/default/files/publication/doc/2018-04/20161207SchearNACSACFP.pdf

Cheers

Matthias

-- Matthias Gerstner <matthias.gerstner () suse de> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Ivo Totev

A flaw was found in keylime 5.8.1 and older. The issue in the Keylime agent and registrar code invalidates the cryptographic chain of trust from the Endorsement Key certificate to agent attestations.