Rootkit MediaTek yang penting memengaruhi jutaan perangkat Android

Pada hari Senin pertama setiap bulan, Google menerbitkan Buletin Keamanan Android, halaman yang mengungkapkan semua kerentanan keamanan dan perbaikannya yang dikirimkan oleh Google sendiri atau pihak ketiga lainnya. Hari ini tidak terkecuali: Google baru saja mempublikasikan Buletin Keamanan Android untuk bulan Maret 2020. Salah satu kerentanan yang didokumentasikan dalam buletin terbaru adalah CVE-2020-0069, sebuah eksploitasi keamanan penting, khususnya a rootkit, yang memengaruhi jutaan perangkat dengan chipset dari MediaTek, perusahaan desain chip besar Taiwan. Meskipun Buletin Keamanan Android bulan Maret 2020 tampaknya merupakan pertama kalinya CVE-2020-0069 diungkapkan kepada publik, rincian eksploitasi sebenarnya telah tersebar secara terbuka di Internet—lebih khusus lagi, di forum XDA-Developers—sejak April tahun 2019. Meskipun MediaTek menyediakan patch sebulan setelah penemuan, kerentanan masih dapat dieksploitasi pada lusinan model perangkat.

Lebih buruknya lagi, kerentanan tersebut dieksploitasi secara aktif oleh peretas. Kini MediaTek telah beralih ke Google untuk menutup celah patch ini dan mengamankan jutaan perangkat dari eksploitasi keamanan penting ini.

Bagi pembaca yang belum mengetahuinya Pengembang XDA, kami adalah situs yang menjadi rumah bagi forum terbesar untuk modifikasi perangkat lunak Android. Biasanya, modifikasi ini berpusat pada mendapatkan akses root pada perangkat untuk menghapus bloatware, menginstal perangkat lunak khusus, atau mengubah parameter sistem default. Tablet Fire milik Amazon adalah target populer bagi para penghobi peretas di forum kami—mereka penuh dengan tablet yang tidak dapat dicopot pemasangannya bloatware, tidak memiliki akses ke aplikasi perangkat lunak dasar seperti Google Play Store, dan yang terpenting, sangat banyak murah. Tantangan dalam melakukan rooting pada tablet Amazon Fire adalah tablet tersebut dikunci secara ketat untuk mencegah pengguna keluar dari taman bertembok Amazon; Amazon tidak menyediakan metode resmi untuk membuka kunci bootloader tablet Fire, yang biasanya merupakan langkah pertama dalam melakukan rooting pada perangkat Android tertentu. Oleh karena itu, satu-satunya cara untuk melakukan root pada tablet Amazon Fire (tanpa modifikasi perangkat keras) adalah dengan menemukan eksploitasi dalam perangkat lunak yang memungkinkan pengguna melewati model keamanan Android. Pada bulan Februari 2019, itu persis seperti yang dilakukan diplomat Anggota Senior XDA ketika dia menerbitkan thread di forum tablet Amazon Fire kami. Dia segera menyadari bahwa eksploitasi ini memiliki cakupan yang jauh lebih luas daripada hanya tablet Fire milik Amazon.

Setelah sedikit pengujian dari diplomat Anggota XDA dan anggota komunitas lainnya, dipastikan bahwa eksploitasi ini berfungsi pada sejumlah besar chip MediaTek. Penulis menyatakan bahwa eksploitasi tersebut bekerja pada "hampir semua chip 64-bit MediaTek," dan mereka secara khusus menyebutkan yang berikut ini sebagai rentan: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8173, MT8176, MT8183, MT6 580, dan MT6595. Karena banyaknya chipset MediaTek yang terpengaruh oleh eksploitasi ini, eksploitasi tersebut diberi nama "MediaTek-su," atau disingkat "MTK-su". Pada 17 April 2019, diplomat menerbitkan thread kedua berjudul "Root Temp Luar Biasa untuk MediaTek ARMv8" di forum "Lain-lain Pengembangan Android" kami. Di thread ini, dia membagikan skrip yang dapat dijalankan pengguna untuk memberi mereka akses pengguna super di shell, serta set SELinux, modul kernel Linux yang menyediakan kontrol akses untuk proses, hingga "permisif" yang sangat tidak aman negara. Bagi pengguna untuk mendapatkan akses root dan mengatur SELinux agar permisif pada perangkat mereka sendiri sangatlah mudah dilakukan: Yang harus Anda lakukan hanyalah menyalin skrip ke folder sementara, ubah direktori tempat skrip disimpan, tambahkan izin yang dapat dieksekusi ke skrip, lalu jalankan naskah.

