Critical MediaTek rootkit affecting millions of Android devices has been out in the open for months

On the first Monday of every month, Google publishes the Android Security Bulletin, a page that discloses all the security vulnerabilities and their patches submitted by Google themselves or other third-parties. Today was no exception: Google just made public the Android Security Bulletin for March 2020. One of the vulnerabilities that are documented in the latest bulletin is CVE-2020-0069, a critical security exploit, specifically a rootkit, that affects millions of devices with chipsets from MediaTek, the large Taiwanese chip design company. Although the March 2020 Android Security Bulletin is seemingly the first time that CVE-2020-0069 has been publicly disclosed, details of the exploit have actually been sitting openly on the Internet—more specifically, on the XDA-Developers forums—since April of 2019. Despite MediaTek making a patch available a month after discovery, the vulnerability is still exploitable on dozens of device models. Even worse, the vulnerability is actively being exploited by hackers. Now MediaTek has turned to Google to close this patch gap and secure millions of devices against this critical security exploit.

The Origin of MediaTek-su

For any readers who aren’t familiar with XDA-Developers, we’re a site that’s home to the largest forums for Android software modifications. Usually, these modifications center around attaining root access on devices in order to delete bloatware, install custom software, or tweak default system parameters. Amazon’s Fire tablets are popular targets for hobbyist hackers on our forums—they’re full of uninstallable bloatware, lack access to basic software applications like the Google Play Store, and, most importantly, are very cheap. The challenge with rooting Amazon Fire tablets is that they’re heavily locked down to prevent users from stepping outside of Amazon’s walled garden; Amazon does not provide an official method to unlock the bootloader of Fire tablets, which is usually the first step in rooting any given Android device. Therefore, the only way to root an Amazon Fire tablet (without hardware modifications) is to find an exploit in the software that allows the user to bypass Android’s security model. In February of 2019, that’s exactly what XDA Senior Member diplomatic did when he published a thread on our Amazon Fire tablet forums. What he didn’t immediately realize is that he stumbled upon an exploit that was far wider in scope than just Amazon’s Fire tablets.

After a bit of testing from XDA Member diplomatic and other community members, it was discovered that this exploit works on a large number of MediaTek chips. The author states that the exploit works on “virtually all of MediaTek’s 64-bit chips,” and they specifically name the following as being vulnerable: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8173, MT8176, MT8183, MT6580, and MT6595. Because of how many MediaTek chipsets were affected by this exploit, the exploit was given the name “MediaTek-su,” or “MTK-su,” for short. On April 17th, 2020, diplomatic published a second thread titled “Amazing Temp Root for MediaTek ARMv8” on our “Miscellaneous Android Development” forum. In this thread, he shared a script that users can execute to grant them superuser access in shell, as well as set SELinux, the Linux kernel module that provides access control for processes, to the highly insecure “permissive” state. For a user to get root access and set SELinux to permissive on their own device is shockingly easy to do: All you have to do is copy the script to a temporary folder, change directories to where the script is stored, add executable permissions to the script, and then execute the script.

The simple steps to get root access using MediaTek-su. Source: XDA Senior Member Diplomatic

XDA community members confirmed the exploit worked on at least the following devices:

