Linux Foundation Edge Virtualization Engine
By the Year
In 2024 there have been 0 vulnerabilities in Linux Foundation Edge Virtualization Engine . Last year Edge Virtualization Engine had 5 security vulnerabilities published. Right now, Edge Virtualization Engine is on track to have less security vulnerabilities in 2024 than it did last year.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2024 | 0 | 0.00 |
| 2023 | 5 | 9.02 |
| 2022 | 0 | 0.00 |
| 2021 | 0 | 0.00 |
| 2020 | 0 | 0.00 |
| 2019 | 0 | 0.00 |
| 2018 | 0 | 0.00 |
It may take a day or so for new Edge Virtualization Engine vulnerabilities to show up in the stats or in the list of recent security vulnerabilties. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Linux Foundation Edge Virtualization Engine Security Vulnerabilities
As noted in the VTPM.md file in the eve documentation
CVE-2023-43632
9.9 - Critical
- September 21, 2023
As noted in the VTPM.md file in the eve documentation, VTPM is a server listening on port 8877 in EVE, exposing limited functionality of the TPM to the clients. VTPM allows clients to execute tpm2-tools binaries from a list of hardcoded options The communication with this server is done using protobuf, and the data is comprised of 2 parts: 1. Header 2. Data When a connection is made, the server is waiting for 4 bytes of data, which will be the header, and these 4 bytes would be parsed as uint32 size of the actual data to come. Then, in the function handleRequest this size is then used in order to allocate a payload on the stack for the incoming data. As this payload is allocated on the stack, this will allow overflowing the stack size allocated for the relevant process with freely controlled data. * An attacker can crash the system. * An attacker can gain control over the system, specifically on the vtpm_server process which has very high privileges.
Allocation of Resources Without Limits or Throttling
On boot, the Pillar eve container checks for the existence and content of
/config/authorized_keys
CVE-2023-43631
8.8 - High
- September 21, 2023
On boot, the Pillar eve container checks for the existence and content of /config/authorized_keys. If the file is present, and contains a supported public key, the container will go on to open port 22 and enable sshd with the given keys as the authorized keys for root login. An attacker could easily add their own keys and gain full control over the system without triggering the measured boot mechanism implemented by EVE OS, and without marking the device as UUD (Unknown Update Detected). This is because the /config partition is not protected by measured boot, it is mutable, and it is not encrypted in any way. An attacker can gain full control over the device without changing the PCR values, thus not triggering the measured boot mechanism, and having full access to the vault. Note: This issue was partially fixed in these commits (after disclosure to Zededa), where the config partition measurement was added to PCR13: aa3501d6c57206ced222c33aea15a9169d629141 5fef4d92e75838cc78010edaed5247dfbdae1889. This issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot.
Insufficiently Protected Credentials
In EVE OS, the measured boot mechanism prevents a compromised device from accessing
the encrypted data located in the vault
CVE-2023-43636
8.8 - High
- September 20, 2023
In EVE OS, the measured boot mechanism prevents a compromised device from accessing the encrypted data located in the vault. As per the measured boot design, the PCR values calculated at different stages of the boot process will change if any of their respective parts are changed. This includes, among other things, the configuration of the bios, grub, the kernel cmdline, initrd, and more. However, this mechanism does not validate the entire rootfs, so an attacker can edit the filesystem and gain control over the system. As the default filesystem used by EVE OS is squashfs, this is somewhat harder than an ext4, which is easily changeable. This will not stop an attacker, as an attacker can repackage the squashfs with their changes in it and replace the partition altogether. This can also be done directly on the device, as the 003-storage-init container contains the mksquashfs and unsquashfs binaries (with the corresponding libs). An attacker can gain full control over the device without changing the PCR values, thus not triggering the measured boot mechanism, and having full access to the vault. Note: This issue was partially fixed in these commits (after disclosure to Zededa), where the config partition measurement was added to PCR13: aa3501d6c57206ced222c33aea15a9169d629141 5fef4d92e75838cc78010edaed5247dfbdae1889. This issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot.
Insufficient Verification of Data Authenticity
Vault Key Sealed With SHA1 PCRs
The measured boot solution implemented in EVE OS leans on a PCR locking mechanism
CVE-2023-43635
8.8 - High
- September 20, 2023
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 Zededas documentation as the measured boot mechanism, designed to protect said vault. The code thats 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.
Use of a Broken or Risky Cryptographic Algorithm
PCR14 is not in the list of PCRs
CVE-2023-43630
8.8 - High
- September 20, 2023
PCR14 is not in the list of PCRs that seal/unseal the vault key, but due to the change that was implemented in commit 7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4, fixing this issue alone would not solve the problem of the config partition not being measured correctly. Also, the vault key is sealed/unsealed with SHA1 PCRs instead of SHA256. This issue was somewhat mitigated due to all of the PCR extend functions updating both the values of SHA256 and SHA1 for a given PCR ID. However, due to the change that was implemented in commit 7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4, this is no longer the case for PCR14, as the code in measurefs.go explicitly updates only the SHA256 instance of PCR14, which means that even if PCR14 were to be added to the list of PCRs sealing/unsealing the vault key, changes to the config partition would still not be measured. An attacker could modify the config partition without triggering the measured boot, this could result in the attacker gaining full control over the device with full access to the contents of the encrypted vault
Insufficiently Protected Credentials
Stay on top of Security Vulnerabilities
Want an email whenever new vulnerabilities are published for Linux Foundation Edge Virtualization Engine or by Linux Foundation? Click the Watch button to subscribe.
