- 0.1 For Patchday, Google is providing a fix for an old hole in a MediaTek driver, which attackers have been actively exploiting for a long time.Reading time:2 min.Save in pocketRead outPrintviewRead comments5posts
- 1 CVE-2020-0031 enables remote code execution
- 2 Active attacks: CVE-2020-0069 aka “MediaTek-su”
- 3 MediaTek OEMs missed patch delivery
For Patchday, Google is providing a fix for an old hole in a MediaTek driver, which attackers have been actively exploiting for a long time.Reading time:2 min.Save in pocketRead outPrintviewRead comments5posts
Google again released security patches for the Android operating system in March. They close an unusually large number of “critical” vulnerabilities, namely a total of 17.
Another security hole in a driver for MediaTek chips (CVE-2020-0069) that Google only rates as “high” is considered by external security researchers to be particularly dangerous. Exploit code appears to have been publicly available for almost a year; It is therefore hardly surprising that CVE-2020-0069 has been actively used by attackers for a long time.
In addition, Google mentions numerous other gaps in the bulletin with “high” and three with “moderate” rating.
CVE-2020-0031 enables remote code execution
According to Google, the most dangerous hole that was fixed on the March patch day is CVE-2020-0031 in the Android framework. According to the current Android Security Bulletin , a remote attacker could use a specially prepared file to execute arbitrary program code in the context of a privileged process (remote code execution).
The remaining 16 gaps that Google has rated as critical are, without exception, in closed-source components from Qualcomm; no additional information is available about them.
Active attacks: CVE-2020-0069 aka “MediaTek-su”
The actively exploited gap CVE-2020-0069 mentioned at the beginning is in the MediaTek Command Queue Driver and therefore only affects mobile devices in which chips from the manufacturer are used.
An exploit for the vulnerability, which was named “MediaTek-su” by its developer, first appeared in the forum of the platform XDA-Developers in April 2019. MediaTek-su was originally based on a script and instructions for rooting Amazon Fire devices, which the developer greatly expanded after noticing that the exploit – in his own words – was based on “virtually all MediaTek 64-bit chips “was applicable.
According to a recent article on MediaTek-su at XDA-Developers, the MediaTek-su script could be executed by any (malicious) apps on the vulnerable device in question, in order to gain temporary root access until it is restarted. In the platform’s forum there is a detailed overview of devices that the community there tested “positively” for the gap .
In January 2020, TrendMicro then reported attack campaigns in the course of which MediaTek-su (mentioned in the description rather casually) in combination with another security vulnerability was misused by malicious apps from Google’s Play Store. Curiously , Google already closed this second gap with the CVE number CVE-2019-2215 during the Android October patch day.
MediaTek OEMs missed patch delivery
According to XDA-Developers, Amazon is said to have secured vulnerable devices immediately after the vulnerability became known. MediaTek also provided patches for its partners in May 2019. Apparently, many of them failed to deliver updates for their devices.
Now Google has provided fixes again as part of the patch day. The company usually provides the respective source code for the updates promptly in the Android Open Source Project (AOSP) and informs Android partners one month before the latest Android Security Bulletin is published.
It remains unclear when and how Google became aware of MediaTek-su / CVE-2020-0069. Various media reported that MediaTek asked Google to deploy the patch to drive distribution. XDA-Developers, in turn, claims to have contacted Google in early February 2020 and reports that the company then asked the team to refrain from publishing an article until now (i.e. until the March patch day).
So it seems conceivable that the “high” rating in the current security bulletin (in contrast to the “critical” rating by the XDA developers team) is also somewhat connected with the failure to point out the gap at an earlier point in time .