Devices the community confirmed were exploitable by MediaTek-su

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Alba tablet series
4. Alcatel 1 5033 series
5. Alcatel 1C
6. Alcatel 3L (2018) 5034 series
7. Alcatel 3T 8
8. Alcatel A5 LED 5085 series
9. Alcatel A30 5049 series
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 — up to Fire OS 6.3.1.2 build 0002517050244 only
15. Amazon Fire HD 8 2016 — up to Fire OS 5.3.6.4 build 626533320 only
16. Amazon Fire HD 8 2017 — up to Fire OS 5.6.4.0 build 636558520 only
17. Amazon Fire HD 8 2018 — up to Fire OS 6.3.0.1 only
18. Amazon Fire HD 10 2017 — up to Fire OS 5.6.4.0 build 636558520 only
19. Amazon Fire HD 10 2019 — up to Fire OS 7.3.1.0 only
20. Amazon Fire TV 2 — up to Fire OS 5.2.6.9 only
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. ASUS ZenPad Z3xxM(F) MT8163-based series
24. Barnes & Noble NOOK Tablet 7″ BNTV450 & BNTV460
25. Barnes & Noble NOOK Tablet 10.1″ BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Life Max
29. BLU Life One X
30. BLU R1 series
31. BLU R2 LTE
32. BLU S1
33. BLU Tank Xtreme Pro
34. BLU Vivo 8L
35. BLU Vivo XI
36. BLU Vivo XL4
37. Bluboo S8
38. BQ Aquaris M8
39. CAT S41
40. Coolpad Cool Play 8 Lite
41. Dragon Touch K10
42. Echo Feeling
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Huawei Y6II MT6735 series
48. Lava Iris 88S
49. Lenovo C2 series
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. LG Tribute Dynasty
55. LG X power 2/M320 series (MTK)
56. LG Xpression Plus 2/K40 LMX420 series
57. Lumigon T3
58. Meizu M5c
59. Meizu M6
60. Meizu Pro 7 Plus
61. Nokia 1
62. Nokia 1 Plus
63. Nokia 3
64. Nokia 3.1
65. Nokia 3.1 Plus
66. Nokia 5.1
67. Nokia 5.1 Plus/X5
68. Onn 7″ Android tablet
69. Onn 8″ & 10″ tablet series (MT8163)
70. OPPO A5s
71. OPPO F5 series/A73 — Android 8.x only
72. OPPO F7 series — Android 8.x only
73. OPPO F9 series — Android 8.x only
74. Oukitel K12
75. Protruly D7
76. Realme 1
77. Sony Xperia C4
78. Sony Xperia C5 series
79. Sony Xperia L1
80. Sony Xperia L3
81. Sony Xperia XA series
82. Sony Xperia XA1 series
83. Southern Telecom Smartab ST1009X (MT8167)
84. TECNO Spark 3 series
85. Umidigi F1 series
86. Umidigi Power
87. Wiko Ride
88. Wiko Sunny
89. Wiko View3
90. Xiaomi Redmi 6/6A series
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

With the exception of MediaTek-based phones from Vivo, Huawei/Honor (after Android 8.0+), OPPO (after Android 8.0+), and Samsung, XDA community members found that MediaTek-su works more often than not when attempted on devices with affected chipsets. According to XDA Member diplomatic, Vivo, Huawei/Honor, OPPO, and Samsung devices “use kernel modifications to deter root access via exploits,” which means the developer would need to dig into the kernel source code of these devices to create “tailored version[s]” of the exploit. That wasn’t worth the added effort, so the developer chose not to add support for these devices even though, “in theory,” the exploit could still work.

By now, it should be clear that this exploit affects a large number of devices on the market. MediaTek chips power hundreds of budget and mid-range smartphone models, cheap tablets, and off-brand set-top boxes, most of which are sold without the expectation of timely updates from the manufacturer. Many devices still affected by MediaTek-su are thus unlikely to get a fix for weeks or months after today’s disclosure, if they get one at all. So what makes MediaTek-su earn its “Critical” severity with a CVSS v3.0 score of 9.3?

Why MTK-su is a Critical Security Vulnerability

To reiterate, the typical way to achieve root access on an Android device is to first unlock the bootloader, which disables verification of the boot partition. Once the bootloader is unlocked, the user can introduce a superuser binary to the system and also a superuser management app to control which processes have access to root. Unlocking the bootloader is intentionally disabling one of the key security features on the device, which is why the user has to explicitly allow it to happen by typically enabling a toggle in Developer Options and then issuing an unlock command to the bootloader. With MediaTek-su, however, the user does not have to unlock the bootloader to get root access. Instead, all they have to do is copy a script to their device and execute it in shell. The user isn’t the only one that can do this, though. Any app on your phone can copy the MediaTek-su script to their private directory and then execute it to gain root access in shell. In fact, XDA Member diplomatic highlights this possibility in their forum thread when they suggest an alternative set of instructions using either the Terminal Emulator for Android app or Termux rather than ADB.

With root access, Android’s security model basically falls apart. For example, permissions become meaningless in the context of root as an app with access to a root shell can grant itself any permission it wants. Furthermore, with a root shell, the entirety of the data partition—including files stored in the typically inaccessible private data directories of applications—is accessible. An app with root can also silently install any other app it wants in the background and then grant them whatever permissions they need to violate your privacy. According to XDA Recognized Developer topjohnwu, a malicious app can even “inject code directly into Zygote by using ptrace,” which means a normal app on your device could be hijacked to do the bidding of the attacker. These examples only touch on a few ways that an app can violate your trust in the background without your knowledge. However, malicious apps can wreak havoc on your device without hiding what they’re doing. Ransomware, for example, is extremely potent with root access; if you don’t pay up, a hypothetical ransomware app could totally and irreversibly make your device inoperable by wiping the entire device clean.

