The Qualcomm IPQ40xx family of chips, which includes the IPQ4018, IPQ4019, IPQ4028 and IPQ4029, are popular System-on-Chip (SoC) solutions for consumer and enterprise networking products. Many devices like the ASUS RT-AC58U, Cisco Meraki MR33 and Aruba AP-365 use an IPQ40xx chip as the main System-on-Chip (SoC) in their design. The OpenWRT Project supported device database shows at least 34 products, manufactured between 2018 and 2020, that are designed around a IPQ40xx chip. The total number of products is likely much larger as many devices, like the Netgear Orbi RB20, are not supported by OpenWRT and therefore not included in the database.
We often analyze networked devices and it’s not surprising that an IPQ40xx-based device found a way to our lab. We got extremely interested once we recognized that this SoC [supports Secure Boot and a Trusted Execution Environment (TEE) made by Qualcomm, hereinafter simply referred to as ‘QSEE’.
During the last decade, the availability of devices with a TEE has increased, answering the need for securing the execution of critical code on multi-purpose devices. They are nowadays widely present on mobile phones to support implementing various use cases with QSEE itself being available on all Snapdragon-based models. Moreover, they are also present on devices like Smart TVs (e.g. for DRM), set-top-boxes (e.g. for PayTV) and even ECUs used by modern vehicles. Still, the availability of a TEE on a networking device like the Linksys EA8300 is somewhwat surprising. Differently from Secure Boot, the use cases therefore have not clearly emerged yet!
We found that QSEE is present on all IPQ40xx-based products we analyzed. However, this does not imply that QSEE is actively used. For instance, the Linksys EA8300 does not seem to use QSEE after its fully booted. We determined that the IPQ40xx SDK likely includes QSEE and its bootloader (i.e. SBL1) only in binary form. Moreover, we believe it may be signed by Qualcomm as well. Thereofore, it’s likely that QSEE is integrated by the SDK into a firmware build by default. This means, an OEM like Linksys, may only have limited control whether QSEE is present or not.
During our research, we extracted the QSEE partition from the target devices and reverse engineered its attack surface and functionality. For our convenience, we explored the attack surface of QSEE from the U-Boot bootloader as we assumed it would be the same, or at least very similar, once the device is fully booted.
We identified multiple critical vulnerabilities for which the following CVEs were assigned: CVE-2020-11256, CVE-2020-11257, CVE-2020-11258 and CVE-2020-11259. We successfully exploited all these vulnerabilities and we were able to execute arbitrary code within QSEE, effectively compromising its additional layer of protection.
The video below demonstrates our exploit for CVE-2020-11256.
An attacker, that’s able to execute code within QSEE, is able to:
- Gain the highest privileges in order to completely compromise the device.
- Gain access to any asset; even if protected by QSEE.
- Gain privileged code execution even before the OS is initialized.
- Render any security features implemented by QSEE (e.g. IPS, AV) ineffective.
The vulnerabilities can be exploited from any code with sufficient privileges for issuing a Secure Monitor Call (SMC) instruction. For most devices, this typically is the bootloader or OS Kernel code. An attacker in control of an unprivileged application, may need to leverage Kernel OS functionality to access QSEE, which is often implemented using a dedicated driver, . Another option would be to exploit a vulnerability in the bootloader or OS Kernel to gain privileged code execution.
We reported these vulnerabilities to Qualcomm June of 2020 using a coordinated disclosure process. We would like to thank Qualcomm for their positive and professional attitude during the entire disclosure process. In October 2020, we received confirmation that Qualcomm implemented fixes and notified their customers with adequate measures to mitigate the vulnerabilities. This publication and the posts that will follow are published in agreement with Qualcomm.
To our surprise, the list of affected products provided by Qualcomm, further expands the impact of our findings to different classes of devices, including:
- CSR8811 Bluetooth v4.2 single-chip radio / baseband IC
- MAC/PHY Transceiver (power line)
- Qualcomm Aqstic™ Audio Codec
It must be noted, that we did not explore the vulnerabilities for all the different affected platforms. Where applicable, additional attack paths and exploitation techniques may be available to an attacker.
We strongly recommend OEMs to follow Qualcomm’s advice and roll out software updates as soon as possible. This advice should be followed even when not explicitly aware of a TEE being present, as it may be integrated by default. Moreover, it’s important to assign adequate resources to determine what the impact is of these vulnerabilities on your product. Support from a third-party security lab specializing in TEE security may be helpful.
- Raelize.