CVE-2023-43631 – SSH as Root Unlockable Without Triggering Measured Boot
https://notcve.org/view.php?id=CVE-2023-43631
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. Al arrancar, el contenedor Pillar eve comprueba la existencia y el contenido de “/config/authorized_keys”. Si el archivo está presente y contiene una clave pública compatible, el contenedor abrirá el puerto 22 y habilitará sshd con las claves proporcionadas como claves autorizadas para el inicio de sesión de root. Un atacante podría agregar fácilmente sus propias claves y obtener control total sobre el sistema sin activar el mecanismo de ""measured boot"" implementado por EVE OS y sin marcar el dispositivo como ""UUD"" (""Actualización Desconocida Detectada""). Esto se debe a que la partición “/config” no está protegida por “measured boot”, es mutable y no está cifrada de ninguna manera. • https://asrg.io/security-advisories/cve-2023-43631 • CWE-522: Insufficiently Protected Credentials CWE-922: Insecure Storage of Sensitive Information •
CVE-2023-43632 – Freely Allocate Buffer on The Stack With Data From Socket
https://notcve.org/view.php?id=CVE-2023-43632
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. Como se indica en el archivo “VTPM.md” en la documentación de eve, “VTPM es un servidor que escucha en el puerto 8877 en EVE, lo que expone la funcionalidad limitada del TPM a los clientes. VTPM permite a los clientes ejecutar binarios de tpm2-tools a partir de una lista de opciones codificadas. • https://asrg.io/security-advisories/cve-2023-43632 • CWE-770: Allocation of Resources Without Limits or Throttling CWE-789: Memory Allocation with Excessive Size Value •
CVE-2023-43635 – Vault Key Sealed With SHA1 PCRs
https://notcve.org/view.php?id=CVE-2023-43635
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 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. Vault Key Sealed With SHA1 PCRs La solución de arranque medido implementada en EVE OS se apoya en un mecanismo de bloqueo de PCR. Diferentes partes del sistema actualizan diferentes valores de PCR en el TPM, lo que da como resultado un valor único para cada entrada de PCR. Estos PCR se utilizan luego para sellar/abrir una clave del TPM que se utiliza para cifrar/descifrar el directorio "vault". Este directorio "vault" es el punto más sensible del sistema y, como tal, su contenido debe estar protegido. • https://asrg.io/security-advisories/cve-2023-43635 • CWE-327: Use of a Broken or Risky Cryptographic Algorithm CWE-328: Use of Weak Hash CWE-522: Insufficiently Protected Credentials •
CVE-2023-43636 – Rootfs Not Protected
https://notcve.org/view.php?id=CVE-2023-43636
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. En EVE OS, el mecanismo de "measured boot" evita que un dispositivo comprometido acceda a los datos cifrados ubicados en la bóveda. Según el diseño de “measured boot”, los valores de PCR calculados en diferentes etapas del proceso de arranque cambiarán si se cambia alguna de sus respectivas partes. Esto incluye, entre otras cosas, la configuración de BIOS, grub, cmdline del kernel, initrd y más. Sin embargo, este mecanismo no valida todos los rootfs, por lo que un atacante puede editar el sistema de archivos y obtener control sobre el sistema. • https://asrg.io/security-advisories/cve-2023-43636 • CWE-345: Insufficient Verification of Data Authenticity •