CVE Vulnerabilities

CVE-2023-43635

Use of Weak Hash

Published: Sep 20, 2023 | Modified: Nov 21, 2024
CVSS 3.x
8.8
HIGH
Source:
NVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.x
RedHat/V2
RedHat/V3
Ubuntu

Vault Key Sealed With SHA1 PCRs

The measured boot solution implemented in EVE OS leans on a PCR locking mechanism.

Different parts of the system update different PCR values in the TPM, resulting in a unique value for each PCR entry.

These PCRs are then used in order to seal/unseal a key from the TPM which is used to encrypt/decrypt the “vault” directory.

This “vault” directory is the most sensitive point in the system and as such, its content should be protected.

This mechanism is noted in Zededa’s documentation as the “measured boot” mechanism, designed to protect said “vault”.

The code that’s responsible for generating and fetching the key from the TPM assumes that SHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being checked.

The issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs. This leads to several issues:

• Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well as not sealing their keys at all, meaning the “vault” is not protected from an attacker.

• SHA1 is considered insecure and reduces the complexity level required to unseal the key in machines which have their SHA1 PCRs enabled.

An attacker can very easily retrieve the contents of the “vault”, which will effectively render the “measured boot” mechanism meaningless.

Weakness

The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).

Affected Software

Name Vendor Start Version End Version
Edge_virtualization_engine Linuxfoundation * 9.5.0 (excluding)

Extended Description

A hash function is defined as an algorithm that maps arbitrarily sized data into a fixed-sized digest (output) such that the following properties hold:

     Building on this definition, a cryptographic hash function must also ensure that a malicious actor cannot leverage the hash function to have a reasonable chance of success at determining any of the following:

What is regarded as “reasonable” varies by context and threat model, but in general, “reasonable” could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world. Any algorithm does not meet the above conditions will generally be considered weak for general use in hashing. In addition to algorithmic weaknesses, a hash function can be made weak by using the hash in a security context that breaks its security guarantees. For example, using a hash function without a salt for storing passwords (that are sufficiently short) could enable an adversary to create a “rainbow table” [REF-637] to recover the password under certain conditions; this attack works against such hash functions as MD5, SHA-1, and SHA-2.

Potential Mitigations

  • Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations (“stretching”) or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.
  • Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.
  • Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment’s needs.

References