A kritikus MediaTek rootkit Android-eszközök millióit érinti

A Google minden hónap első hétfőjén közzéteszi a Android biztonsági közlemény, egy oldal, amely felfedi a Google vagy más harmadik felek által benyújtott összes biztonsági rést és azok javításait. A mai nap sem volt kivétel: a Google most hozta nyilvánosságra az Android 2020 márciusi biztonsági közleményét. A legutóbbi közleményben dokumentált egyik sebezhetőség a CVE-2020-0069, amely egy kritikus biztonsági kizsákmányolás, különösen rootkit, amely több millió készüléket érint a MediaTek, a nagy tajvani chiptervező cég chipkészleteivel. Bár a 2020. márciusi Android Biztonsági Értesítő látszólag az első alkalom, hogy a CVE-2020-0069-et nyilvánosságra hozzák, a kizsákmányolás részletei április óta nyíltan jelennek meg az interneten – pontosabban az XDA-Developers fórumain. 2019. Annak ellenére, hogy a MediaTek egy hónappal a felfedezés után elérhetővé tette a javítást, a sérülékenység továbbra is több tucat eszközmodellben kihasználható.

Még rosszabb, hogy a sebezhetőséget a hackerek aktívan kihasználják. A MediaTek most a Google-hoz fordult, hogy felszámolja ezt a javítási hiányt, és több millió eszközt óvjon meg ezzel a kritikus biztonsági kizsákmányolással szemben.

Minden olyan olvasónak, aki nem ismeri XDA-fejlesztők, mi egy olyan webhely, amely a legnagyobb Android-szoftver-módosítási fórumoknak ad otthont. Általában ezek a módosítások az eszközök root hozzáférésének megszerzésére irányulnak a bloatware törlése, az egyéni szoftverek telepítése vagy az alapértelmezett rendszerparaméterek módosítása érdekében. Az Amazon's Fire táblagépek népszerű célpontjai a hobbi hackerek fórumain – tele vannak eltávolítható anyagokkal bloatware, nem férnek hozzá olyan alapvető szoftveralkalmazásokhoz, mint a Google Play Áruház, és ami a legfontosabb, nagyon olcsó. Az Amazon Fire táblagépek gyökereztetésével kapcsolatos kihívás az, hogy erősen le vannak zárva, nehogy a felhasználók kilépjenek az Amazon fallal körülvett kertjéből; Az Amazon nem biztosít hivatalos módszert a Fire táblagépek rendszerbetöltőjének feloldására, ami általában az első lépés az adott Android-eszköz rootolásához. Ezért az Amazon Fire táblagép rootolásának egyetlen módja (hardvermódosítások nélkül), ha a szoftverben olyan exploitot találunk, amely lehetővé teszi a felhasználó számára, hogy megkerülje az Android biztonsági modelljét. 2019 februárjában ez az pontosan amit az XDA Senior Tag diplomatic tett amikor közzétett egy szálat az Amazon Fire táblagépes fórumain. Hamar rájött, hogy ez a kizsákmányolás sokkal szélesebb körű, mint az Amazon Fire táblagépei.

Az XDA-tag diplomáciai és más közösségi tagok által végzett kis tesztelés után bebizonyosodott, hogy ez az exploit számos MediaTek chipen működik. A szerző kijelenti, hogy a kizsákmányolás "a MediaTek gyakorlatilag az összes 64 bites chipjén" működik, és konkrétan a következőket nevezik sebezhetőnek: MT6735, MT6737, MT6738, A 173, MT8176, MT8183, MT6580 és MT6595. Mivel ez a kihasználás hány MediaTek lapkakészletet érintett, az exploit a "MediaTek-su" vagy röviden "MTK-su" nevet kapta. 2019. április 17-én a diplomáciai egy második szálat publikált ""Csodálatos Temp Root a MediaTek ARMv8 számára" az "Egyéb Android fejlesztés" fórumunkon. Ebben a szálban megosztott egy szkriptet, amelyet a felhasználók végrehajthatnak, hogy parancsértelmezőben szuperfelhasználói hozzáférést biztosítsanak nekik, valamint A SELinux, a Linux kernel modul, amely hozzáférés-szabályozást biztosít a folyamatokhoz, a nagyon nem biztonságos "megengedők" számára állapot. Megdöbbentően egyszerűen megteheti, hogy a felhasználó root hozzáférést kapjon, és megengedőre állítsa a SELinuxot saját eszközén: Csak másolnia kell a szkriptet egy ideiglenes mappába, módosítsa azokat a könyvtárakat, ahol a szkriptet tárolja, adjon hozzá végrehajtható engedélyeket a szkripthez, majd futtassa a forgatókönyv.

