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.

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

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 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.

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.

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, Revocation Notifier uses a fixed /tmp path for UNIX domain socket which can allow unprivileged users a method to prohibit keylime operations.

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

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

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.

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