Krytyczny rootkit MediaTek wpływa na miliony urządzeń z Androidem

W pierwszy poniedziałek każdego miesiąca Google publikuje Biuletyn dotyczący bezpieczeństwa Androida, strona ujawniająca wszystkie luki w zabezpieczeniach i ich poprawki przesłane przez samą firmę Google lub inne strony trzecie. Dzisiejszy dzień nie był wyjątkiem: Google właśnie upublicznił Biuletyn bezpieczeństwa Androida na marzec 2020 r. Jedną z luk udokumentowanych w najnowszym biuletynie jest CVE-2020-0069, krytyczny exploit bezpieczeństwa, w szczególności rootkita, który dotyczy milionów urządzeń z chipsetami MediaTek, dużej tajwańskiej firmy projektującej chipy. Chociaż biuletyn bezpieczeństwa Androida z marca 2020 r. wydaje się być pierwszym publicznym ujawnieniem CVE-2020-0069, szczegóły exploita krążą po Internecie – a dokładniej na forach XDA-Developers – od kwietnia z 2019 roku. Mimo że MediaTek udostępnił łatkę miesiąc po odkryciu, lukę nadal można wykorzystać w dziesiątkach modeli urządzeń.

Co gorsza, luka jest aktywnie wykorzystywana przez hakerów. Teraz MediaTek zwrócił się do Google o uzupełnienie tej luki w łatce i zabezpieczenie milionów urządzeń przed tym krytycznym exploitem bezpieczeństwa.

Dla wszystkich czytelników, którzy nie znają Programiści XDA, jesteśmy witryną zawierającą największe fora dotyczące modyfikacji oprogramowania Android. Zwykle te modyfikacje skupiają się na uzyskaniu dostępu do roota na urządzeniach w celu usunięcia bloatware, zainstalowania niestandardowego oprogramowania lub dostosowania domyślnych parametrów systemowych. Tablety Fire firmy Amazon są popularnym celem hakerów-hobbystów na naszych forach — jest ich mnóstwo i można je odinstalować bloatware, brak dostępu do podstawowych aplikacji, takich jak Sklep Google Play, i co najważniejsze, są bardzo tani. Wyzwanie związane z rootowaniem tabletów Amazon Fire polega na tym, że są one mocno zablokowane, aby uniemożliwić użytkownikom wyjście poza otoczony murem ogród Amazon; Amazon nie zapewnia oficjalnej metody odblokowania modułu ładującego tabletów Fire, co zwykle jest pierwszym krokiem do zrootowania dowolnego urządzenia z Androidem. Dlatego jedynym sposobem na zrootowanie tabletu Amazon Fire (bez modyfikacji sprzętowych) jest znalezienie exploita w oprogramowaniu, który pozwala użytkownikowi ominąć model zabezpieczeń Androida. W lutym 2019 r. tj dokładnie to, co zrobił starszy członek dyplomacji XDA kiedy opublikował wątek na naszych forach dotyczących tabletów Amazon Fire. Szybko zdał sobie sprawę, że zakres tego exploita był znacznie szerszy niż tylko tablety Fire firmy Amazon.

Po krótkich testach przeprowadzonych przez dyplomatów będących członkami XDA i innych członków społeczności potwierdzono, że ten exploit działa na dużej liczbie chipów MediaTek. Autor twierdzi, że exploit działa na „praktycznie wszystkich 64-bitowych chipach MediaTek” i jako szczególnie podatne wymienia następujące luki: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8 173, MT8176, MT8183, MT6580 i MT6595. Ze względu na liczbę chipsetów MediaTek dotkniętych tym exploitem, exploitowi nadano w skrócie nazwę „MediaTek-su” lub „MTK-su”. W dniu 17 kwietnia 2019 r. w serwisie dyplomatycznym pojawił się drugi wątek pt. „Niesamowity root tymczasowy dla MediaTek ARMv8” na naszym forum „Różne rozwój Androida”. W tym wątku udostępnił skrypt, który użytkownicy mogą wykonać, aby przyznać im dostęp superużytkownika w powłoce, a także ustawić SELinux, moduł jądra Linuksa zapewniający kontrolę dostępu do procesów wysoce niepewnym „permisywnym” państwo. Aby użytkownik mógł uzyskać dostęp do konta root i ustawić SELinux w tryb zezwalający na swoim własnym urządzeniu, jest to szokująco łatwe: wystarczy skopiować plik skrypt do folderu tymczasowego, zmień katalogi, w których przechowywany jest skrypt, dodaj uprawnienia do wykonywania skryptu, a następnie wykonaj scenariusz.