Az XDA közösség tagjai megerősítették, hogy a kizsákmányolás legalább a következő eszközökön működött:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Alba tabletta sorozat
4. Alcatel 1 5033 sorozat
5. Alcatel 1C
6. Alcatel 3L (2018) 5034 sorozat
7. Alcatel 3T 8
8. Alcatel A5 LED 5085 sorozat
9. Alcatel A30 5049 sorozat
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 – csak a Fire OS 6.3.1.2 build 0002517050244 verzióig
15. Amazon Fire HD 8 2016 – csak a Fire OS 5.3.6.4 build 626533320 verzióig
16. Amazon Fire HD 8 2017 – csak a Fire OS 5.6.4.0 build 636558520 verzióig
17. Amazon Fire HD 8 2018 – csak Fire OS 6.3.0.1-ig
18. Amazon Fire HD 10 2017 – csak a Fire OS 5.6.4.0 build 636558520 verzióig
19. Amazon Fire HD 10 2019 – csak Fire OS 7.3.1.0-ig
20. Amazon Fire TV 2 – csak Fire OS 5.2.6.9-ig
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. ASUS ZenPad Z3xxM(F) MT8163 alapú sorozat
24. Barnes & Noble NOOK Tablet 7" BNTV450 és BNTV460
25. Barnes & Noble NOOK Tablet 10,1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU élettartam max
29. BLU Life One X
30. BLU R1 sorozat
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 sorozat
48. Lava Iris 88S
49. Lenovo C2 sorozat
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. LG Tribute-dinasztia
55. LG X power 2/M320 sorozat (MTK)
56. LG Xpression Plus 2/K40 LMX420 sorozat
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 táblagép
69. Onn 8" és 10" táblagép sorozat (MT8163)
70. OPPO A5s
71. OPPO F5 series/A73 – csak Android 8.x
72. OPPO F7 sorozat – csak Android 8.x
73. OPPO F9 sorozat – csak Android 8.x
74. Oukitel K12
75. Protruly D7
76. Realme 1
77. Sony Xperia C4
78. Sony Xperia C5 sorozat
79. Sony Xperia L1
80. Sony Xperia L3
81. Sony Xperia XA sorozat
82. Sony Xperia XA1 sorozat
83. Southern Telecom Smartab ST1009X (MT8167)
84. TECNO Spark 3 sorozat
85. Umidigi F1 sorozat
86. Umidigi Power
87. Wiko Ride
88. Wiko Sunny
89. Wiko View3
90. Xiaomi Redmi 6/6A sorozat
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

Olvass tovább

A Vivo, a Huawei/Honor (Android 8.0+ után), az OPPO (Android 8.0+ után) és a MediaTek-alapú telefonok kivételével A Samsung és az XDA közösség tagjai úgy találták, hogy a MediaTek-su gyakrabban működik, mint nem, ha megpróbálják az érintett eszközökön lapkakészletek. Az XDA-tag diplomatikus jelentése szerint a Vivo, a Huawei/Honor, az OPPO és a Samsung készülékei "kernelmódosításokat használnak a root hozzáférés megakadályozására exploits", ami azt jelenti, hogy a fejlesztőnek bele kell mélyednie ezeknek az eszközöknek a kernel forráskódjába, hogy létrehozza a "testreszabott verziót" kihasználni. Ez nem érte meg a hozzáadott erőfeszítést, így a fejlesztő úgy döntött, hogy nem ad hozzá támogatást ezekhez az eszközökhöz, noha "elméletileg" a kihasználás még működhet.