Anggota komunitas XDA mengonfirmasi bahwa eksploitasi tersebut berhasil setidaknya pada perangkat berikut:

1. Acer Iconia Satu 10 B3-A30
2. Acer Iconia Satu 10 B3-A40
3. Seri tablet Alba
4. Seri Alcatel 1 5033
5. Alcatel 1C
6. Alcatel 3L (2018) seri 5034
7. Alcatel 3T 8
8. Seri Alcatel A5 LED 5085
9. Seri Alcatel A30 5049
10. Alcatel Idola 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 -- hanya hingga Fire OS 6.3.1.2 build 0002517050244
15. Amazon Fire HD 8 2016 -- hanya hingga Fire OS 5.3.6.4 build 626533320
16. Amazon Fire HD 8 2017 -- hanya hingga Fire OS 5.6.4.0 build 636558520
17. Amazon Fire HD 8 2018 -- hanya hingga Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 -- hanya hingga Fire OS 5.6.4.0 build 636558520
19. Amazon Fire HD 10 2019 -- hanya hingga Fire OS 7.3.1.0
20. Amazon Fire TV 2 -- hanya hingga Fire OS 5.2.6.9
21. ASUS ZenFone Max Ditambah X018D
22. ASUS ZenPad 3s 10 Z500M
23. Seri berbasis ASUS ZenPad Z3xxM(F) MT8163
24. Barnes & Noble NOOK Tablet 7" BNTV450 & BNTV460
25. Tablet Barnes & Noble NOOK 10,1" BNTV650
26. Blackview A8 Maks
27. Blackview BV9600 Pro (Helio P60)
28. BLU Hidup Maks
29. BLU Hidup Satu X
30. Seri BLU R1
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. KUCING S41
40. Coolpad Keren Mainkan 8 Lite
41. Sentuhan Naga K10
42. Perasaan Gema
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Seri Huawei Y6II MT6735
48. Lava Iris 88S
49. Seri Lenovo C2
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. Dinasti Penghormatan LG
55. Seri LG X power 2/M320 (MTK)
56. Seri LG Xpression Plus 2/K40 LMX420
57. Lumigon T3
58. Meizu M5c
59. Meizu M6
60. Meizu Pro 7 Ditambah
61. Nokia 1
62. Nokia 1 Ditambah
63. Nokia 3
64. Nokia 3.1
65. Nokia 3.1 Ditambah
66. Nokia 5.1
67. Nokia 5.1 Ditambah/X5
68. Pada tablet Android 7".
69. Seri tablet Onn 8" & 10" (MT8163)
70. OPPO A5s
71. Seri OPPO F5/A73 -- Android 8.x saja
72. Seri OPPO F7 -- Android 8.x saja
73. Seri OPPO F9 -- Android 8.x saja
74. Oukitel K12
75. Benar-benar D7
76. realme 1
77. Sony Xperia C4
78. Seri Sony Xperia C5
79. Sony Xperia L1
80. Sony Xperia L3
81. Seri Sony Xperia XA
82. Seri Sony Xperia XA1
83. Telekomunikasi Selatan Smartab ST1009X (MT8167)
84. Seri TECNO Spark 3
85. Seri Umidigi F1
86. Kekuatan Umidigi
87. Naik Wiko
88. Wiko Cerah
89. Tampilan Wiko3
90. Seri Xiaomi Redmi 6/6A
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

Baca selengkapnya

Kecuali ponsel berbasis MediaTek dari Vivo, Huawei/Honor (setelah Android 8.0+), OPPO (setelah Android 8.0+), dan Samsung, anggota komunitas XDA menemukan bahwa MediaTek-su bekerja lebih sering ketika dicoba pada perangkat yang terpengaruh chipset. Menurut diplomat Anggota XDA, perangkat Vivo, Huawei/Honor, OPPO, dan Samsung "menggunakan modifikasi kernel untuk mencegah akses root melalui eksploitasi," yang berarti pengembang perlu menggali kode sumber kernel perangkat ini untuk membuat "versi yang disesuaikan" dari mengeksploitasi. Upaya tambahan tersebut tidak sebanding dengan upaya yang dilakukan, sehingga pengembang memilih untuk tidak menambahkan dukungan untuk perangkat ini meskipun, "secara teori", eksploitasi tersebut masih dapat berfungsi.

