Page 4 of 294 results (0.005 seconds)

CVSS: 8.8EPSS: 0%CPEs: 2EXPL: 0

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 •

CVSS: 9.9EPSS: 0%CPEs: 1EXPL: 0

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 •

CVSS: 8.8EPSS: 0%CPEs: 1EXPL: 0

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 •

CVSS: 8.8EPSS: 0%CPEs: 2EXPL: 0

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 •

CVSS: 8.8EPSS: 0%CPEs: 1EXPL: 0

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 gaining full control over the device with full access to the contents of the encrypted “vault” PCR14 no está en la lista de PCRs que sella/abre la clave de “vault”, pero debido al cambio que se implementó en el commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, solucionar este problema por sí solo no resolvería el problema de que la partición de configuración no se mida correctamente. Además, la clave de la "vault" se sella/se abre con PCRs SHA1 en lugar de SHA256. Este problema se mitigó en cierta medida debido a que todas las funciones de extensión de PCR actualizaron los valores de SHA256 y SHA1 para una ID de PCR determinada. Sin embargo, debido al cambio que se implementó en el commit "7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4", este ya no es el caso para PCR14, ya que el código en "measurefs.go" actualiza explícitamente solo la instancia SHA256 de PCR14, lo que significa que incluso si PCR14 fuera Si se agregara a la lista de PCRs que sellan o abren la clave de “vault”, los cambios en la partición de configuración aún no se medirían. Un atacante podría modificar la partición de configuración sin activar el arranque medido, lo que podría dar como resultado que el atacante obtenga control total sobre el dispositivo con acceso completo al contenido de la "vault" cifrada. • https://asrg.io/security-advisories/cve-2023-43630 • CWE-328: Use of Weak Hash CWE-522: Insufficiently Protected Credentials CWE-922: Insecure Storage of Sensitive Information •