CVE

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.

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.

When sealing/unsealing the “vault” key, a list of PCRs is used, which defines which PCRs are used. In a previous project, CYMOTIVE found that the configuration is not protected by the secure boot, and in response Zededa implemented measurements on the config partition that was mapped to PCR 13. In that process, PCR 13 was added to the list of PCRs that seal/unseal the key. In commit “56e589749c6ff58ded862d39535d43253b249acf”, the config partition measurement moved from PCR 13 to PCR 14, but PCR 14 was not added to the list of PCRs that seal/unseal the key. This change makes the measurement of PCR 14 effectively redundant as it would not affect the sealing/unsealing of the key. 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”

When sealing/unsealing the “vault” key, a list of PCRs is used, which defines which PCRs are used. In a previous project, CYMOTIVE found that the configuration is not protected by the secure boot, and in response Zededa implemented measurements on the config partition that was mapped to PCR 13. In that process, PCR 13 was added to the list of PCRs that seal/unseal the key. In commit “56e589749c6ff58ded862d39535d43253b249acf”, the config partition measurement moved from PCR 13 to PCR 14, but PCR 14 was not added to the list of PCRs that seal/unseal the key. This change makes the measurement of PCR 14 effectively redundant as it would not affect the sealing/unsealing of the key. 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”

Due to the implementation of "deriveVaultKey", prior to version 7.10, the generated vault key would always have the last 16 bytes predetermined to be "arfoobarfoobarfo". This issue happens because "deriveVaultKey" calls "retrieveCloudKey" (which will always return "foobarfoobarfoobarfoobarfoobarfo" as the key), and then merges the 32byte randomly generated key with this key (by takeing 16bytes from each, see "mergeKeys"). This makes the key a lot weaker. This issue does not persist in devices that were initialized on/after version 7.10, but devices that were initialized before that and updated to a newer version still have this issue. Roll an update that enforces the full 32bytes key usage.

Due to the implementation of "deriveVaultKey", prior to version 7.10, the generated vault key would always have the last 16 bytes predetermined to be "arfoobarfoobarfo". This issue happens because "deriveVaultKey" calls "retrieveCloudKey" (which will always return "foobarfoobarfoobarfoobarfoobarfo" as the key), and then merges the 32byte randomly generated key with this key (by takeing 16bytes from each, see "mergeKeys"). This makes the key a lot weaker. This issue does not persist in devices that were initialized on/after version 7.10, but devices that were initialized before that and updated to a newer version still have this issue. Roll an update that enforces the full 32bytes key usage.

D-Link DIR-816 A2 v1.10CNB05 was discovered to contain a stack overflow via parameter sip_address in ipportFilter.

OpenHarmony v3.2.1 and prior version has a liteos-a kernel may crash caused by mqueue undetected entries vulnerability. Local attackers can crash liteos-a kernel by the error input 

Improper Input Validation in GitHub repository nocodb/nocodb prior to 0.96.0.

In Eclipse RAP versions from 3.0.0 up to and including 3.25.0, Remote Code Execution is possible on Windows when using the FileUpload component. The reason for this is a not completely secure extraction of the file name in the FileUploadProcessor.stripFileName(String name) method. As soon as this finds a / in the path, everything before it is removed, but potentially \ (backslashes) coming further back are kept. For example, a file name such as /..\..\webapps\shell.war can be used to upload a file to a Tomcat server under Windows, which is then saved as ..\..\webapps\shell.war in its webapps directory and can then be executed.