Mostanra egyértelművé kell tenni, hogy ez a kizsákmányolás a piacon lévő számos eszközt érinti. A MediaTek chipek több száz olcsó és középkategóriás okostelefon-modellt, olcsó táblagépet és nem márkájú okostelefont táplálnak set-top boxok, amelyek többségét anélkül értékesítik, hogy elvárnák a gyártó időszerű frissítését. Sok, a MediaTek-su által még mindig érintett eszközön ezért nem valószínű, hogy a mai közzététel után hetekig vagy hónapokig kapnak javítást, ha egyáltalán kapnak ilyet. Tehát mitől éri el a MediaTek-su "kritikus" súlyosságát a CVSS v3.0 9,3 pont?

Miért jelent kritikus biztonsági rést az MTK-su?

Megismételve, az Android-eszközök root hozzáférésének tipikus módja a rendszerbetöltő feloldása, amely letiltja a rendszerindító partíció ellenőrzését. A rendszerbetöltő feloldása után a felhasználó bevezethet egy szuperfelhasználói binárist a rendszerbe, valamint egy szuperfelhasználó-kezelő alkalmazást, amellyel szabályozhatja, hogy mely folyamatok férhetnek hozzá a root-hoz. A rendszerbetöltő feloldása szándékosan letiltja az egyik kulcsfontosságú biztonsági funkciót az eszközön, ezért a felhasználónak kifejezetten lehetővé teszi, hogy ez megtörténjen úgy, hogy általában engedélyez egy kapcsolót a Fejlesztői beállításokban, majd ad ki egy feloldó parancsot a rendszerbetöltő. A MediaTek-su esetén azonban a felhasználónak nem kell feloldania a rendszerbetöltőt, hogy root hozzáférést kapjon. Ehelyett nem kell mást tenniük, mint átmásolni egy szkriptet az eszközükre, és shellben végrehajtani. Azonban nem a felhasználó az egyetlen, aki megteheti ezt. A telefonon lévő bármely alkalmazás átmásolhatja a MediaTek-su szkriptet a saját könyvtárába, majd végrehajthatja azt, hogy root hozzáférést kapjon a shellben. Valójában XDA-tag diplomáciai kiemeli ezt a lehetőséget fórumszálukban, amikor alternatív utasításkészletet javasolnak a Terminál emulátor Android alkalmazáshoz vagy Termux nem pedig ADB.

A root hozzáféréssel az Android biztonsági modellje alapvetően szétesik. Például az engedélyek értelmetlenné válnak a root kontextusában, mivel egy root rendszerhéjhoz hozzáféréssel rendelkező alkalmazás bármilyen engedélyt megadhat magának. Ezen túlmenően egy gyökérhéjjal az adatpartíció egésze – beleértve az alkalmazások jellemzően hozzáférhetetlen privát adatkönyvtáraiban tárolt fájlokat is – elérhető. A gyökérrel rendelkező alkalmazások csendben telepíthetnek bármilyen más alkalmazást a háttérben, majd megadhatnak nekik minden olyan engedélyt, amelyre szükségük van az Ön személyes adatainak megsértéséhez. Az XDA Recognized Developer szerint topjohnwu, egy rosszindulatú alkalmazás akár „közvetlenül a Zygote-ba szúrhat be kódot a ptrace segítségével”, ami azt jelenti, hogy az eszközön lévő normál alkalmazásokat eltéríthetik, hogy a támadó utasításait teljesítsék. Ezek a példák csak néhány olyan módot érintenek, amikor egy alkalmazás a háttérben az Ön tudta nélkül megsértheti a bizalmát. A rosszindulatú alkalmazások azonban pusztítást végezhetnek az eszközön anélkül, hogy elrejtik, amit csinálnak. A Ransomware például az rendkívül erős root hozzáféréssel; ha nem fizet, egy feltételezett ransomware alkalmazás megteheti teljesen és visszafordíthatatlanul tedd működésképtelenné az eszközt az egész eszköz tisztára törlésével.