Członkowie społeczności XDA potwierdzili, że exploit działał na co najmniej następujących urządzeniach:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Seria tabletów Alba
4. Seria Alcatel 1 5033
5. Alcatela 1C
6. Seria Alcatel 3L (2018) 5034
7. Alcatela 3T 8
8. Seria Alcatel A5 LED 5085
9. Seria Alcatel A30 5049
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 — tylko do Fire OS 6.3.1.2, kompilacja 0002517050244
15. Amazon Fire HD 8 2016 — tylko Fire OS 5.3.6.4, kompilacja 626533320
16. Amazon Fire HD 8 2017 — tylko Fire OS 5.6.4.0, kompilacja 636558520
17. Amazon Fire HD 8 2018 – tylko do Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 — tylko Fire OS 5.6.4.0, kompilacja 636558520
19. Amazon Fire HD 10 2019 – tylko do Fire OS 7.3.1.0
20. Amazon Fire TV 2 – tylko do Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. Seria ASUS ZenPad Z3xxM(F) MT8163
24. Barnes & Noble NOOK Tablet 7" BNTV450 i BNTV460
25. Tablet Barnes & Noble NOOK 10,1 cala BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Życie Max
29. BLU Life One X
30. Seria BLU R1
31. BLU R2 LTE
32. NIEBIESKI 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. KOT S41
40. Coolpad Cool Play 8 Lite
41. Dragon Touch K10
42. Uczucie echa
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Seria Huawei Y6II MT6735
48. Lawa Irys 88S
49. Seria Lenovo C2
50. Karta Lenovo E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. Dynastia hołdu LG
55. Seria LG X power 2/M320 (MTK)
56. Seria LG Xpression Plus 2/K40 LMX420
57. Lumigona T3
58. Meizu M5c
59. Meizu M6
60. Meizu Pro 7 Plus
61. Nokia 1
62. Nokii 1 Plus
63. Nokii 3
64. Nokii 3.1
65. Nokii 3.1 Plus
66. Nokii 5.1
67. Nokii 5.1 Plus/X5
68. Onn 7-calowy tablet z Androidem
69. Seria tabletów Onn 8" i 10" (MT8163)
70. OPPO A5
71. Seria OPPO F5/A73 – tylko Android 8.x
72. Seria OPPO F7 – tylko Android 8.x
73. Seria OPPO F9 – tylko Android 8.x
74. Oukitel K12
75. Zdecydowanie D7
76. Realme 1
77. Sony Xperia C4
78. Seria Sony Xperia C5
79. Sony Xperia L1
80. Sony Xperia L3
81. Seria Sony Xperia XA
82. Seria Sony Xperia XA1
83. Southern Telecom Smartab ST1009X (MT8167)
84. Seria TECNO Spark 3
85. Seria Umidigi F1
86. Moc Umidigi
87. Wiko Jazda
88. Wiko Sunny
89. Widok Wiko3
90. Seria Xiaomi Redmi 6/6A
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest5 Z3351S

Czytaj więcej

Z wyjątkiem telefonów opartych na MediaTek firm Vivo, Huawei/Honor (po Androidzie 8.0+), OPPO (po Androidzie 8.0+) i Członkowie społeczności Samsung i XDA odkryli, że MediaTek-su działa częściej niż w przypadku prób na urządzeniach, których dotyczy problem chipsety. Według członków dyplomacji XDA, urządzenia Vivo, Huawei/Honor, OPPO i Samsung „wykorzystują modyfikacje jądra, aby uniemożliwić dostęp do konta root za pośrednictwem exploity”, co oznacza, że ​​programista będzie musiał zagłębić się w kod źródłowy jądra tych urządzeń, aby stworzyć „wersje dostosowane do indywidualnych potrzeb” wykorzystać. Nie było to warte dodatkowego wysiłku, więc programista zdecydował się nie dodawać obsługi tych urządzeń, mimo że „teoretycznie” exploit mógł nadal działać.

