Security Advisories

At this page we will list of all known security vulnerabilities found on OP-TEE. Likewise you will find when it was fixed and who reported the issue.

At this page we will list of all known security vulnerabilities found on OP-TEE. Likewise you will find when it was fixed and who reported the issue.

If you have found a security issue in OP-TEE, please send us an email (see Contact) and then someone from the team will contact you for further discussion. The initial email doesn’t have to contain any details.

October 2018

Riscure mini-audit

Integer overflow in crypto system calls (x2) - part 2

The function syscall_asymm_verify is a system call used to verify cryptographic signatures. One of the parameters passed in by a TA is num_params. The TEE kernel locally allocates a heap buffer of size sizeof(TEE_Attribute) * num_params without checking for an integer overflow in the multiplication. The lack of checking can result in a smaller heap buffer than required. The user supplied input usr_params is then copied into this buffer, but making the additional checks in copy_in_attrs fail can be used to terminate the copy at any moment. This allows a heap based buffer overflow with attacker controlled data written outside the boundaries of the buffer. Such corruption might allow code execution in the context of the TEE kernel.

optee_os.git:

Reported by CVE ID OP-TEE ID Affected versions
Riscure Not/Ready OP-TEE-2018-0011 v3.3.0 and earlier

Integer overflow in crypto system calls (x2)

The function syscall_obj_generate_key is a system call which generates a cryptographic key. This system call is exposed to TAs which supply the length of the key to be generated, its type, and a number of attributes it should have. A multiplication operation involving the number of parameters is not checked for overflow which can lead to an out-of-bounds write. One of the parameters passed in by a TA is param_count. The TEE kernel locally allocates a heap buffer of size sizeof(TEE_Attribute) * param_count, without checking for an integer overflow in the multiplication. The lack of checking can result in a smaller heap buffer than required. The user supplied input usr_params is then copied into this buffer, but making the additional checks in copy_in_attrs fail can be used to terminate the copy at any moment. This allows a heap based buffer overflow with attacker controlled data written outside the boundaries of the buffer. Such corruption might allow code execution in the context of the TEE kernel.

optee_os.git:

Reported by CVE ID OP-TEE ID Affected versions
Riscure Not/Ready OP-TEE-2018-0010 v3.3.0 and earlier

Integer overflow in crypto system calls

The function syscall_cryp_obj_populate is a system call which initializes the attributes of a cryptographic object. This system call is exposed to TAs which supply a reference to the crypto object to be populated along with a number of attributes it must posses. The number of attributes is used as part of the multiplication to allocate memory. It is not checked for an overflow, which can lead to an out-of-bounds write. One of the parameters passed in by a TA is attr_count. The TEE kernel locally allocates a heap buffer of size sizeof(TEE_Attribute) * attr_count without checking for an integer overflow in the multiplication. The lack of checking can result in a smaller heap buffer than required. The user supplied input usr_attrs is then copied into this buffer, but making the additional checks in copy_in_attrs fail can be used to terminate the copy at any moment. This allows a heap based buffer overflow with attacker controlled data written outside the boundaries of the buffer. Such corruption might allow code execution in the context of the TEE kernel.

optee_os.git:

Reported by CVE ID OP-TEE ID Affected versions
Riscure Not/Ready OP-TEE-2018-0009 v3.3.0 and earlier

Buffer checks missing when calling pseudo TAs

The function tee_svc_copy_param is used to copy in parameters when a TA wants to open a session with or invoke a command upon another TA. It is used in system calls and is therefore indirectly callable by any TA. However, this function does not do sufficient parameter checking when the called TA is a pseudo TA. One of the parameters passed in is callee_params which is passed directly through from the TA. It is verified that this structure itself resides in either shared memory or memory which the calling TA has read access to. However, this structure can contain pointers as its members. The structure callee_params is first copied into the output parameter param. In the case that the called TA is a pseudo TA no further checking is done and a success code is returned. It is not verified that the members of param point to valid memory. This means there is a mismatch between the validation performed when invoking a normal TA and when invoking a pseudo TA. If a pseudo TA relies on the pointers being validated as it would be for a normal TA, it might use these pointers without further validation. This might result in memory corruption and memory disclosure.