The only “weakness” in MediaTek-su is that it grants an application just “temporary” root access, which means that a process loses superuser access after a device reboot. Furthermore, on devices running Android 6.0 Marshmallow and above, the presence of Verified Boot and dm-verity block modifications to read-only partitions like system and vendor. However, these two factors are mostly only hindrances to modders on our forums rather than malicious actors. To overcome the limitation of temporary root, a malicious app can simply re-run the MediaTek-su script on every boot. On the other hand, there’s little need to overcome dm-verity as permanent modifications to the system or vendor partitions are unlikely to interest most malware authors; after all, there are already tons of things a malicious app can do with a root shell.

If you’re wondering on a technical level what MediaTek-su is exploiting, MediaTek shared the below chart with us that summarizes the entry point. The flaw apparently exists in one of MediaTek’s Linux Kernel drivers called “CMDQ.” The description states that, “by executing IOCTL commands in [the] CMDQ device node,” a local attacker can “arbitrarily read/write physical memory, dump [the] kernel symbol table to the pre-allocated DMA buffer, [and] manipulate the DMA buffer to modify the kernel settings to disable SELinux and escalate to ‘root’ privilege.”

MediaTek’s Security Vulnerability Summary of CVE-2020-0069

According to the chart that MediaTek shared with us, this vulnerability affects MediaTek devices with Linux Kernel versions 3.18, 4.4, 4.9, or 4.14 running Android versions 7 Nougat, 8 Oreo, or 9 Pie. The vulnerability is not exploitable on MediaTek devices running Android 10, apparently, since “the access permission of CMDQ device nodes is also enforced by SELinux.” This mitigation likely comes from an update to MediaTek’s BSP rather than from Android itself. Android 10’s only mitigation for this vulnerability is its restriction on apps executing binaries in their home directory; however, as XDA Recognized Developer topjohnwu notes, a malicious app can simply run the MediaTek-su code in a dynamic library.

Even though MediaTek has patched this issue in all the affected chipsets, they can’t force device makers to implement the patches. MediaTek told us they had patches ready all the way back in May of 2019. Amazon, unsurprisingly, immediately patched the issue across its devices once they were made aware. However, 10 months have passed since MediaTek made a fix available to its partners, yet in March of 2020, dozens of OEMs haven’t fixed their devices. Most of the affected devices are on older Android releases with outdated Android Security Patch Levels (SPLs), and the update situation is even worse when you consider the hundreds of lesser-known device models using these MediaTek chips. MediaTek has a serious issue on its hands here, so they’ve turned to Google for help.

Unlike MediaTek, Google can force OEMs to update their devices through license agreements or program terms (such as Android One). For an OEM to declare that a device is in compliance with the 2020-03-05 Security Patch Level (SPL), the device must include all framework, Linux kernel, and applicable vendor driver fixes in the March 2020 Android Security Bulletin, which includes a fix for CVE-2020-0069, or MediaTek-su. (Google doesn’t actually seem to enforce that OEMs actually merge all patches when declaring a certain SPL, though.) Now that the March 2020 bulletin is out, this story should be over, right? Unfortunately, we have to also hold Google’s feet to the fire for dragging their feet on incorporating the patches.

The flaw in the security patch process

In case it isn’t clear already, not every security vulnerability needs to end up in an Android Security Bulletin. Many vulnerabilities are discovered and patched by vendors without them ever showing up in the monthly bulletin. MediaTek-su should have been one of them, but for multiple reasons, several OEMs failed to integrate the patches offered by MediaTek. (There are a lot of potential reasons why, ranging from a lack of resources to business decisions to a failure in communication.) When I previously stated that MediaTek “turned to Google” for help, it implied that MediaTek actively sought help from Google to get OEMs to finally fix their devices. However, that might not actually have been the case. It is my understanding that Google was unaware of MediaTek-su until it was incidentally brought up in a security report from TrendMicro published January 6th, 2020. In the report, TrendMicro was documenting another security vulnerability, dubbed the “use-after-free in binder driver” vulnerability, that was actively being exploited in the wild. TrendMicro noted how three malicious apps attained root access using one of two methods, either the “use-after-free in binder driver” vulnerability or MediaTek-su.