Powinno już być jasne, że exploit ten wpływa na dużą liczbę urządzeń dostępnych na rynku. Chipy MediaTek zasilają setki budżetowych i średniej klasy modeli smartfonów, tanich tabletów i produktów innych niż marka dekodery, z których większość jest sprzedawana bez oczekiwania na terminowe aktualizacje od producenta. Dlatego jest mało prawdopodobne, aby wiele urządzeń, na które nadal wpływa MediaTek-su, zostało naprawionych w ciągu kilku tygodni lub miesięcy od dzisiejszego ujawnienia, jeśli w ogóle takową otrzymają. Co więc sprawia, że ​​MediaTek-su osiąga poziom „Krytyczny” dzięki CVSS wersja 3.0 wynik 9,3?

Dlaczego MTK-su stanowi krytyczną lukę w zabezpieczeniach

Powtórzę, typowym sposobem uzyskania dostępu do roota na urządzeniu z Androidem jest najpierw odblokowanie programu ładującego, co uniemożliwia weryfikację partycji rozruchowej. Po odblokowaniu programu ładującego użytkownik może wprowadzić do systemu plik binarny superużytkownika, a także aplikację do zarządzania superużytkownikiem, aby kontrolować, które procesy mają dostęp do roota. Odblokowanie bootloadera powoduje celowe wyłączenie jednej z kluczowych funkcji bezpieczeństwa na urządzeniu, dlatego użytkownik musi wyraźnie zezwól na to, zazwyczaj włączając przełącznik w Opcjach programisty, a następnie wydając polecenie odblokowania program rozruchowy. Jednak w przypadku MediaTek-su użytkownik nie musi odblokowywać programu ładującego, aby uzyskać dostęp do konta root. Zamiast tego wystarczy, że skopiuje skrypt na swoje urządzenie i uruchomi go w powłoce. Jednak użytkownik nie jest jedyną osobą, która może to zrobić. Każda aplikacja na Twoim telefonie może skopiować skrypt MediaTek-su do swojego prywatnego katalogu, a następnie uruchomić go, aby uzyskać dostęp do konta root w powłoce. W rzeczywistości członek XDA dyplomatyczny podkreśla tę możliwość w swoim wątku na forum, gdy sugerują alternatywny zestaw instrukcji, używając albo Emulator terminala dla aplikacji na Androida Lub Termux zamiast ADB.

Przy dostępie do roota model bezpieczeństwa Androida w zasadzie się rozpada. Na przykład uprawnienia stają się bez znaczenia w kontekście roota, ponieważ aplikacja mająca dostęp do powłoki roota może przyznać sobie dowolne uprawnienia. Co więcej, dzięki powłoce głównej dostępna jest cała partycja danych – łącznie z plikami przechowywanymi w zazwyczaj niedostępnych prywatnych katalogach danych aplikacji. Aplikacja z uprawnieniami roota może także po cichu zainstalować w tle dowolną inną aplikację, a następnie przyznać jej wszelkie uprawnienia potrzebne do naruszenia Twojej prywatności. Według uznanego programisty XDA topjohnwuzłośliwa aplikacja może nawet „wstrzyknąć kod bezpośrednio do Zygote za pomocą ptrace”, co oznacza, że ​​zwykła aplikacja na Twoim urządzeniu może zostać przejęta, aby wykonać polecenie atakującego. Te przykłady dotyczą tylko kilku sposobów, w jakie aplikacja może naruszyć Twoje zaufanie w tle bez Twojej wiedzy. Jednak złośliwe aplikacje mogą siać spustoszenie na Twoim urządzeniu, nie ukrywając tego, co robią. Ransomware jest na przykład niezwykle silny z dostępem do roota; jeśli nie zapłacisz, może to zrobić hipotetyczna aplikacja ransomware całkowicie i nieodwracalnie uniemożliwić korzystanie z urządzenia, wycierając całe urządzenie do czysta.