optee_os.git:

Reported by CVE ID OP-TEE ID Affected versions
Riscure Not/Ready OP-TEE-2018-0007 v3.3.0 and earlier

Potential disclosure of previously loaded TA code and data

The function elf_load_body is used to load the code and data segments while dynamically loading a TA. The amount of memory allocated for the code and data segments is previously determined and the sum of it is stored in state->vasize. The actual allocated amount of memory is rounded up the next multiple of the memory pool granularity. To ensure that the newly loaded TA is not able to observe any data belonging to a TA previously stored on this exact location in memory, the memory block is set to zero. The size used to memset the block to zero is the sum of the sizes of the segments, not the rounded size of the actual allocation. This means that the remaining space at the end of the allocation is not cleared, potentially leaking code and/or data of a previous TA. The information gained by this attack is limited by the memory layout of the (compromised) TA performing the attack and the flags (i.e. is unloading the TA prevented when the last session is closed due to TA_FLAG_INSTANCE_KEEP_ALIVE) and layout of the attacked TA.

optee_os.git:

Reported by CVE ID OP-TEE ID Affected versions
Riscure Not/Ready OP-TEE-2018-0006 v3.3.0 and earlier

tee_mmu_check_access_rights does not check final page of TA buffer

The function tee_mmu_check_access_rights is used to check access rights to a given memory region. This function is used when a TA performs a system call to verify that the TA has the correct access rights to the buffer it provides. However, the function tee_mmu_check_access_rights does not check every page of the TA provided buffer. A TA provides a buffer as a pointer (uaddr) and a length (a). The provided buffer is checked piecewise in increments of addr_incr (4KiB) in a for-loop. In the case where len is not already page aligned, the termination condition a < (uaddr + len) has been passed when addr_incr is added the last time of the loop iteration. Therefore, the final page of the TA provided buffer is not checked. A TA could provide a buffer of which up to 4KiB resides in the context of the TEE kernel or another TA. This could lead to memory corruption of the TEE itself or another TA. Memory corruption vulnerabilities can have serious impact such as allowing runtime control.

optee_os.git:

Reported by CVE ID OP-TEE ID Affected versions
Riscure Not/Ready OP-TEE-2018-0005 v3.3.0 and earlier

Unchecked parameters are passed through from REE

The function set_rmem_param is a helper function used when copying parameters locally for TA calls. It is used when a parameter is a buffer of type rmem. The function receives an input parameter param from the REE and an output parameter mem. After finding the shared memory object referenced by param the offset and size members of param are copied into mem as is. There is no validation done to ensure that these members actually do reside in shared memory. There is no further checking done on param before it gets passed on to the TA through the function pointer sess->ctx->ops->enter_invoke_cmd in the function tee_ta_invoke_command. How this problem manifests itself is very dependent on how the passed parameters are used by the TA. However, it could lead to corruption of any memory which the TA can access.

optee_os.git:

Reported by CVE ID OP-TEE ID Affected versions
Riscure Not/Ready OP-TEE-2018-0004 v3.3.0 and earlier

May 2018

Spectre variant 4 (CVE-2018-3639)

Current status:

In the affected Arm cores (Cortex-A57, Cortex-A72, Cortex-A73 and Cortex-A75) who all are Armv8 based there are configuration control registers available at EL3 that when enabled effectively mitigate a potential Spectre v4 attack. This means that the mitigation for this is not being implemented at S-EL1 where the TEE resides. For more information about the EL-3 mitigations, please see the Trusted Firmware A Security Advisory TFV 7. In all officially supported Armv8 OP-TEE setups we are using TF-A as the firmware and therefore we consider that the TF-A mitigations at EL-3 effectively stop Spectre v4 attacks in a system running OP-TEE and TF-A.