A MediaTek-su egyetlen "gyengesége", hogy csak "ideiglenes" root hozzáférést biztosít egy alkalmazásnak, ami azt jelenti, hogy a folyamat elveszíti a szuperfelhasználói hozzáférést az eszköz újraindítása után. Továbbá az Android 6.0 Marshmallow és újabb rendszert futtató eszközökön a Ellenőrzött rendszerindítás és dm-verity blokkolja az írásvédett partíciók, például a rendszer és a szállító módosításait. Ez a két tényező azonban többnyire csak a fórumunkon megjelenő moddereket akadályozza, nem pedig a rosszindulatú szereplőket. Az ideiglenes gyökér korlátozásának leküzdése érdekében egy rosszindulatú alkalmazás egyszerűen újra futtathatja a MediaTek-su szkriptet minden rendszerindításkor. Másrészt nincs szükség a dm-verity leküzdésére, mivel a rendszer vagy a szállítói partíciók állandó módosításai valószínűleg nem érdeklik a legtöbb rosszindulatú szoftvert; elvégre már vannak tonna olyan dolgokról, amelyeket egy rosszindulatú alkalmazás tehet a gyökérhéjjal.

Ha technikai szinten kíváncsi arra, hogy mit aknáz ki a MediaTek-su, a MediaTek megosztotta velünk az alábbi táblázatot, amely összefoglalja a belépési pontot. A hiba nyilvánvalóan a MediaTek egyik "CMDQ" nevű Linux Kernel illesztőprogramjában található. A leírás szerint "az IOCTL végrehajtásával parancsokat [a] CMDQ eszközcsomópontban", a helyi támadó „tetszőlegesen olvashatja/írhatja a fizikai memóriát, kiírhatja [a] kernel szimbólumtáblázatot a előre lefoglalt DMA puffer, [és] a DMA puffer manipulálásával módosítsa a kernel beállításait a SELinux letiltásához és a „root” szintre emeléséhez kiváltság."

A MediaTek által velünk megosztott diagram szerint ez a biztonsági rés a 3.18-as, 4.4-es, 4.9-es vagy 4.14-es Linux Kernel-verziójú MediaTek-eszközöket érinti, amelyek Android 7-es Nougat, 8 Oreo vagy 9 Pie-verziót futtatnak. A sérülékenység nem használható ki az Android 10 rendszert futtató MediaTek eszközökön, mivel „a CMDQ hozzáférési engedélye az eszközcsomópontokat a SELinux is kényszeríti." Ez a mérséklés valószínűleg a MediaTek BSP frissítéséből származik, nem pedig az Androidból maga. Az Android 10 egyetlen mérséklése ennek a sebezhetőségnek az az oka korlátozás a saját könyvtárukban lévő bináris fájlokat futtató alkalmazásokra; azonban, ahogy az XDA Recognized Developer topjohnwu megjegyzi, egy rosszindulatú alkalmazás egyszerűen futtathatja a MediaTek-su kódot egy dinamikus könyvtárban.

Annak ellenére, hogy a MediaTek az összes érintett lapkakészleten javította ezt a problémát, nem kényszeríthetik az eszközgyártókat a javítások megvalósítására. A MediaTek elmondta, hogy 2019 májusában már készen voltak a javítások. Az Amazon nem meglepő módon azonnal javította a problémát az eszközein, miután tudomást szereztek róla. Azonban 10 hónap telt el azóta, hogy a MediaTek elérhetővé tett egy javítást partnerei számára, de még be 2020 márciusában több tucat OEM-gyártó nem javította meg eszközét. A legtöbb érintett eszköz régebbi Android-kiadásokon található, elavult Android biztonsági javítási szintekkel (SPL), és a frissítési helyzet még rosszabb, ha figyelembe vesszük a több száz kevésbé ismert eszközmodellek, amelyek ezeket a MediaTek chipeket használják. A MediaTek rendelkezik a komoly itt a kezében van a probléma, ezért a Google-hoz fordultak segítségért.

A MediaTekkel ellentétben a Google tud arra kényszeríti az OEM-eket, hogy frissítsék eszközeiket licencszerződések vagy a program feltételeit (például Android One). Ahhoz, hogy az OEM kijelenthesse, hogy az eszköz megfelel a 2020-03-05 biztonsági javítási szintnek (SPL), az eszköznek tartalmaznia kell az összes keretrendszert, A Linux kernel és a megfelelő szállítói illesztőprogram-javítások a 2020. márciusi Android Biztonsági Közleményben, amely tartalmazza a CVE-2020-0069 javítást, vagy MediaTek-su. (Úgy tűnik, hogy a Google ezt valójában nem kényszeríti ki Az OEM-ek tulajdonképpen az összes javítást egyesítik egy bizonyos SPL deklarálásakor azonban.) Most, hogy megjelent a 2020. márciusi közlemény, ennek a történetnek véget kell érnie, nem? Sajnos a Google lábát is tűzhöz kell tartanunk, amiért húzzák a javításokat.