Jedyną „słabością” MediaTek-su jest to, że przyznaje aplikacji jedynie „tymczasowy” dostęp do roota, co oznacza, że ​​proces traci dostęp administratora po ponownym uruchomieniu urządzenia. Ponadto na urządzeniach z systemem Android 6.0 Marshmallow i nowszym obecność Zweryfikowany rozruch i dm-verity blokuj modyfikacje partycji tylko do odczytu, takich jak system i dostawca. Jednakże te dwa czynniki są w większości jedynie przeszkodami dla modderów na naszych forach, a nie złośliwymi aktorami. Aby pokonać ograniczenia tymczasowego roota, złośliwa aplikacja może po prostu ponownie uruchomić skrypt MediaTek-su przy każdym uruchomieniu. Z drugiej strony nie ma potrzeby przezwyciężać dm-verity, ponieważ trwałe modyfikacje systemu lub partycji dostawcy raczej nie zainteresują większości autorów szkodliwego oprogramowania; w końcu już są mnóstwo rzeczy, które złośliwa aplikacja może zrobić za pomocą powłoki roota.

Jeśli zastanawiasz się na poziomie technicznym, co wykorzystuje MediaTek-su, MediaTek udostępnił nam poniższą tabelę podsumowującą punkt wejścia. Usterka najwyraźniej występuje w jednym ze sterowników jądra systemu Linux firmy MediaTek o nazwie „CMDQ”. W opisie stwierdza się, że „wykonując IOCTL poleceń w węźle urządzenia CMDQ”, lokalny atakujący może „dowolnie czytać/zapisywać pamięć fizyczną, zrzucać tabelę symboli jądra do wstępnie przydzielony bufor DMA, [i] manipuluj buforem DMA, aby zmodyfikować ustawienia jądra, wyłączyć SELinux i eskalować do „root” przywilej."

Według wykresu, który udostępnił nam MediaTek, luka ta dotyczy urządzeń MediaTek z jądrem Linux w wersjach 3.18, 4.4, 4.9 lub 4.14 z systemem Android w wersjach 7 Nougat, 8 Oreo lub 9 Pie. Najwyraźniej luki nie można wykorzystać na urządzeniach MediaTek z systemem Android 10, ponieważ „zezwolenie na dostęp CMDQ węzły urządzeń są również wymuszane przez SELinux.” To ograniczenie prawdopodobnie wynika z aktualizacji BSP MediaTek, a nie z Androida samo. Jedynym rozwiązaniem, które w systemie Android 10 można zaradzić tej luce, jest jej ograniczenie aplikacji wykonujących pliki binarne w swoim katalogu domowym; Jednakże, jak zauważa topjohnwu, uznany programista XDA, złośliwa aplikacja może po prostu uruchomić kod MediaTek-su w bibliotece dynamicznej.

Mimo że firma MediaTek załatała ten problem we wszystkich chipsetach, których dotyczy problem, nie może zmusić producentów urządzeń do wdrożenia poprawek. MediaTek powiedział nam, że miał gotowe poprawki już w maju 2019 r. Nic dziwnego, że Amazon natychmiast załatał problem na swoich urządzeniach, gdy tylko zostały one o tym poinformowane. Minęło jednak 10 miesięcy, odkąd MediaTek udostępnił poprawkę swoim partnerom Marzec 2020 r., dziesiątki producentów OEM nie naprawiło swoich urządzeń. Większość dotkniętych urządzeń działa na starszych wersjach Androida z nieaktualnymi poziomami poprawek zabezpieczeń Androida (SPL), a sytuacja z aktualizacjami jest jeszcze gorsza, jeśli weźmie się pod uwagę setki mniej znanych modeli urządzeń wykorzystujących te chipy MediaTek. MediaTek ma poważny problem leży po jego stronie, więc zwrócili się o pomoc do Google.

W przeciwieństwie do MediaTeka, Google Móc zmusić producentów OEM do aktualizacji swoich urządzeń umowy licencyjne lub warunki programu (takie jak Android One). Aby producent OEM mógł zadeklarować, że urządzenie jest zgodne z poziomem poprawek zabezpieczeń (SPL) 2020-03-05, urządzenie musi zawierać wszystkie platformy, Jądro systemu Linux i odpowiednie poprawki sterowników dostawców zawarte w Biuletynie zabezpieczeń systemu Android z marca 2020 r., który zawiera poprawkę dla CVE-2020-0069 lub MediaTek-su. (Wydaje się, że Google tego nie egzekwuje Producenci OEM faktycznie łączą wszystkie poprawki chociaż deklarując określony SPL.) Teraz, gdy ukazał się biuletyn z marca 2020 r., ta historia powinna się zakończyć, prawda? Niestety, musimy także trzymać kciuki za Google, który ociąga się z włączaniem poprawek.

