CVE-2025-46733 in optee_os
Summary
by MITRE • 07/04/2025
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’s 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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/04/2025
The vulnerability described in CVE-2025-46733 affects OP-TEE, a Trusted Execution Environment implementation designed to work alongside non-secure Linux kernels on Arm Cortex-A processors utilizing TrustZone technology. This flaw exists in version 4.5.0 and stems from improper handling of return codes within the Secure Storage API implementation. The issue arises when a maliciously crafted tee-supplicant binary executes in the Rich Execution Environment (REE) userspace, allowing an attacker to manipulate system calls that should normally be processed safely by the Trusted Application (TA) layer. The vulnerability is rooted in the TEE Internal Core API specification which mandates that certain functions panic upon unexpected return codes, but this behavior is exacerbated by the unsanitized propagation of these codes through multiple system layers including REE userspace, Linux kernel tee-driver, OP-TEE kernel, and finally back to libutee. This chain of code propagation creates a critical security gap where an attacker with access to REE userspace can substitute the legitimate tee-supplicant with a malicious version that deliberately returns unexpected codes.
The operational impact of this vulnerability is severe and multifaceted, particularly when targeting TAs built with specific flags such as `TA_FLAG_SINGLE_INSTANCE` and `TA_FLAG_INSTANCE_KEEP_ALIVE`. These TAs maintain persistent memory states between sessions, which becomes compromised when the TA panics and restarts with a clean memory space. The behavior of these TAs is particularly concerning because they may depend on preserved memory for critical operations, making them vulnerable to manipulation that could alter their operational integrity. The most significant example is the optee_ftpm TA which uses kept-alive memory to store PCR values that must remain non-resettable for security purposes. When an attacker triggers a panic in this TA, they can reset PCRs and then extend them with arbitrary values, effectively falsifying boot measurements and gaining access to sealed data. This type of attack aligns with attack patterns identified in the MITRE ATT&CK framework under privilege escalation and defense evasion techniques, specifically targeting the integrity of trusted execution environments.
The technical flaw represents a classic case of improper input validation and error handling in a security-critical system, which maps directly to CWE-248, "Uncaught Exception," and CWE-707, "Improper Neutralization of Input During Web Page Generation." The vulnerability demonstrates how a seemingly benign specification requirement can become a security weakness when implemented without proper sanitization and error boundary checks. The attack vector requires an attacker to have access to REE userspace, which is typically trivial for root users and potentially achievable by less privileged users depending on system configuration. The fix implemented in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f addresses the core issue by ensuring that return codes from secure storage operations are properly sanitized before being passed to libutee functions, thereby preventing the propagation of unexpected values that could trigger panics. This remediation approach follows security best practices outlined in the Open Web Application Security Project (OWASP) guidelines for secure coding and input validation, particularly emphasizing the principle of least privilege and proper error handling in security-critical components. The broader impact extends beyond the immediate TA affected, as similar vulnerabilities could potentially exist in other TAs utilizing the Secure Storage API, making this a systemic concern for OP-TEE implementations that rely on such storage mechanisms.