A biztonsági javítási folyamat hibája

Abban az esetben, ha még nem világos, nem kell minden biztonsági résnek az Android Biztonsági közleményében megjelennie. A gyártók számos sebezhetőséget fedeznek fel és javítanak ki anélkül, hogy azok valaha is megjelennének a havi értesítőben. A MediaTek-sunak kellett volna ezek közé tartoznia, de több ok miatt több OEM-nek nem sikerült integrálnia a MediaTek által kínált javításokat. (Sok lehetséges oka van ennek, az erőforrások hiányától az üzleti döntéseken át a kommunikációs kudarcig.) Amikor korábban kijelentette, hogy a MediaTek "a Google-hoz fordult" segítségért, ami arra utalt, hogy a MediaTek aktívan kért segítséget a Google-tól, hogy az OEM-eket végre megjavítsák. eszközöket. Lehetséges azonban, hogy valójában nem ez volt a helyzet. Megértésem szerint a Google nem tudott a MediaTek-su-ról egészen addig, amíg véletlenül fel nem hozták egy biztonsági jelentésben TrendMicro közzétéve: 2020. január 6. A jelentésben TrendMicro dokumentálta egy másik biztonsági rés, a "utólagos használat a kötőanyag-meghajtóban"sebezhetőség, amelyet a vadonban aktívan kihasználtak. TrendMicro megjegyezte, hogyan jutott három rosszindulatú alkalmazás gyökér hozzáféréshez a két módszer egyikével, vagy a "használat után szabaddá"-val a binder illesztőprogramban, vagy a MediaTek-su segítségével.

Abban a kódban, hogy TrendMicro megosztott, jól láthatjuk, hogy a rosszindulatú alkalmazások hogyan céloztak meg bizonyos eszközmodelleket (pl. Nokia 3, OPPO F9 és Redmi 6A) és MediaTek-su alkalmazása rajtuk.

Nem tudok helyette beszélni TrendMicro, de úgy tűnik, nem tudták, hogy a MediaTek-su egy még nem javított kizsákmányolás. Végül is a „használat utáni mentes a kötőanyag-illesztőprogramban” exploitjára összpontosítottak, és úgy tűnik, hogy a MediaTek-su használatának felfedezése csak utólagos gondolat volt. (Biztos vagyok benne, hogy ha TrendMicro tisztában voltak a MediaTek-su körül kialakult helyzettel, egyeztették volna közzétételi erőfeszítéseiket a Google-lal.) Csak arról értesültünk, hogy ezt a kizsákmányolást 2020. február 5-én, és miután magunk is megvizsgáltuk, mennyire rossz, február 7-én megkerestük a Google-t. 2020. A Google annyira aggódott a MediaTek-su nyilvánosságra hozatalának következményei miatt, hogy arra kértek bennünket, tartsuk el a történet közzétételét a mai napig. Miután figyelembe vettük a rosszindulatú programok által megcélzott felhasználókat okozó jóvátehetetlen károkat MediaTek-su, megállapodtunk, hogy felfüggesztjük ezt a történetet az Android 2020 márciusi bejelentéséig Biztonsági közlemény. Ennek ellenére, ha figyelembe vesszük, mennyi időbe telik sok eszköznek a legújabb biztonsági frissítés beszerzése, ha valaha is Egyáltalán, biztosan rengeteg eszköz lesz még mindig sebezhető a MediaTek-suval szemben néhány hónap múlva Most. Ez rettenetes lehet mindenki számára, aki sebezhető eszközzel rendelkezik.

