pjlantz/optee-qemuEnvironment with vulnerable kernel for exploitation of the TEE driver (CVE-2021-44733)
Recently a use-after-free vulnerability was discovered in the Linux kernel TEE subsystem, up to and including version 5.15.11, and was assigned CVE-2021-44733 [1].
At a first glance it did not seem to be exploitable for several reasons, however after some further analysis of the vulnerable code path and by implementing a crude proof-of-concept exploit it was possible to overwrite a function pointer in the kernel. No privilege escalation payload is presented in this post, however the entire environment for running OPTEE and the exploit is available for further testing, see 'Setting up the environment'.
A TEE (Trusted Execution Environment) is a trusted OS running in some secure environment, for example, TrustZone on ARM CPUs. A TEE driver handles the details needed to communicate with the TEE. Some of the more important duties of the driver is to provide a generic API towards the TEE based on the Globalplatform TEE Client API specification [3], but also to manage the shared memory between Linux and the TEE. This subsystem can be enabled by configuring CONFIG_OPTEE in the kernel configurations for ARM architectures.
The secure world contains the trusted OS denoted OP-TEE OS [4]. On top of this OS it is possible to have so called Trusted Applications (TAs) running which can perform some operations in the isolated environment, see Figure 1.
Figure 1: Overview of TEE - from Linaro's presentation [5]
The normal world (Linux userspace/kernel) can interact with these applications using client applications (CAs) and the API exposed by the TEE subsystem. A CA can open a session towards a specific TA and invoke functions that the TA implements. Passing of any arguments back and forth between the TA and CA is done using shared memory. The interaction between a CA and TA using all relevant syscalls is described next.
A CA opens up /dev/tee[0-9] to communicate with the driver. Note, that for the conventional way of using these APIs, this is done implicitly using the libteec.
The shared memory can be registered by the CA using the IOCTL TEE_IOC_SHM_ALLOC. This allocates shared memory and returns a file descriptor which user space can use as part of mmap.
The next step is to establish a session using the IOCTL TEE_IOC_OPEN_SESSION and specifying the uuid for a specific TA. This uuid is hardcoded during the compilation of the TA.
In order to invoke any specific function in the TA, the CA invokes this by specifying the identifier of a function along with any input arguments, this is done using TEE_IOC_INVOKE.
When the CA is finished with all requests, the session can be closed using TEE_IOC_CLOSE_SESSION.
Figure 2: Session between CA and TA - from Linaro's presentation [5]
Much of the communication between clients and the TEE is opaque to the driver. The main job for the driver is to manage the context, receive requests from the clients, forward them to the TEE and send back the results [2].
CVE-2021-44733 was discovered using fuzzing with syzkaller. The description file used for this is provided below. Note that ioctl$TEE_SHM_REGISTER_FD is only part of Linaro (maintainers) kernel tree and not in upstream. The environment provided in 'Setting up the environment' could be used for fuzzing if configured properly according to syzkaller documentation [6]
