[Electronics-Talk] This time, the vulnerability exploit has to do with the Mediatek chip (fwd)

Tue Mar 3 11:39:47 UTC 2020

-- 

---------- Forwarded message ----------
Date: Mon, 2 Mar 2020 15:27:07
From: Warren Carr <warcarr at gmail.com>
Reply-To: antad at googlegroups.com
To: antad at googlegroups.com
Subject: This time, the vulnerability exploit has to do with the Mediatek chip

I?d let this one from the XDA site speak for itself.

Quote:

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

xda-developers / Mishaal Rahman

On the first Monday of every month, Google publishes the Android Security
Bulletin <https://source.android.com/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
<http://forum.xda-developers.com/> , 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
<https://forum.xda-developers.com/hd8-hd10/orig-development/experimental-sof
tware-root-hd-8-hd-10-t3904595>  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, 2019, diplomatic published a second thread titled ?Amazing Temp
Root for MediaTek ARMv8
<https://forum.xda-developers.com/android/development/amazing-temp-root-medi
atek-armv8-t3922213> ? 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.

  <https://www.xda-developers.com/files/2020/03/MediaTek-su-Steps.jpg>
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 <https://forum.xda-developers.com/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 <https://forum.xda-developers.com/nokia-1>
62. Nokia 1 Plus
63. Nokia 3 <https://forum.xda-developers.com/nokia-3>
64. Nokia 3.1 <https://forum.xda-developers.com/nokia-3-1>
65. Nokia 3.1 Plus
66. Nokia 5.1 <https://forum.xda-developers.com/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 <https://forum.xda-developers.com/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 <https://www.xda-developers.com/tag/android-oreo/> +), 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
<https://nvd.nist.gov/vuln-metrics/cvss>  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
<https://forum.xda-developers.com/showpost.php?p=79354350&postcount=2>  in
their forum thread when they suggest an alternative set of instructions
using either the Terminal Emulator for Android app
<https://play.google.com/store/apps/details?id=jackpal.androidterm>  or
Termux <https://play.google.com/store/apps/details?id=com.termux>  rather
than ADB <https://www.xda-developers.com/install-adb-windows-macos-linux/> .

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 <https://forum.xda-developers.com/member.php?u=4470081>
, 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
<https://www.xda-developers.com/a-look-at-marshmallow-root-verity-complicati
ons/>  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.?

  <https://www.xda-developers.com/files/2020/03/CVE-2020-0069.png>
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
<https://developer.android.com/about/versions/10/behavior-changes-10#execute
-permission> ; 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
<https://www.xda-developers.com/google-require-oem-regular-security-patches/
>  or program terms (such as Android One
<https://www.xda-developers.com/tag/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
<https://www.xda-developers.com/android-oem-lying-security-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
<https://www.xda-developers.com/zero-day-security-vulnerability-active-explo
it-google-pixel-huawei-xiaomi-samsung-others/> ? 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.

<https://www.xda-developers.com/files/2020/03/TrendMicro-MediaTek-su-exploit
.jpg>
Alleged Play Store apps abusing MediaTek-su. Source: TrendMicro
<https://blog.trendmicro.com/trendlabs-security-intelligence/first-active-at
tack-exploiting-cve-2019-2215-found-on-google-play-linked-to-sidewinder-apt-
group/> .

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.

  <https://www.xda-developers.com/files/2020/03/TrendMicro-DEX-Code.jpg>
  <https://www.xda-developers.com/files/2020/03/TrendMicro-MediaTek-su-code.
jpg>
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
<https://forum.xda-developers.com/android/development/amazing-temp-root-medi
atek-armv8-t3922213> . 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
<https://www.xda-developers.com/mediatek-su-rootkit-exploit/>  appeared
first on xda-developers <https://www.xda-developers.com/> .

 <https://www.xda-developers.com/mediatek-su-rootkit-exploit/> Visit website

 <http://appyet_base/COMMENT_APPYET> View comments

End of quite.

Warren

As both an "Android Evangelist and Enthusiast," I beg you in the name of
Google, to quit spreading false information among blind people that says
Android is Not Accessible!

Ask, and you will be enlightened!

Help empower the disabled, but don't compartmentalize them!

Join ?ANTAD? by sending mail to: antad+subscribe at googlegroups.com <mailto:
antad+subscribe at googlegroups.com>  for anything Android, News, Talk, Apps
and Deals with no moderation!

For the ?ANTAD Podcast,? simply navigate to:

antadpodcast.com

or input that in your podcast client to fetch the episodes or simply Google
ANTAD Podcast.

Join the ANTAD Lounge on Skype by going to this URL:

<https://www.google.com/url?q=https%3A%2F%2Fjoin.skype.com%2FSnQzyhxlzzwH&sa
=D&sntz=1&usg=AFQjCNEe7w74VavoCcEEXJGrk5sPKPsc9g>
https://join.skype.com/SnQzyhxlzzwH

-- 
You received this message because you are subscribed to the Google Groups "ANTAD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antad+unsubscribe at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/antad/000a01d5f0d0%24f1f1b0f0%24d5d512d0%24%40gmail.com.