Annak ellenére, hogy ezt a nagyon súlyos, „kritikus” súlyos sebezhetőséget aktívan kihasználják a vadonban, csak a Google A probléma javítását behelyezték a 2020. márciusi értesítőbe, ami körülbelül 2 hónappal azután történt, hogy tudomást szereztek a probléma. Bár a Google 30 nappal a közlemény nyilvánosságra hozatala előtt tájékoztatja Android-partnereit a legújabb Android Biztonsági Közleményről (pl. Az OEM-eket 2020. február elején értesítették a 2020. márciusi közleményben foglaltakról.) A Google módosíthatja és gyakran frissíti is a közleményt változtatásokkal vagy új javításokkal. Hogy a Google miért nem úgy döntött, hogy felgyorsítja a javítás beépítését egy ilyen súlyos probléma esetén, az nem érthető, különösen, amikor a MediaTek 10 hónappal ezelőtt javította a problémát. Ha ilyen hibát fedeznének fel az Apple készülékeiben, nincs kétségem afelől, hogy kiadtak volna egy javítást sokkal, de sokkal gyorsabban. A Google lényegében azzal a kockázatos fogadással számolt, hogy a MediaTek-su a 2020. márciusi közleményig látszólag alacsony profilú marad, mint amilyen volt. Bár úgy tűnik, hogy a Google-nek szerencséje van ebben a tekintetben, fogalmunk sincs, hány rosszindulatú program szerzője tud már a kizsákmányolásról. Végül is egy véletlenszerű XDA fórum témában ül majdnem egy egész év.

Van még egy fél ebben a kudarcban, akivel nem sokat foglalkoztam, és ez az exploit szerzője, az XDA-tag diplomata. Becsületére legyen mondva, nem hiszem, hogy rosszindulatú szándéka volna a MediaTek-su kiadásában. A kihasználás eredete egyértelműen az Amazon Fire táblagépek módosítására irányuló diplomáciai vágyra vezethető vissza. Diplomatikus azt mondja, hogy e gyökérmódszer kidolgozásával az elsődleges célja a közösség segítése volt. Az XDA lényege az eszköz testreszabása, a közösségben végzett diplomáciai erőfeszítések pedig az, amit az emberek élveznek a fórumokon. Bár a projekt nyílt forráskódú diplomáciai elutasítása némi aggodalomra ad okot, kifejti, hogy azt akarta, hogy a közösség minél tovább élvezze ezt a root hozzáférést. Amikor először felvettem a kapcsolatot a diplomáciával, azt is kijelentette, hogy együttműködésben áll néhány partnerrel, ami miatt nem tudta megosztani a projekt forráskódját és kutatásait. Bár nem tudtam több részletet szerezni erről az együttműködésről, azon tűnődöm, vajon a diplomatikusok úgy döntöttek volna, hogy nyilvánosságra hozzák ezt a kizsákmányolást, ha a MediaTek bug bounty programot kínál. Nem tudom elképzelni, hogy egy ekkora sérülékenység ne fizetne ki tetemes összeget, ha a MediaTeknek valóban lenne ilyen programja. A diplomáciai állítások szerint ez a kizsákmányolás a 2015 végi MediaTek MT6580 lapkakészlet óta lehetséges, ezért el kell töprengeni, vajon a diplomatikus volt-e az első, aki megtalálta ezt a kizsákmányolást. Elmondja, hogy a cikk megjelenéséig fogalma sem volt arról, hogy a MediaTek-sut aktívan kihasználják.

Ha ellenőrizni szeretné, hogy eszköze sebezhető-e a MediaTek-su-val szemben, akkor manuálisan futtassa az XDA Member diplomatic által közzétett szkriptet ebben az XDA fórum témában. Ha beír egy gyökérhéjat (tudni fogja, ha a szimbólum $-ról #-re változik), akkor tudni fogja, hogy az exploit működik. Ha működik, akkor meg kell várnia, amíg az eszköz gyártója kiad egy frissítést, amely javítja a MediaTek-su-t. Ha eszköze a 2020-03-05 biztonsági javítási szintet jelzi, amely a legújabb, 2020. márciusi SPL, akkor szinte biztosan védett a MediaTek-su ellen. Ellenkező esetben csak ellenőriznie kell, hogy eszköze sebezhető-e.

---

1. frissítés (2020.03.02., 21:45 EST): Ezt a cikket frissítettük annak tisztázása érdekében, hogy az XDA-tag diplomatikus valóban tudatában volt ennek a sebezhetőségnek, amint még 2019 februárjában fedezte fel, de ennek közzétételéig nem tudott a kizsákmányolás vadonbeli használatáról. cikk. Kijavítottuk megfogalmazásunkat egy olyan ok miatt is, ami miatt a diplomáciai megtagadták a projekt forráskódjának megosztását.