Saat ini, sudah jelas bahwa eksploitasi ini memengaruhi sejumlah besar perangkat di pasar. Chip MediaTek memberi daya pada ratusan model ponsel cerdas murah dan kelas menengah, tablet murah, dan di luar merek dekoder, sebagian besar dijual tanpa mengharapkan pembaruan tepat waktu dari pabrikan. Oleh karena itu, banyak perangkat yang masih terpengaruh oleh MediaTek-su kemungkinan besar tidak akan mendapatkan perbaikan selama berminggu-minggu atau berbulan-bulan setelah pengungkapan hari ini, jika pun mereka mendapatkan perbaikan sama sekali. Jadi apa yang membuat MediaTek-su mendapatkan tingkat keparahan "Kritis" dengan a CVSS v3.0 skor 9,3?

Mengapa MTK-su merupakan Kerentanan Keamanan Kritis

Sekali lagi, cara umum untuk mendapatkan akses root pada perangkat Android adalah dengan membuka kunci bootloader terlebih dahulu, yang menonaktifkan verifikasi partisi boot. Setelah bootloader dibuka kuncinya, pengguna dapat memasukkan biner pengguna super ke sistem dan juga aplikasi manajemen pengguna super untuk mengontrol proses mana yang memiliki akses ke root. Membuka kunci bootloader berarti menonaktifkan salah satu fitur keamanan utama pada perangkat dengan sengaja, itulah sebabnya pengguna harus secara eksplisit mengizinkan hal itu terjadi dengan biasanya mengaktifkan tombol alih di Opsi Pengembang dan kemudian mengeluarkan perintah buka kunci ke pemuat boot. Namun dengan MediaTek-su, pengguna tidak perlu membuka kunci bootloader untuk mendapatkan akses root. Sebaliknya, yang harus mereka lakukan hanyalah menyalin skrip ke perangkat mereka dan menjalankannya di shell. Namun, pengguna bukanlah satu-satunya yang dapat melakukan hal ini. Aplikasi apa pun di ponsel Anda dapat menyalin skrip MediaTek-su ke direktori pribadinya dan kemudian menjalankannya untuk mendapatkan akses root di shell. Faktanya, Anggota XDA diplomatis menyoroti kemungkinan ini di thread forum mereka ketika mereka menyarankan serangkaian instruksi alternatif menggunakan salah satu dari itu Terminal Emulator untuk aplikasi Android atau Termux ketimbang ADB.

Dengan akses root, model keamanan Android pada dasarnya berantakan. Misalnya, izin menjadi tidak berarti dalam konteks root karena aplikasi dengan akses ke shell root dapat memberikan izin apa pun yang diinginkannya. Selain itu, dengan shell root, keseluruhan partisi data—termasuk file yang disimpan dalam direktori data pribadi aplikasi yang biasanya tidak dapat diakses—dapat diakses. Aplikasi dengan root juga dapat secara diam-diam menginstal aplikasi lain apa pun yang diinginkannya di latar belakang dan kemudian memberi mereka izin apa pun yang mereka perlukan untuk melanggar privasi Anda. Menurut Pengembang yang Diakui XDA topjohnwu, aplikasi jahat bahkan dapat "menyuntikkan kode langsung ke Zygote dengan menggunakan ptrace", yang berarti aplikasi normal di perangkat Anda dapat dibajak untuk melakukan perintah penyerang. Contoh-contoh ini hanya membahas beberapa cara aplikasi dapat melanggar kepercayaan Anda di latar belakang tanpa sepengetahuan Anda. Namun, aplikasi berbahaya dapat mendatangkan malapetaka pada perangkat Anda tanpa menyembunyikan tindakannya. Ransomware, misalnya, adalah sangat ampuh dengan akses root; jika Anda tidak membayar, aplikasi ransomware hipotetis bisa melakukannya secara menyeluruh dan tidak dapat diubah lagi membuat perangkat Anda tidak dapat dioperasikan dengan menghapus seluruh perangkat hingga bersih.

