F-Secure reported that the i.MX CSU configuration in OP-TEE for a couple of devices (i.MX6, i.MX6ULL, i.MX6ULZ, i.MX6SX, i.MX67DS) has an insecure default state. The csu_sa_imx6ul, which represents the CSU Security Access register (CSU_SA) settings for access and lock values, is only set for the i.MX6UL P/N. All remaining P/Ns have a NULL csu_sa_setting which causes the CSU_SA P/N defaults to be applied (which are Secure access for all type-1 masters). This means that Normal World, on the i.MX6, i.MX6ULL, i.MX6ULZ, i.MX6SX, i.MX67DS, can bypass TrustZone protections by accessing any bus master not protected by the CSL configuration.
The OP-TEE team (core maintainers and the maintainers of the NXP ports), TrustedFirmware and NXP have together investigated this issue and although the claim above is correct, our conclusion is that this isn't a security issue as such and the rationale for that decision is as follows:
- NXP have documented how to securely configure the CSU in the documentation for the i.MX family.
- NXP cannot provide a secure configuration for OP-TEE that fits all customer needs and that’s why by default, the i.MX security in OP-TEE OS is open. Trying to satisfy all security needs for all different possible configurations at the same time is not doable.
- OP-TEE strives to be as secure as possible by default, but in the end it is an open source reference implementation, which for various reason cannot always have fully secure configurations enabled by default. As an example unrelated to this report, the OP-TEE project has a hardware unique key (HUK), which is just a stubbed key. Another example would be the Trusted Applications that by default in OP-TEE are signed with an dummy/example key. Both of these are meant to be replaced by the one making the (secure) devices targeting the end consumers. This is something that has been addressed in the OP-TEE porting guidelines. We believe that the CSU configuration falls in the same category. I.e., in the end products is should configured in a secure manner, but for the reference implementations it's better to leave it in the default state.
We do not share F-Secure's view on the severity. In short we don't see this as a security issue, but since F-Secure insisted on pushing this and since they have created a CVE for it, we have for consistency decided to link to the CVE in this report.
Patches
N/A
Workarounds
- In addition to the existing i.MX documentation, NXP will publish a NXP/i.MX dedicated section in the OP-TEE documentation where a disclaimer will warn about this default open security configuration of i.MX platforms.
- We advise companies making products based on the i.MX devices mentioned in this advisory to cross check that their CSU settings are correct and configured in a secure manner according to the i.MX documentation.
References
[1] OP-TEE porting guidelines
[2] F-secure's disclosure policy
OP-TEE ID
N/A
Reported by
For more information
For more information regarding the security incident process in OP-TEE, please read the information that can be found when going to the "Security" page at https://www.trustedfirmware.org.
F-Secure reported that the i.MX CSU configuration in OP-TEE for a couple of devices (
i.MX6,i.MX6ULL,i.MX6ULZ,i.MX6SX,i.MX67DS) has an insecure default state. The csu_sa_imx6ul, which represents the CSU Security Access register (CSU_SA) settings for access and lock values, is only set for thei.MX6UL P/N. All remaining P/Ns have aNULLcsu_sa_setting which causes the CSU_SA P/N defaults to be applied (which are Secure access for all type-1 masters). This means that Normal World, on thei.MX6,i.MX6ULL,i.MX6ULZ,i.MX6SX,i.MX67DS, can bypass TrustZone protections by accessing any bus master not protected by the CSL configuration.The OP-TEE team (core maintainers and the maintainers of the NXP ports), TrustedFirmware and NXP have together investigated this issue and although the claim above is correct, our conclusion is that this isn't a security issue as such and the rationale for that decision is as follows:
We do not share F-Secure's view on the severity. In short we don't see this as a security issue, but since F-Secure insisted on pushing this and since they have created a CVE for it, we have for consistency decided to link to the CVE in this report.
Patches
N/A
Workarounds
References
[1] OP-TEE porting guidelines
[2] F-secure's disclosure policy
OP-TEE ID
N/A
Reported by
For more information
For more information regarding the security incident process in OP-TEE, please read the information that can be found when going to the "Security" page at https://www.trustedfirmware.org.