Vulnerabilities

The `PaperCutNG Mobility Print` version 1.0.3512 application allows an<br /> <br /> unauthenticated attacker to perform a CSRF attack on an instance<br /> <br /> administrator to configure the clients host (in the "configure printer<br /> <br /> discovery" section). This is possible because the application has no<br /> <br /> protections against CSRF attacks, like Anti-CSRF tokens, header origin<br /> <br /> validation, samesite cookies, etc.<br /> <br /> <br /> <br />

Use of a static key to protect a JWT token used in user authentication can allow an for an authentication bypass in D-Link D-View 8 v2.0.1.28

<br /> <br /> <br /> In EVE OS, the “measured boot” mechanism prevents a compromised device from accessing<br /> the encrypted data located in the vault.<br /> <br /> As per the “measured boot” design, the PCR values calculated at different stages of the boot<br /> process will change if any of their respective parts are changed.<br /> <br /> This includes, among other things, the configuration of the bios, grub, the kernel cmdline,<br /> initrd, and more.<br /> <br /> However, this mechanism does not validate the entire rootfs, so an attacker can edit the<br /> filesystem and gain control over the system.<br /> <br /> As the default filesystem used by EVE OS is squashfs, this is somewhat harder than an ext4,<br /> which is easily changeable.<br /> <br /> This will not stop an attacker, as an attacker can repackage the squashfs with their changes<br /> in it and replace the partition altogether.<br /> <br /> This can also be done directly on the device, as the “003-storage-init” container contains the<br /> “mksquashfs” and “unsquashfs” binaries (with the corresponding libs).<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> An attacker can gain full control over the device without changing the PCR values, thus not<br /> triggering the “measured boot” mechanism, and having full access to the vault.<br /> <br /> <br /> <br /> Note:<br /> <br /> This issue was partially fixed in these commits (after disclosure to Zededa), where the config<br /> partition measurement was added to PCR13:<br /> <br /> • aa3501d6c57206ced222c33aea15a9169d629141<br /> <br /> • 5fef4d92e75838cc78010edaed5247dfbdae1889.<br /> <br /> 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.

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.

A flaw was found in the offline_access scope in Keycloak. This issue would affect users of shared computers more (especially if cookies are not cleared), due to a lack of root session validation, and the reuse of session ids across root and user authentication sessions. This enables an attacker to resolve a user session attached to a previously authenticated user; when utilizing the refresh token, they will be issued a token for the original user.

PCR14 is not in the list of PCRs that seal/unseal the “vault” key, but<br /> due to the change that was implemented in commit<br /> “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, fixing this issue alone would not solve the<br /> problem of the config partition not being measured correctly.<br /> <br /> Also, the “vault” key is sealed/unsealed with SHA1 PCRs instead of<br /> SHA256. <br /> This issue was somewhat mitigated due to all of the PCR extend functions<br /> updating both the values of SHA256 and SHA1 for a given PCR ID.<br /> <br /> However, due to the change that was implemented in commit<br /> “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, this is no longer the case for PCR14, as<br /> the code in “measurefs.go” explicitly updates only the SHA256 instance of PCR14, which<br /> means that even if PCR14 were to be added to the list of PCRs sealing/unsealing the “vault”<br /> key, changes to the config partition would still not be measured.<br /> <br /> <br /> <br /> An attacker could modify the config partition without triggering the measured boot, this could<br /> result in the attacker gaining full control over the device with full access to the contents of the<br /> encrypted “vault” <br /> <br /> <br /> <br /> <br />

<br /> Vault Key Sealed With SHA1 PCRs<br /> <br /> <br /> <br /> <br /> <br /> <br /> The measured boot solution implemented in EVE OS leans on a PCR locking mechanism.<br /> <br /> Different parts of the system update different PCR values in the TPM, resulting in a unique<br /> value for each PCR entry.<br /> <br /> These PCRs are then used in order to seal/unseal a key from the TPM which is used to<br /> encrypt/decrypt the “vault” directory.<br /> <br /> This “vault” directory is the most sensitive point in the system and as such, its content should<br /> be protected.<br /> <br /> This mechanism is noted in Zededa’s documentation as the “measured boot” mechanism,<br /> designed to protect said “vault”.<br /> <br /> The code that’s responsible for generating and fetching the key from the TPM assumes that<br /> SHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being<br /> checked.<br /> <br /> The issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.<br /> This leads to several issues:<br /> <br /> • Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well<br /> as not sealing their keys at all, meaning the “vault” is not protected from an attacker.<br /> <br /> • SHA1 is considered insecure and reduces the complexity level required to unseal the<br /> key in machines which have their SHA1 PCRs enabled.<br /> <br /> <br /> <br /> An attacker can very easily retrieve the contents of the “vault”, which will effectively render<br /> the “measured boot” mechanism meaningless.<br /> <br /> <br /> <br /> <br /> <br />

fake_upload.cgi on the Telstra Smart Modem Gen 2 (Arcadyan LH1000), firmware versions

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

D-LINK DWL-6610 FW_v_4.3.0.8B003C was discovered to contain a command injection vulnerability in the function pcap_download_handler. This vulnerability allows attackers to execute arbitrary commands via the update.device.packet-capture.tftp-file-name parameter.

D-LINK DWL-6610 FW_v_4.3.0.8B003C was discovered to contain a stack overflow vulnerability in the function update_users.

D-LINK DWL-6610 FW_v_4.3.0.8B003C was discovered to contain a command injection vulnerability in the function sub_2EF50. This vulnerability allows attackers to execute arbitrary commands via the manual-time-string parameter.