Błąd w procesie łatania zabezpieczeń

Jeśli nie jest to już jasne, nie każda luka w zabezpieczeniach musi znaleźć się w Biuletynie bezpieczeństwa Androida. Wiele luk w zabezpieczeniach jest wykrywanych i łatanych przez dostawców, a ich nie pojawianie się w comiesięcznym biuletynie. MediaTek-su powinien być jednym z nich, ale z wielu powodów kilku producentom OEM nie udało się zintegrować poprawek oferowanych przez MediaTek. (Istnieje wiele potencjalnych przyczyn, począwszy od braku zasobów, przez decyzje biznesowe, aż po błędy w komunikacji). Kiedy wcześniej stwierdził, że MediaTek „zwrócił się do Google” o pomoc, oznaczało to, że MediaTek aktywnie szukał pomocy od Google, aby nakłonić producentów OEM do ostatecznej naprawy swoich urządzenia. Jednak w rzeczywistości mogło tak nie być. Rozumiem, że Google nie wiedział o MediaTek-su, dopóki nie zostało to przypadkowo poruszone w raporcie bezpieczeństwa z TrendMikro opublikowano 6 stycznia 2020 r. W raporcie TrendMikro dokumentował inny lukę w zabezpieczeniach, zwaną „do wykorzystania po bezpłatnym w sterowniku spoiwa„luka, która była aktywnie wykorzystywana na wolności. TrendMikro zauważył, jak trzy złośliwe aplikacje uzyskały dostęp do konta root przy użyciu jednej z dwóch metod: luki w sterowniku segregatora „użyj po zwolnieniu” lub MediaTek-su.

W kodzie to TrendMikro udostępnione, możemy wyraźnie zobaczyć, w jaki sposób złośliwe aplikacje atakowały określone modele urządzeń (np. Nokia 3, OPPO F9 i Redmi 6A) i wykorzystując na nich MediaTek-su.

Nie mogę mówić TrendMikro, ale wygląda na to, że nie zdawali sobie sprawy, że MediaTek-su to jeszcze niezałatany exploit. W końcu skupili się na exploitze „użyj po zwolnieniu w sterowniku spoiwa”, a odkrycie użycia MediaTek-su wydaje się, że zostało przemyślane. (Jestem pewien, że jeśli TrendMikro byli świadomi sytuacji wokół MediaTek-su, skoordynowaliby swoje wysiłki w zakresie ujawniania informacji z Google). Zostaliśmy jedynie poinformowani o tym wykorzystaliśmy to 5 lutego 2020 r. i po samodzielnym sprawdzeniu, jak źle to było, 7 lutego skontaktowaliśmy się w tej sprawie z Google, 2020. Google był tak zaniepokojony konsekwencjami upublicznienia MediaTek-su, że poprosił nas o wstrzymanie się z publikacją tej historii do dzisiaj. Po rozważeniu nieodwracalnych szkód, jakie mogą zostać wyrządzone użytkownikom będącym celem szkodliwego oprogramowania MediaTek-su, zgodziliśmy się wstrzymać tę historię do czasu ogłoszenia Androida w marcu 2020 r. Biuletyn Bezpieczeństwa. Biorąc jednak pod uwagę, ile czasu zajmie wielu urządzeniom uzyskanie najnowszej aktualizacji zabezpieczeń, jeśli w ogóle to nastąpi w ogóle to zrozumiesz, za kilka miesięcy z pewnością mnóstwo urządzeń będzie nadal podatnych na działanie MediaTek-su Teraz. To powinno być przerażające dla każdego, kto ma wrażliwe urządzenie.

