Ilay Levi

**Name of the Vulnerable Software and Affected Versions** Renesas arm-trusted-firmware versions prior to the fixed version **Description** The issue is related to a Buffer Copy without Checking Size of Input, also known as a 'Classic Buffer Overflow', which allows Local Execution of Code. This is associated with program files in the Renesas arm-trusted-firmware. Specifically, in line 313, `addr loaded cnt` is checked not to be `CHECK IMAGE AREA CNT` (5) or larger, but this check does not halt the function. Immediately after, in line 317, there will be an overflow in the buffer, and the value of `dst` will be written to the area immediately after the buffer, which is `addr loaded cnt`. This allows an attacker to freely control the value of `addr loaded cnt` and thus control the destination of the write immediately after, in line 318, with whichever address and whichever value (`len`) they desire. **Recommendations** As a temporary workaround, consider disabling the vulnerable function until a patch is available. Restrict access to the vulnerable module to minimize the risk of exploitation. Avoid using the `dst` and `len` parameters in the affected code until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Pillar eve container versions 9.0.0 and earlier **Description** The Pillar eve container checks for the existence and content of `/config/authorized keys` on boot. If the file is present and contains a supported public key, the container opens port 22 and enables sshd with the given keys as the authorized keys for root login. An attacker can add their own keys and gain full control over the system without triggering the "measured boot" mechanism or marking the device as "UUD" ("Unknown Update Detected"). This is because the `/config` partition is not protected by "measured boot", is mutable, and is not encrypted. 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. **Recommendations** For versions 9.0.0 and earlier, consider disabling the `/config/authorized keys` file or restricting access to it until a patch is available. As a temporary workaround, restrict access to the `/config` partition to minimize the risk of exploitation. Note that this issue was partially fixed in certain commits, but the fix is not included in version 9.0.0. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** EVE (affected versions not specified) **Description** The issue concerns a server listening on port 8877 in EVE, exposing limited functionality of the TPM to clients. This server, known as 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 two parts: a header and data. When a connection is made, the server waits for 4 bytes of data, which will be the header, and these 4 bytes are parsed as uint32 size of the actual data to come. Then, in the function `handleRequest`, this size is used 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 or gain control over the system, specifically on the `vtpm server` process, which has very high privileges. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Pillar eve container versions 9.0.0 and later, prior to the inclusion of the config partition measurement in PCR13 **Description** The Pillar eve container checks for the existence and content of `/config/GlobalConfig/global.json` on boot. If the file exists, it overrides the existing configuration on the device, allowing an attacker to change the system's configuration, including debug functions. This could be used to unlock ssh with custom `authorized keys` via the `debug.enable.ssh` key, unlock the usb to enable the keyboard via the `debug.enable.usb` key, or allow VNC access via the `app.allow.vnc` key. An attacker can gain full control over the device without triggering the measured boot mechanism and have full access to the vault. The `/config` partition is not protected by measured boot, is mutable, and is not encrypted. **Recommendations** For versions 9.0.0 and later, prior to the inclusion of the config partition measurement in PCR13, consider disabling the `debug.enable.ssh` and `debug.enable.usb` keys to prevent unauthorized access. Restrict access to the `/config/GlobalConfig/global.json` file to minimize the risk of exploitation. Avoid using the `app.allow.vnc` key in the affected configuration file until the issue is resolved. As a temporary workaround, consider restricting access to the vault until a patch is available. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Zededa (affected versions not specified) **Description** The issue arises from a change in the configuration partition measurement from PCR 13 to PCR 14, without updating the list of PCRs used for sealing and unsealing the "vault" key. This makes the measurement of PCR 14 redundant and allows an attacker to modify the config partition without triggering the measured boot. As a result, the attacker could gain full control over the device and access the contents of the encrypted "vault". **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** SoftwareX versions prior to 7.10 **Description** The issue arises from the implementation of `deriveVaultKey`, which generates a vault key with the last 16 bytes predetermined to be "arfoobarfoobarfo". This occurs because `deriveVaultKey` calls `retrieveCloudKey`, returning "foobarfoobarfoobarfoobarfoobarfo" as the key, and then merges the 32-byte randomly generated key with this key using `mergeKeys`. This makes the key weaker. Devices initialized before version 7.10 and updated to a newer version still have this issue. **Recommendations** For versions prior to 7.10, roll an update that enforces the full 32bytes key usage. As a temporary workaround, consider restricting the usage of the `deriveVaultKey` function until a patch is available.

**Name of the Vulnerable Software and Affected Versions** EVE OS versions 9.0.0 and earlier **Description** The "measured boot" mechanism in EVE OS is designed to prevent a compromised device from accessing the encrypted data located in the vault. However, this mechanism does not validate the entire rootfs, allowing an attacker to edit the filesystem and gain control over the system. The default filesystem used by EVE OS is squashfs, which makes it somewhat harder for an attacker to make changes compared to an ext4 filesystem. Nevertheless, an attacker can repackage the squashfs with their changes and replace the partition altogether, potentially using the "mksquashfs" and "unsquashfs" binaries available in the "003-storage-init" container. This can be done directly on the device, enabling the attacker to 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. **Recommendations** For EVE OS version 9.0.0 and earlier, consider applying the commits that add the config partition measurement to PCR13, specifically aa3501d6c57206ced222c33aea15a9169d629141 and 5fef4d92e75838cc78010edaed5247dfbdae1889, to partially fix the issue. As a temporary workaround, restrict access to the "003-storage-init" container and the "mksquashfs" and "unsquashfs" binaries to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** No specific software or versions are mentioned in the provided descriptions. **Description** The issue concerns a problem where PCR14 is not in the list of PCRs that seal/unseal the "vault" key. Due to a change implemented in a commit, fixing this issue alone would not solve the problem of the config partition not being measured correctly. The "vault" key is sealed/unsealed with SHA1 PCRs instead of SHA256. This issue was somewhat mitigated because all PCR extend functions updated both SHA256 and SHA1 values for a given PCR ID. However, the change in the commit means that only the SHA256 instance of PCR14 is updated, which would still not measure changes to the config partition even if PCR14 were added to the list of PCRs sealing/unsealing the "vault" key. An attacker could modify the config partition without triggering the measured boot, potentially gaining full control over the device with access to the encrypted "vault". **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** EVE OS (affected versions not specified) **Description** The measured boot solution in EVE OS uses a PCR locking mechanism to protect the "vault" directory, which is the most sensitive point in the system. However, the key used to encrypt/decrypt the "vault" is sealed using SHA1 PCRs instead of SHA256 PCRs, which is considered insecure. This leads to issues where machines with SHA256 PCRs enabled but SHA1 PCRs disabled are not protected, and attackers can easily retrieve the contents of the "vault". The use of SHA1 PCRs reduces the complexity level required to unseal the key, making it easier for attackers to access the "vault". **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.