QuadRooter Attack Overview: Vulnerabilities, Methods & Mitigations
QuadRooter is a threat vector specifically affecting Android devices. The common vulnerabilities and exposures (CVE) for these security issues are:
- CVE-2016-2059 (Linux IPC router binding any port as a control port)
- CVE-2016-5340 (Ashmem vulnerability)
- CVE-2016-2503, CVE-2106-2504 (Use after free due to race conditions in KGSL)
The suspected vulnerability in Android devices is the Qualcomm chipsets. Qualcomm is the world’s leading designer of LTE chipsets. Also at risk are the software drivers that come with the chipsets. They control the flow of communications between the chipset components.
An attacker can use these various vulnerabilities for executing arbitrary code on a particular Android device. Alternatively, an attacker can use an APK file which can install itself after downloading.
What Android Devices are Vulnerable to QuadRooter Attacks?
These Android devices are most vulnerable:
- BlackBerry Priv
- Blackphone 1 and Blackphone 2
- Google Nexus 5X, Nexus 6 and Nexus 6P
- HTC One, HTC M9 and HTC 10
- LG G4, LG G5, and LG V10
- New Moto X by Motorola
How Does the QuadRooter Attack Work?
Here are the technical details of the QuadRooter attack using Android vulnerabilities listed above.
CVE-2016-2059 (Linux IPC Router Binding Any Port as a Control Port)
A kernel module introduced by Qualcomm, called the ipc_router, provides inter-process communication capabilities for the various Qualcomm components, user mode processes and hardware drivers. The vulnerability is in the conversion function which uses a flawed locking logic to corrupt the monitoring sockets list. The sockets list is corrupted by deleting the port_ptr (this is an extension struct to the original struct socket) from its list using the list del function as well as the local_ports_lock_lhc2 lock at the same time. This tactic is illustrated in the screenshot below:
Calling this function on a monitoring socket removes it from the list while also locking down the regular sockets list. Thus, an attacker can use this vulnerability to corrupt the control ports list by causing it to point to free data. This can then be controlled with a technique known as “heap spraying.” Assuming an attacker can occupy the newly freed memory and control it, the kernel treats the sprayed memory like a regular msm_ipc_port object.
CVE-2016-5340 (Ashmem Vulnerability)
This vulnerability occurs because the ashmem_file() function does not properly check for the required file types. Thus, attackers can use a deprecated feature of the Android, called the “Obb5”. This can be used to create a file named “ashmem” on top of a file system. With this feature, an attacker can mount their own file system, creating a file in their root directory called “ashmem”. By sending the fd of this file to the “get_ashmem_file” function, an attacker can trick the system to think that the file they created is actually an ashmem file, when in reality, it can be any file type. This is demonstrated in the screenshot below:
The function “get_ashmem_file” retrieves a file descriptor and checks whether the file descriptor points to an ashmem file type. If the file descriptor points to it, this function then proceeds to extract the private_data struct and subsequently returns it back to the caller. This process is illustrated below:
CVE-2016-2503, CVE-2106-2504 (Use After Free Due to Race Conditions In KGSL)
The kgsl is one of Qualcomm’s GPU components. The vulnerability actually exists within the destroy() function. It is prone to what is known as a “race condition flaw,” where two parallel threads call the function simultaneously. This could make the kernel force a context switch in one thread. This happens right after the “kgsl_syncsource_get” call to the second thread which also calls this function. Together, these two threads can pass the kgsl_syncsource_get before starting the refcount reduction technique. This drops the refcount of a syncsource object below 0, thus exposing itself to a use-after-free attack. This is can be seen in the illustration below:
This vulnerability exists in the “kgsl_mem_entry_attach_process()” function since it grants access to the UM before the initialization of a particular entry. This is illustrated in the screenshot below:
QuadRooter Attack Mitigation Suggestions
- Users should avoid installing Android apps (in particular, APK files) which are hosted by an unknown third party. Instead, download apps only from trusted sources such as Google Play.
- Users should read the permission requests when the installing apps. Be wary of apps asking for unusual or unnecessary permissions; or apps using large amounts of data or battery life.
- The user should only use a trusted and encrypted Wi-Fi network. Also, the Wi-Fi adapter should be turned off when not being used.
- Consider using mobile security solutions that detect suspicious behavior on a device, including malware hiding in apps.
- QuadRooter vulnerabilities leaves 900 million Android devices at risk of attack, We Live Security
- Qualcomm, Wikipedia
- Google says most users are protected against QuadRooter Android threat, The Inquirer
- The truth behind QuadRooter, Avast Blog
- What is QuadRooter? Android bug exposes 900m phones to attack, including Galaxy S7, Trusted Reviews