Mimo że ta bardzo poważna luka o „krytycznym” poziomie ważności jest aktywnie wykorzystywana w środowisku naturalnym, wyłącznie przez Google dołączyli poprawkę rozwiązującą ten problem do biuletynu z marca 2020 r., czyli około 2 miesiące po powiadomieniu o problemie wydanie. Chociaż Google informuje swoich partnerów korzystających z systemu Android o najnowszym Biuletynie zabezpieczeń systemu Android na pełne 30 dni przed upublicznieniem biuletynu (tj. Producenci OEM zostali poinformowani o treści biuletynu z marca 2020 r. na początku lutego 2020 r.), Google może aktualizować biuletyn i często to robi, wprowadzając zmiany lub nowe poprawki. Nie rozumiem, dlaczego Google nie zdecydowało się przyspieszyć dołączenia łatki w przypadku tak poważnego problemu, zwłaszcza że MediaTek miał na to rozwiązanie 10 miesięcy temu. Gdyby taki błąd został wykryty w urządzeniach Apple, nie wątpię, że wypuściliby poprawkę dużo, dużo szybciej. Google zasadniczo oparł się na ryzykownym założeniu, że MediaTek-su pozostanie tak pozornie dyskretny, jak to miało miejsce aż do biuletynu z marca 2020 r. Chociaż wydaje się, że Google miał pod tym względem szczęście, nie mamy pojęcia, ilu autorów szkodliwego oprogramowania wie już o tym exploitie. W końcu siedział w przypadkowym wątku na forum XDA prawie cały rok.

Jest jeszcze jedna strona tej klęski, o której nie wspomniałem zbyt wiele, a jest nią autor exploita, członek dyplomacji XDA. Trzeba przyznać, że nie sądzę, że miał złe zamiary, publikując MediaTek-su. Możemy wyraźnie prześledzić pochodzenie exploita od chęci dyplomatycznej modyfikacji tabletów Amazon Fire. Dyplomatyk powiedział mi, że jego głównym celem w opracowaniu tej metody rootowania była pomoc społeczności. Dostosowywanie urządzenia jest tym, o co chodzi w XDA, a wysiłki dyplomatyczne w społeczności są tym, co ludzie lubią na forach. Chociaż odmowa dyplomatyczna udostępnienia projektu open source budzi pewne obawy, wyjaśnia, że ​​chciał, aby społeczność cieszyła się dostępem do konta root tak długo, jak to możliwe. Kiedy po raz pierwszy skontaktowałem się z dyplomacją, oświadczył również, że współpracuje z niektórymi partnerami, co uniemożliwiło mu udostępnienie kodu źródłowego projektu i badań. Chociaż nie udało mi się uzyskać więcej szczegółów na temat tej współpracy, zastanawiam się, czy firma dyplomatyczna zdecydowałaby się upublicznić ten exploit, gdyby MediaTek oferował program nagród za błędy. Nie mogę sobie wyobrazić, że luka tej wielkości nie przyniosłaby pokaźnych sum pieniędzy, gdyby MediaTek rzeczywiście miał taki program. Diplomatic twierdzi, że ten exploit jest możliwy od chipsetu MediaTek MT6580 z końca 2015 roku, więc należy się zastanawiać, czy Diplomatic jest w ogóle pierwszą osobą, która znalazła ten exploit. Mówi mi, że aż do publikacji tego artykułu nie miał pojęcia, że ​​MediaTek-su był aktywnie wykorzystywany.

Jeśli chcesz sprawdzić, czy Twoje urządzenie jest podatne na MediaTek-su, uruchom ręcznie skrypt przesłany przez członka dyplomatycznego XDA w tym wątku na forum XDA. Jeśli wejdziesz do powłoki roota (będziesz wiedział, kiedy symbol zmieni się z $ na #), będziesz wiedział, że exploit działa. Jeśli to zadziała, musisz poczekać, aż producent Twojego urządzenia wprowadzi aktualizację łatującą MediaTek-su. Jeśli Twoje urządzenie zgłasza poziom poprawki zabezpieczeń z dnia 2020-03-05, czyli najnowszą wersję SPL z marca 2020 r., oznacza to, że prawie na pewno jest chronione przed MediaTek-su. W przeciwnym razie będziesz musiał po prostu sprawdzić, czy Twoje urządzenie jest podatne.

---

Aktualizacja 1 (3.02.2020 o 21:45 EST): Ten artykuł został zaktualizowany, aby wyjaśnić, że dyplomata będący członkiem XDA był w rzeczywistości świadomy zakresu tej luki, gdy tylko odkrył go w lutym 2019 r., ale do czasu opublikowania tego artykułu nie był świadomy wykorzystania tego exploita w środowisku naturalnym artykuł. Poprawiliśmy także nasze sformułowanie dotyczące jednego z powodów, dla których placówka dyplomatyczna odmówiła udostępnienia kodu źródłowego projektu.