Satu-satunya "kelemahan" di MediaTek-su adalah ia hanya memberikan aplikasi akses root "sementara", yang berarti bahwa suatu proses kehilangan akses pengguna super setelah perangkat di-boot ulang. Selanjutnya pada perangkat yang menjalankan Android 6.0 Marshmallow ke atas, kehadiran Boot Terverifikasi dan dm-verity memblokir modifikasi pada partisi read-only seperti sistem dan vendor. Namun, kedua faktor ini sebagian besar hanya menjadi penghalang bagi para modder di forum kami, bukan pelaku jahat. Untuk mengatasi keterbatasan root sementara, aplikasi jahat cukup menjalankan ulang skrip MediaTek-su setiap kali boot. Di sisi lain, tidak ada kebutuhan untuk mengatasi dm-verity karena modifikasi permanen pada sistem atau partisi vendor kemungkinan besar tidak menarik minat sebagian besar pembuat malware; lagipula, sudah ada ton tentang hal-hal yang dapat dilakukan aplikasi berbahaya dengan shell root.

Jika Anda bertanya-tanya secara teknis apa yang dieksploitasi MediaTek-su, MediaTek membagikan bagan di bawah ini kepada kami yang merangkum titik masuknya. Cacat tersebut tampaknya ada di salah satu driver Kernel Linux MediaTek yang disebut “CMDQ.” Deskripsinya menyatakan bahwa, "dengan menjalankan IOCTL perintah di node perangkat CMDQ," penyerang lokal dapat "secara sewenang-wenang membaca/menulis memori fisik, membuang tabel simbol kernel ke buffer DMA yang telah dialokasikan sebelumnya, [dan] memanipulasi buffer DMA untuk mengubah pengaturan kernel guna menonaktifkan SELinux dan meningkatkan ke 'root' hak istimewa."

Menurut bagan yang dibagikan MediaTek kepada kami, kerentanan ini memengaruhi perangkat MediaTek dengan Kernel Linux versi 3.18, 4.4, 4.9, atau 4.14 yang menjalankan Android versi 7 Nougat, 8 Oreo, atau 9 Pie. Kerentanan ini tampaknya tidak dapat dieksploitasi pada perangkat MediaTek yang menjalankan Android 10, karena "izin akses CMDQ node perangkat juga diterapkan oleh SELinux." Mitigasi ini kemungkinan besar berasal dari pembaruan pada BSP MediaTek, bukan dari Android diri. Satu-satunya mitigasi Android 10 untuk kerentanan ini adalah pembatasan pada aplikasi yang menjalankan binari di direktori home-nya; namun, seperti yang dicatat oleh topjohnwu Pengembang yang Diakui XDA, aplikasi jahat dapat dengan mudah menjalankan kode MediaTek-su di perpustakaan dinamis.

Meskipun MediaTek telah menambal masalah ini di semua chipset yang terkena dampak, mereka tidak dapat memaksa pembuat perangkat untuk menerapkan tambalan tersebut. MediaTek memberi tahu kami bahwa mereka telah menyiapkan patch sejak Mei 2019. Amazon, tidak mengherankan, segera menambal masalah ini di seluruh perangkatnya setelah mereka menyadarinya. Namun, 10 bulan telah berlalu sejak MediaTek menyediakan perbaikan untuk mitranya, namun masih belum berhasil Maret 2020, puluhan OEM belum memperbaiki perangkatnya. Sebagian besar perangkat yang terkena dampak berada pada rilis Android lama dengan Tingkat Patch Keamanan Android (SPL) yang sudah ketinggalan zaman, dan situasi pembaruan bahkan lebih buruk lagi jika Anda mempertimbangkan ratusan model perangkat yang kurang dikenal menggunakan chip MediaTek ini. MediaTek memiliki serius masalah sedang ditangani di sini, jadi mereka meminta bantuan Google.

Berbeda dengan MediaTek, Google Bisa memaksa OEM untuk memperbarui perangkat mereka melalui perjanjian lisensi atau istilah program (seperti Android One). Agar OEM dapat menyatakan bahwa suatu perangkat mematuhi Security Patch Level (SPL) 2020-03-05, perangkat tersebut harus menyertakan semua kerangka kerja, Kernel Linux, dan perbaikan driver vendor yang berlaku di Buletin Keamanan Android Maret 2020, yang mencakup perbaikan untuk CVE-2020-0069, atau MediaTek-su. (Google sepertinya tidak menerapkan hal itu OEM sebenarnya menggabungkan semua patch ketika mendeklarasikan SPL tertentu.) Sekarang setelah buletin Maret 2020 keluar, cerita ini seharusnya sudah berakhir, bukan? Sayangnya, kita juga harus menahan diri dari Google karena menunda-nunda penerapan patch tersebut.

