CVE-2025-46733

{"id": "CVE-2025-46733", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "CHANGED", "version": "3.1", "baseScore": 7.9, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L", "integrityImpact": "LOW", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "LOW", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.3, "exploitabilityScore": 2.0}]}, "published": "2025-07-04T14:15:33.217", "references": [{"url": "https://github.com/OP-TEE/optee_os/commit/941a58d78c99c4754fbd4ec3079ec9e1d596af8f", "source": "security-advisories@github.com"}, {"url": "https://github.com/OP-TEE/optee_os/security/advisories/GHSA-f35r-hm2m-p6c3", "source": "security-advisories@github.com"}, {"url": "https://github.com/OP-TEE/optee_os/security/advisories/GHSA-f35r-hm2m-p6c3", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-755"}]}], "descriptions": [{"lang": "en", "value": "OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. In version 4.5.0, using a specially crafted tee-supplicant binary running in REE userspace, an attacker can trigger a panic in a TA that uses the libutee Secure Storage API. Many functions in libutee, specifically those which make up the Secure Storage API, will panic if a system call returns an unexpected return code. This behavior is mandated by the TEE Internal Core API specification. However, in OP-TEE\u2019s implementation, return codes of secure storage operations are passed through unsanitized from the REE tee-supplicant, through the Linux kernel tee-driver, through the OP-TEE kernel, back to libutee. Thus, an attacker with access to REE userspace, and the ability to stop tee-supplicant and replace it with their own process (generally trivial for a root user, and depending on the way permissions are set up, potentially available even to less privileged users) can run a malicious tee-supplicant process that responds to storage requests with unexpected response codes, triggering a panic in the requesting TA. This is particularly dangerous for TAs built with `TA_FLAG_SINGLE_INSTANCE` (corresponding to `gpd.ta.singleInstance` and `TA_FLAG_INSTANCE_KEEP_ALIVE` (corresponding to `gpd.ta.keepAlive`). The behavior of these TAs may depend on memory that is preserved between sessions, and the ability of an attacker to panic the TA and reload it with a clean memory space can compromise the behavior of those TAs. A critical example of this is the optee_ftpm TA. It uses the kept alive memory to hold PCR values, which crucially must be non-resettable. An attacker who can trigger a panic in the fTPM TA can reset the PCRs, and then extend them PCRs with whatever they choose, falsifying boot measurements, accessing sealed data, and potentially more. The impact of this issue depends significantly on the behavior of affected TAs. For some, it could manifest as a denial of service, while for others, like the fTPM TA, it can result in the disclosure of sensitive data. Anyone running the fTPM TA is affected, but similar attacks may be possible on other TAs that leverage the Secure Storage API. A fix is available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f."}, {"lang": "es", "value": "OP-TEE es un Entorno de Ejecuci\u00f3n Confiable (TEE) dise\u00f1ado para complementar un kernel Linux no seguro que se ejecuta en n\u00facleos Arm; los n\u00facleos Cortex-A utilizan la tecnolog\u00eda TrustZone. En la versi\u00f3n 4.5.0, mediante un binario tee-supplicant especialmente manipulado que se ejecuta en el espacio de usuario de REE, un atacante puede generar un p\u00e1nico en un TA que utiliza la API de Almacenamiento Seguro de libutee. Muchas funciones de libutee, en particular las que conforman la API de Almacenamiento Seguro, entrar\u00e1n en p\u00e1nico si una llamada al sistema devuelve un c\u00f3digo de retorno inesperado. Este comportamiento est\u00e1 estipulado por la especificaci\u00f3n de la API del N\u00facleo Interno de TEE. Sin embargo, en la implementaci\u00f3n de OP-TEE, los c\u00f3digos de retorno de las operaciones de almacenamiento seguro se transfieren sin sanear desde el tee-supplicant de REE, a trav\u00e9s del controlador tee del kernel de Linux, a trav\u00e9s del kernel de OP-TEE, de vuelta a libutee. De este modo, un atacante con acceso al espacio de usuario REE y la capacidad de detener tee-supplicant y reemplazarlo con su propio proceso (generalmente trivial para un usuario root y, dependiendo de la forma en que se configuren los permisos, potencialmente disponible incluso para usuarios menos privilegiados) puede ejecutar un proceso tee-supplicant malicioso que responde a las solicitudes de almacenamiento con c\u00f3digos de respuesta inesperados, lo que provoca p\u00e1nico en el TA solicitante. Esto es particularmente peligroso para los TA creados con `TA_FLAG_SINGLE_INSTANCE` (que corresponde a `gpd.ta.singleInstance` y `TA_FLAG_INSTANCE_KEEP_ALIVE` (que corresponde a `gpd.ta.keepAlive`). El comportamiento de estos TA puede depender de la memoria que se conserva entre sesiones, y la capacidad de un atacante de generar p\u00e1nico en el TA y recargarlo con un espacio de memoria limpio puede comprometer el comportamiento de esos TA. Un ejemplo cr\u00edtico de esto es el TA optee_ftpm. Utiliza la memoria viva mantenida para almacenar valores de PCR, que crucialmente deben ser no reiniciables. Un atacante que puede provocar un p\u00e1nico en el TA fTPM puede reiniciar los PCR y luego extenderlos con lo que elija, falsificando mediciones de arranque, accediendo a datos sellados y potencialmente m\u00e1s. El impacto de este problema depende significativamente del comportamiento de los TA afectados. Para algunos, podr\u00eda manifestarse como una denegaci\u00f3n de servicio, mientras que para otros, como el TA fTPM, Puede resultar en la divulgaci\u00f3n de datos confidenciales. Cualquier usuario de la TA fTPM se ve afectado, pero podr\u00edan producirse ataques similares en otras TA que utilizan la API de Almacenamiento Seguro. Hay una soluci\u00f3n disponible en el commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f."}], "lastModified": "2025-07-08T16:18:53.607", "sourceIdentifier": "security-advisories@github.com"}