As mentioned in the whitepaper from Arm about these types of attacks, there are new barriers (SSBB and PSSBB) being introduced also. These could also be used as a mitigation directly at lower exception levels. But just as for Spectre v1, this involves manual inspection of code and placement of barriers until tooling has become better to figure out this on its own. This manual work is error prone and very time consuming and has to be done over and over again. We have been doing some manual inspection of the OP-TEE code and so far have not been able to identify and vulnerable areas. But just as for Spectre v1, we continuously discuss tooling etc with members of Linaro.

Reported by CVE ID OP-TEE ID Affected versions
Google Project Zero CVE-2018-3639 N/A N/A (EL-3 TF-A implements the mitigation)

January 2018

Meltdown and Spectre

In collaboration a group of different people (see “Reported by”) have found out that it is possible to circumvent security countermeasures and privilege escalation by using speculative execution, caches, out-of-order execution in a specific way. All details about the attacks has been thoroughly described in the whitepapers that can found in the Meltdown and Spectre page. A blog post is also available on the Linaro website. So we will not cover the details here, instead we will highlight how it could affect OP-TEE and what the mitigations are.

Variant 1: bounds check bypass (CVE-2017-5753)

Possible attack

Since user data provided to Trusted Applications most often comes from non-secure side, it is important to check the code where we are using those non-secure parameters. The same type of checks are necessary when doing syscalls from Trusted Applications. In principle, this means that non-secure side eventually could access secure memory when untrusted value is passed to secure side.

Current status:

We have been doing some manual inspection of the OP-TEE code, and so far have not been able to identify any vulnerable areas. Code analysis tools and compiler update are being discussed with members of Linaro.

Reported by CVE ID OP-TEE ID Affected versions
Google Project Zero, University of Pennsylvania, University of Maryland, Rambus, Graz University of Technology, University of Adelaide, Data61 CVE-2017-5753 OP-TEE-2018-0001 All versions

Variant 2: branch target injection (CVE-2017-5715)

Possible attack

In theory it would be possible for a program in non-secure world to train the branch predictor to trick the secure monitor to speculatively read secure memory and as a consequence of that leak information to the cache that can be observed by a less privileged process. To exploit this an attacker needs to find a gadget that can be used as a trampoline to get access kernel memory (from a Trusted Application for example).

The mitigation here is to invalidate the branch predictor when:

  • Going from non-secure to the secure environment.
  • When doing syscall from S-EL0 to S-EL1.

Current status:

For Armv8-A builds we are typically running OP-TEE with Arm Trusted Firmware, patches can be found here:

  • https://github.com/ARM-software/arm-trusted-firmware/pull/1214 (merged)

For builds where we are not using Arm TF (typically Armv7-A builds) we have implemented mitigations that can be found here:

  • https://github.com/OP-TEE/optee_os/pull/2047 (merged)
  • https://github.com/OP-TEE/optee_os/pull/2065 (merged)

For SVC calls, we have patches here:

  • https://github.com/OP-TEE/optee_os/pull/2055 (Armv7-A, AArch32) (merged)
  • https://github.com/OP-TEE/optee_os/pull/2072 (AArch64) (merged) and https://github.com/OP-TEE/optee_os/pull/2229 (AArch64) (merged)
Reported by CVE ID OP-TEE ID Affected versions
Google Project Zero, University of Pennsylvania, University of Maryland, Rambus, Graz University of Technology, University of Adelaide, Data61 CVE-2017-5715 OP-TEE-2018-0002 All versions prior to OP-TEE 3.0.0 (32 bits) or 3.1.0 (64 bits)

Variant 3: rogue data cache load (CVE-2017-5754)

Possible attack

Just as in Linux kernel it could be possible to do the same type of attack from a Trusted Application as being described in the Meltdown whitepaper. I.e., under some conditions the CPU would read and execute instructions speculatively before the CPU handles the illegal access (traps).

Current status:

Our patches can be found here:

  • https://github.com/OP-TEE/optee_os/pull/2048 (merged)