Cacat dalam proses patch keamanan

Jika hal ini belum jelas, tidak semua kerentanan keamanan harus dimasukkan ke dalam Buletin Keamanan Android. Banyak kerentanan ditemukan dan ditambal oleh vendor tanpa pernah muncul di buletin bulanan. MediaTek-su seharusnya menjadi salah satunya, namun karena berbagai alasan, beberapa OEM gagal mengintegrasikan patch yang ditawarkan oleh MediaTek. (Ada banyak kemungkinan penyebabnya, mulai dari kurangnya sumber daya, keputusan bisnis, hingga kegagalan dalam komunikasi.) Ketika saya sebelumnya menyatakan bahwa MediaTek "meminta bantuan Google", hal ini menyiratkan bahwa MediaTek secara aktif mencari bantuan dari Google agar OEM akhirnya memperbaiki masalah mereka. perangkat. Namun, kenyataannya mungkin tidak demikian. Berdasarkan pemahaman saya, Google tidak mengetahui adanya MediaTek-su hingga hal tersebut secara tidak sengaja disebutkan dalam laporan keamanan dari TrendMicro diterbitkan 6 Januari 2020. Dalam laporan tersebut, TrendMicro sedang mendokumentasikan lain kerentanan keamanan, dijuluki "gunakan-setelah-bebas dalam driver pengikat" kerentanan, yang secara aktif dieksploitasi di alam liar. TrendMicro mencatat bagaimana tiga aplikasi berbahaya mendapatkan akses root menggunakan salah satu dari dua metode, yaitu kerentanan "use-after-free in binder driver" atau MediaTek-su.

Dalam kode itu TrendMicro dibagikan, kita dapat melihat dengan jelas bagaimana aplikasi jahat menargetkan model perangkat tertentu (mis. Nokia 3, OPPO F9, dan Redmi 6A) dan menggunakan MediaTek-su di dalamnya.

Saya tidak bisa membelanya TrendMicro, namun tampaknya mereka tidak menyadari bahwa MediaTek-su adalah eksploitasi yang belum ditambal. Fokus mereka adalah pada eksploitasi "use-after-free in binder driver", dan penemuan penggunaan MediaTek-su sepertinya hanya sebuah renungan. (Saya yakin jika TrendMicro mengetahui situasi seputar MediaTek-su, mereka akan mengoordinasikan upaya pengungkapannya dengan Google.) Kami hanya diberi tahu ini mengeksploitasi diri kami sendiri pada tanggal 5 Februari 2020, dan setelah menyelidiki sendiri seberapa buruknya, kami menghubungi Google mengenai hal ini pada tanggal 7 Februari, 2020. Google sangat prihatin dengan dampak dari publikasi MediaTek-su sehingga mereka meminta kami untuk menunda penerbitan cerita ini hingga hari ini. Setelah mempertimbangkan kerugian yang tidak dapat diperbaiki yang dapat ditimbulkan pada pengguna yang menjadi sasaran penggunaan malware MediaTek-su, kami sepakat untuk menunda cerita ini hingga pengumuman Android Maret 2020 Buletin Keamanan. Namun, mengingat berapa lama waktu yang dibutuhkan banyak perangkat untuk mendapatkan pembaruan keamanan terbaru, jika memang demikian memahaminya, pasti ada banyak sekali perangkat yang masih rentan terhadap MediaTek-su dalam beberapa bulan ke depan Sekarang. Hal ini seharusnya menjadi hal yang mengerikan bagi siapa pun yang memiliki perangkat yang rentan.