Alleged Play Store apps abusing MediaTek-su. Source: TrendMicro.

In the code that TrendMicro shared, we can clearly see how the malicious apps were targeting specific device models (eg. Nokia 3, OPPO F9, and Redmi 6A) and employing MediaTek-su on them.

I can’t speak for TrendMicro, but it seems that they were unaware that MediaTek-su was a yet-unpatched exploit. Their focus was on the “use-after-free in binder driver” exploit, after all, and the discovery of the use of MediaTek-su seems to have been an afterthought. (I’m sure that if TrendMicro were aware of the situation surrounding MediaTek-su, they would have coordinated their disclosure efforts with Google.) We were only made aware of this exploit ourselves on February 5th, 2020, and after investigating for ourselves how bad it was, we contacted Google about it on February 7th, 2020. Google was so concerned about the repercussions of publicizing MediaTek-su that they asked us to hold off on publishing this story until today. After considering the irreparable harm that can be inflicted on users targeted by malware using MediaTek-su, we agreed to put a hold on this story until the announcement of the March 2020 Android Security Bulletin. Still, considering how long it’ll take many devices to get the latest security update, if they ever get it at all, there is bound to be a ton of devices still vulnerable to MediaTek-su a few months from now. That should be horrifying to anyone with a vulnerable device.

Even though this very serious, “critical” severity vulnerability is actively being exploited in the wild, Google only slotted in the fix for this issue into the March 2020 bulletin, which is about 2 months after they were made aware of the issue. While Google does inform its Android partners about the latest Android Security Bulletin a full 30 days before the bulletin is made public (ie. OEMs were made aware of what’s in the March 2020 bulletin in early February 2020), Google can, and often does, update the bulletin with changes or new fixes. Why Google didn’t choose to expedite the inclusion of a patch for such a serious issue is beyond me, especially when MediaTek had a fix for it 10 months ago. If such a bug were discovered in Apple’s devices, I have little doubt they would have issued a fix much, much faster. Google essentially banked on the risky bet that MediaTek-su would remain as seemingly low-profile as it already was until the March 2020 bulletin. While Google seems to have gotten lucky in that regard, we have no idea how many malware authors already know about the exploit. After all, it’s been sitting in a random XDA forum thread for nearly a whole year.

There’s one more party in this debacle that I haven’t addressed much, and it’s the author of the exploit, XDA Member diplomatic. To their credit, I don’t think they had any malicious intent in publishing MediaTek-su. We can clearly trace the exploit’s origin to diplomatic’s desire to mod the Amazon Fire tablets. Diplomatic tells me that their “main motivation for searching for a method like this was to help the community.” Customizing your device is what XDA is all about, and diplomatic’s efforts in the community are what people enjoy about the forums. Although diplomatic’s refusal to open source the project raises some concerns, they explain that they wanted the community to enjoy this “amazing temp root for MediaTek” project for as long as possible. When I first contacted diplomatic, they did admit that they were involved in some kind of “business transaction with the project’s source and research” that they insisted was “all legit.” While I was unable to get more details about this “business transaction,” I do wonder if diplomatic would have chosen to go this route if MediaTek offered a bug bounty program. I can’t imagine that a vulnerability of this magnitude wouldn’t pay out a hefty sum of money if MediaTek actually had such a program. Diplomatic claims that this exploit “has been possible since the days of MT6580” which was announced near the end of 2015, so one has to wonder if diplomatic is even the first person to find this exploit.

How to check if you’re affected by MediaTek-su?

If you want to check whether your device is vulnerable to MediaTek-su, then manually run the script posted by XDA Member diplomatic in this XDA forum thread. If you enter a root shell (you’ll know when the symbol changes from $ to #), then you’ll know the exploit works. If it works, then you’ll need to wait for the manufacturer of your device to roll out an update that patches MediaTek-su. If your device reports the Security Patch Level of 2020-03-05, which is the latest March 2020 SPL, then it is almost certainly protected against MediaTek-su. Otherwise, you’ll have to just check whether your device is vulnerable.

The post Critical MediaTek rootkit affecting millions of Android devices has been out in the open for months appeared first on xda-developers.