The mitigation ideas are the same as with KPTI, i.e, we keep the amount of kernel memory being mapped to a minimum when running in usermode. It should also be noted that there are currently no known devices running OP-TEE who are susceptible to the Meltdown attack. Still we have decided to move on and merged the mitigation patches, since we believe that this gives additional security and it also means that we are prepared if/when we find OP-TEE running on Cortex-A75.

Reported by CVE ID OP-TEE ID Affected versions
Google Project Zero, Cyberus Technology, Graz University of Technology CVE-2017-5754 OP-TEE-2018-0003 All versions prior to OP-TEE 3.0.0

December 2016

RSA key leakage in modular exponentiation

Description

Applus+ Laboratories found out that OP-TEE is vulnerable to a timing attack when doing the Montgomery operations.

One way to optimize modular exponentiation is to make use of something called Montgomery multiplication and Montgomery reduction. OP-TEE implements the Montgomery operations in the big number library, libmpa. The current implementation uses a binary Left to Right (LtoR) implementation. The LtoR implementation is vulnerable to timing attacks since it leaks information about the exponent in use, because it uses different amount of time in each loop when doing the exponentiation. The leaked information can be used to completely recover the private key. One mitigation to this attack is to change the implementation to a constant time exponentiation algorithm instead of LtoR. One such algorithm is the so called Montgomery powering ladder, which does the same amount of operations in every loop. I.e., it will always do square and multiply in every loop. The fix (Montgomery ladder) for the timing attack has been implemented in:

optee_os.git:

Reported by CVE ID OP-TEE ID Affected versions
Applus+ Laboratories CVE-2017-1000413 OP-TEE-2016-0003 All versions prior to OP-TEE 2.5.0

Bellcore attack

Description

Applus+ Laboratories found out that OP-TEE is vulnerable to the Bellcore attack when using fault injection / glitching attack.

A common way to speed up RSA calculations is to use something that is called Chinese Remainder Theorem (CRT). This optimization is also used in LibTomCrypt which is currently the default software crypto library in OP-TEE. In short, when using CRT you are operating on the individual prime factors ‘p’ and ‘q’ separately and then later combine them to final result instead of just doing the exponentiation directly. However, this also means that if somethings goes wrong in the intermediate calculations with ‘p’ or ‘q’ it is possible to completely recover the private key if you also have access to a valid signature. I.e. it’s the combination of valid and invalid signature that makes it possible to recover the private key.

The important thing is to never ever return any incorrect signature back to the caller. LibTomCrypt already has mitigations for this. They have the flag LTC_RSA_CRT_HARDENING which enables code that checks that the signature indeed is valid before returning it to the user. Then there is also the flag LTC_RSA_BLINDING which mixes in another random prime number when doing the intermediate calculations. OP-TEE hasn’t had those flags enabled by default in the past and when enabling them there was some code missing related to random number generation for big number (mpanum). The fixes for this issue can be found in:

optee_os.git:

The fix can be found in OP-TEE starting from v2.5.0.

Reported by CVE ID OP-TEE ID Affected versions
Applus+ Laboratories CVE-2017-1000412 OP-TEE-2017-0002 All versions prior to OP-TEE 2.5.0

June 2016

Bleichenbacher signature forgery attack

Description

A vulnerability in the OP-TEE project was found by Intel Security Advanced Threat Research in June 2016. It appeared that OP-TEE was vulnerable to Bleichenbacher signature forgery attack.

The problem lies in the LibTomCrypt code in OP-TEE, that neglects to check that the message length is equal to the ASN.1 encoded data length. Upstream LibTomCrypt already had a fix and there was also a test case, verifying that the fix resolved the issue.

The fixes from upstream LibTomCrypt has been cherry-picked into OP-TEE. The fix for TEE core can be found upstream in this patch and a test case has been added to the test suite for OP-TEE and that can also be found upstream in this patch.

Reported by CVE ID OP-TEE ID Affected versions
Intel Security Advanced Threat Research CVE-2016-6129 OP-TEE-2016-0001 All versions prior to OP-TEE v2.2.0 (fixed in OP-TEE v2.2.0)

Supporting Companies


Linaro Member
Wind River
Applus Laboratories Member