Meskipun kerentanan tingkat keparahan yang sangat serius dan "kritis" ini dieksploitasi secara aktif di alam liar, hanya Google saja memasukkan perbaikan untuk masalah ini ke dalam buletin bulan Maret 2020, yaitu sekitar 2 bulan setelah mereka mengetahui adanya masalah. Meskipun Google memberi tahu mitra Androidnya tentang Buletin Keamanan Android terbaru, 30 hari penuh sebelum buletin dipublikasikan (mis. OEM diberi tahu tentang isi buletin Maret 2020 pada awal Februari 2020), Google dapat, dan sering kali memang demikian, memperbarui buletin dengan perubahan atau perbaikan baru. Mengapa Google tidak memilih untuk mempercepat penyertaan patch untuk masalah serius seperti ini berada di luar jangkauan saya, terutama ketika MediaTek telah memperbaikinya 10 bulan yang lalu. Jika bug seperti itu ditemukan di perangkat Apple, saya yakin mereka akan mengeluarkan perbaikan jauh lebih cepat. Google pada dasarnya mengandalkan taruhan berisiko bahwa MediaTek-su akan tetap terlihat low profile hingga buletin bulan Maret 2020 diterbitkan. Meskipun Google tampaknya beruntung dalam hal ini, kami tidak tahu berapa banyak pembuat malware yang sudah mengetahui eksploitasi tersebut. Lagi pula, itu sudah ada di thread forum XDA acak hampir setahun penuh.

Ada satu pihak lagi dalam bencana ini yang belum banyak saya bahas, dan pihak tersebut adalah pihak yang melakukan eksploitasi, diplomat Anggota XDA. Yang patut disyukuri, menurut saya dia tidak mempunyai niat jahat dalam menerbitkan MediaTek-su. Kita dapat dengan jelas menelusuri asal muasal eksploitasi tersebut hingga keinginan diplomat untuk memodifikasi tablet Amazon Fire. Diplomatic memberi tahu saya bahwa tujuan utamanya mengembangkan metode root ini adalah untuk membantu masyarakat. Menyesuaikan perangkat Anda adalah inti dari XDA, dan upaya diplomasi di komunitas adalah hal yang disukai orang-orang di forum. Meskipun penolakan diplomat terhadap proyek open source menimbulkan beberapa kekhawatiran, dia menjelaskan bahwa dia ingin komunitas menikmati akses root ini selama mungkin. Ketika saya pertama kali menghubungi diplomat, dia juga menyatakan bahwa dia berkolaborasi dengan beberapa mitra yang menghalangi dia untuk membagikan kode sumber dan penelitian proyek tersebut. Meskipun saya tidak bisa mendapatkan rincian lebih lanjut tentang kolaborasi ini, saya bertanya-tanya apakah diplomat akan memilih untuk mengumumkan eksploitasi ini kepada publik jika MediaTek menawarkan program bug bounty. Saya tidak dapat membayangkan kerentanan sebesar ini tidak akan menghasilkan banyak uang jika MediaTek benar-benar memiliki program seperti itu. Diplomatik mengklaim bahwa eksploitasi ini telah dimungkinkan sejak chipset MediaTek MT6580 pada akhir tahun 2015, jadi kita bertanya-tanya apakah diplomat adalah orang pertama yang menemukan eksploitasi ini. Dia memberi tahu saya bahwa dia tidak tahu bahwa MediaTek-su secara aktif dieksploitasi hingga artikel ini diterbitkan.

Jika Anda ingin memeriksa apakah perangkat Anda rentan terhadap MediaTek-su, jalankan skrip secara manual yang diposting oleh diplomat Anggota XDA di utas forum XDA ini. Jika Anda memasukkan shell root (Anda akan mengetahui kapan simbol berubah dari $ menjadi #), maka Anda akan mengetahui bahwa eksploitasi tersebut berfungsi. Jika berhasil, Anda harus menunggu produsen perangkat Anda meluncurkan pembaruan yang menambal MediaTek-su. Jika perangkat Anda melaporkan Tingkat Patch Keamanan 05-03-2020, yang merupakan SPL terbaru Maret 2020, maka hampir pasti perangkat tersebut terlindungi dari MediaTek-su. Jika tidak, Anda harus memeriksa apakah perangkat Anda rentan.

---

Pembaruan 1 (3/2/2020 @ 21:45 EST): Artikel ini diperbarui untuk mengklarifikasi bahwa diplomat Anggota XDA sebenarnya menyadari cakupan kerentanan ini begitu dia menemukannya pada bulan Februari 2019, tetapi dia tidak mengetahui penggunaan eksploitasi tersebut di alam liar hingga publikasi ini artikel. Kami juga mengoreksi kata-kata kami mengenai salah satu alasan mengapa diplomat menolak membagikan kode sumber proyek.