CVE

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

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

A Type Confusion vulnerability was found in the Spotlight RPC functions in afpd in Netatalk 3.1.x before 3.1.17. When parsing Spotlight RPC packets, one encoded data structure is a key-value style dictionary where the keys are character strings, and the values can be any of the supported types in the underlying protocol. Due to a lack of type checking in callers of the dalloc_value_for_key() function, which returns the object associated with a key, a malicious actor may be able to fully control the value of the pointer and theoretically achieve Remote Code Execution on the host. This issue is similar to CVE-2023-34967.

An arbitrary code execution flaw was found in Foreman. This flaw allows an admin user to bypass safe mode in templates and execute arbitrary code on the underlying operating system.

An arbitrary code execution flaw was found in Foreman. This issue may allow an admin user to execute arbitrary code on the underlying operating system by setting global parameters with a YAML payload.

A flaw was found in Keycloak. Under specific circumstances, HTML entities are not sanitized during user impersonation, resulting in a Cross-site scripting (XSS) vulnerability.

An XPC misconfiguration vulnerability in CoreCode MacUpdater before 2.3.8, and 3.x before 3.1.2, allows attackers to escalate privileges by crafting malicious .pkg files.

D-Link device DI-7200GV2.E1 v21.04.09E1 was discovered to contain a stack overflow via the popupId parameter in the H5/hi_block.asp function.

D-Link device DI-7200GV2.E1 v21.04.09E1 was discovered to contain a stack overflow via the prev parameter in the H5/login.cgi function.

D-Link device DI-7200GV2.E1 v21.04.09E1 was discovered to contain a stack overflow via the id parameter in the yyxz.data function.