Esminis „MediaTek“ procesorių trūkumas įrenginiuose buvo pašalintas dėl OĮG nepriežiūros. „Google“ tikisi, kad 2020 m. kovo mėn. „Android“ saugos biuletenis tai išspręs.
Pirmąjį kiekvieno mėnesio pirmadienį „Google“ skelbia Android saugos biuletenis, puslapis, kuriame atskleidžiamos visos saugos spragos ir jų pataisos, kurias pateikė pati „Google“ ar kitos trečiosios šalys. Šiandien nebuvo išimtis: „Google“ ką tik paskelbė 2020 m. kovo mėnesio „Android“ saugos biuletenį. Vienas iš pažeidžiamumų, aprašytų naujausiame biuletenyje, yra CVE-2020-0069, svarbus saugumo išnaudojimas, ypač rootkit, kuris paveikia milijonus įrenginių su mikroschemų rinkiniais iš MediaTek, didelės Taivano mikroschemų projektavimo įmonės. Nors 2020 m. kovo mėn. „Android“ saugos biuletenis atrodo pirmą kartą viešai paskelbtas CVE-2020-0069, Išnaudojimo detalės iš tikrųjų buvo atvirai internete, tiksliau, XDA-Developers forumuose, nuo balandžio mėn. 2019 m. Nepaisant to, kad „MediaTek“ paskelbė pataisą praėjus mėnesiui po atradimo, pažeidžiamumas vis dar gali būti išnaudojamas dešimtyse įrenginių modelių.
Dar blogiau, kad pažeidžiamumu aktyviai naudojasi įsilaužėliai. Dabar „MediaTek“ kreipėsi į „Google“, kad pašalintų šią pataisos spragą ir apsaugotų milijonus įrenginių nuo šio kritinio saugumo išnaudojimo.Visiems skaitytojams, kurie nėra susipažinę su XDA kūrėjai, esame svetainė, kurioje yra didžiausi Android programinės įrangos modifikacijų forumai. Paprastai šios modifikacijos yra skirtos pasiekti įrenginių šakninę prieigą, kad būtų pašalinta „bloatware“, įdiegta pasirinktinė programinė įranga arba pakoreguojami numatytieji sistemos parametrai. „Amazon's Fire“ planšetiniai kompiuteriai yra populiarūs įsilaužėlių mėgėjų taikiniai mūsų forumuose – juose gausu pašalinamų elementų. bloatware, trūksta prieigos prie pagrindinių programinės įrangos programų, tokių kaip „Google Play“ parduotuvė, ir, svarbiausia, yra labai pigu. Iššūkis, susijęs su įsišaknijusiais „Amazon Fire“ planšetiniais kompiuteriais, yra tas, kad jie yra labai užrakinti, kad vartotojai negalėtų išeiti už „Amazon“ aptverto sodo; „Amazon“ nepateikia oficialaus metodo, kaip atrakinti „Fire“ planšetinių kompiuterių įkrovos įkroviklį, o tai paprastai yra pirmasis bet kurio „Android“ įrenginio įsišaknijimo žingsnis. Todėl vienintelis būdas išjungti „Amazon Fire“ planšetinį kompiuterį (be aparatinės įrangos modifikacijų) yra programinėje įrangoje rasti išnaudojimą, leidžiantį vartotojui apeiti „Android“ saugos modelį. 2019 m. vasario mėn tiksliai tai, ką padarė XDA vyresnysis narys diplomatinis kai jis paskelbė giją mūsų Amazon Fire planšetinių kompiuterių forumuose. Jis greitai suprato, kad šis išnaudojimas buvo daug platesnis nei tik „Amazon“ „Fire“ tabletės.
Po šiek tiek testavimo iš XDA narių diplomatinių ir kitų bendruomenės narių buvo patvirtinta, kad šis išnaudojimas veikia daugelyje MediaTek lustų. Autorius teigia, kad išnaudojimas veikia „beveik visuose MediaTek 64 bitų lustuose“, ir jie konkrečiai įvardija kaip pažeidžiamus: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6779, MT6795, MT6779, MT6795, MT6779, MT6795, MT6796, MT6796, MT6796, 8 173, MT8176, MT8183, MT6580 ir MT6595. Dėl to, kiek MediaTek mikroschemų rinkinių paveikė šis išnaudojimas, išnaudojimui buvo suteiktas pavadinimas „MediaTek-su“ arba trumpiau „MTK-su“. 2019 m. balandžio 17 d. diplomatinė paskelbė antrą giją pavadinimu "Nuostabi „MediaTek ARMv8“ laikina šaknis“ mūsų forume „Įvairus Android kūrimas“. Šioje temoje jis pasidalino scenarijumi, kurį vartotojai gali vykdyti, kad suteiktų jiems supervartotojo prieigą prie apvalkalo, taip pat SELinux, „Linux“ branduolio modulis, suteikiantis prieigos kontrolę procesams, labai nesaugiems „leidžiantiems“ valstybė. Kad vartotojas galėtų gauti root prieigą ir nustatyti SELinux į leistiną savo įrenginyje, yra šokiruojančiai lengva: tereikia nukopijuoti scenarijų į laikinąjį aplanką, pakeiskite katalogus, kuriuose yra saugomas scenarijus, pridėkite scenarijui vykdomuosius leidimus ir paleiskite scenarijus.
XDA bendruomenės nariai patvirtino, kad išnaudojimas veikė bent šiuose įrenginiuose:
- Acer Iconia One 10 B3-A30
- Acer Iconia One 10 B3-A40
- Alba tablečių serija
- Alcatel 1 5033 serija
- Alcatel 1C
- Alcatel 3L (2018) 5034 serija
- Alcatel 3T 8
- Alcatel A5 LED 5085 serija
- Alcatel A30 5049 serija
- Alcatel Idol 5
- „Alcatel“ / TCL A1 A501DL
- Alcatel / TCL LX A502DL
- Alcatel Tetra 5041C
- Amazon Fire 7 2019 – tik iki Fire OS 6.3.1.2 build 0002517050244
- „Amazon Fire HD 8 2016“ – tik iki „Fire OS 5.3.6.4 build 626533320“
- „Amazon Fire HD 8 2017“ – tik iki „Fire OS 5.6.4.0 build 636558520“
- „Amazon Fire HD 8 2018“ – tik iki „Fire OS 6.3.0.1“.
- „Amazon Fire HD 10 2017“ – tik iki „Fire OS 5.6.4.0 build 636558520“
- „Amazon Fire HD 10 2019“ – tik iki „Fire OS 7.3.1.0“.
- „Amazon Fire TV 2“ – tik iki „Fire OS 5.2.6.9“.
- ASUS ZenFone Max Plus X018D
- ASUS ZenPad 3s 10 Z500M
- ASUS ZenPad Z3xxM(F) MT8163 pagrįsta serija
- Barnes & Noble NOOK 7 colių planšetinis kompiuteris BNTV450 ir BNTV460
- Barnes & Noble NOOK 10,1" BNTV650 planšetinis kompiuteris
- Blackview A8 Max
- „Blackview BV9600 Pro“ („Helio P60“)
- BLU Life Max
- BLU Life One X
- BLU R1 serija
- BLU R2 LTE
- BLU S1
- BLU Tank Xtreme Pro
- BLU Vivo 8L
- BLU Vivo XI
- BLU Vivo XL4
- Bluboo S8
- BQ Aquaris M8
- CAT S41
- Coolpad Cool Play 8 Lite
- Dragon Touch K10
- Aido jausmas
- Gionee M7
- HiSense Infinity H12 Lite
- Huawei GR3 TAG-L21
- Huawei Y5II
- Huawei Y6II MT6735 serija
- Lava Iris 88S
- Lenovo C2 serija
- Lenovo Tab E8
- Lenovo Tab2 A10-70F
- LG K8+ (2018) X210ULMA (MTK)
- LG K10 (2017 m.)
- LG Tribute dinastija
- LG X power 2 / M320 series (MTK)
- LG Xpression Plus 2/K40 LMX420 serija
- Lumigon T3
- Meizu M5c
- Meizu M6
- „Meizu Pro 7 Plus“.
- Nokia 1
- Nokia 1 Plus
- Nokia 3
- Nokia 3.1
- Nokia 3.1 Plus
- Nokia 5.1
- Nokia 5.1 Plus/X5
- Onn 7 colių Android planšetinis kompiuteris
- Onn 8" ir 10" planšetinių kompiuterių serija (MT8163)
- OPPO A5s
- OPPO F5 series/A73 – tik „Android 8.x“.
- OPPO F7 serija – tik „Android 8.x“.
- OPPO F9 serija – tik „Android 8.x“.
- Oukitel K12
- Protruly D7
- Realme 1
- Sony Xperia C4
- Sony Xperia C5 serija
- Sony Xperia L1
- Sony Xperia L3
- Sony Xperia XA serija
- Sony Xperia XA1 serija
- Southern Telecom Smartab ST1009X (MT8167)
- TECNO Spark 3 serija
- Umidigi F1 serija
- Umidigi galia
- „Wiko Ride“.
- Wiko Sunny
- Wiko vaizdas3
- Xiaomi Redmi 6/6A serija
- ZTE Blade A530
- ZTE Blade D6/V6
- ZTE Quest 5 Z3351S
Skaityti daugiau
Išskyrus „Vivo“, „Huawei“ / „Honor“ (po „Android 8.0“ ir naujesnės versijos), OPPO (po „Android 8.0“ ir naujesnės versijos) „MediaTek“ pagrindu veikiančius telefonus. „Samsung“, XDA bendruomenės nariai nustatė, kad „MediaTek-su“ veikia dažniau nei ne, kai bandoma naudoti įrenginiuose su paveiktais mikroschemų rinkiniai. Pasak XDA narių diplomatinių atstovų, „Vivo“, „Huawei/Honor“, OPPO ir „Samsung“ įrenginiai „naudoja branduolio modifikacijas, kad atgrasytų root prieigą per exploits“, o tai reiškia, kad kūrėjas turės įsigilinti į šių įrenginių branduolio šaltinio kodą, kad sukurtų „pritaikytas versijas“ išnaudoti. Tai nebuvo verta papildomų pastangų, todėl kūrėjas nusprendė nepridėti šių įrenginių palaikymo, nors „teoriškai“ išnaudojimas vis tiek gali veikti.
Iki šiol turėtų būti aišku, kad šis išnaudojimas turi įtakos daugeliui rinkoje esančių įrenginių. „MediaTek“ lustai maitina šimtus nebrangių ir vidutinės klasės išmaniųjų telefonų modelių, pigių planšetinių kompiuterių ir ne prekės ženklo priedėlių, kurių dauguma parduodami nesitikint, kad gamintojas laiku pateiks atnaujinimų. Todėl mažai tikėtina, kad daugelis įrenginių, kuriuos vis dar veikia „MediaTek-s“, bus pataisyti praėjus savaitėms ar mėnesiams po šiandienos atskleidimo, jei jie išvis tai padarys. Taigi, dėl ko „MediaTek-su“ užsitarnauja „kritinį“ sunkumą su a CVSS v3.0 balas 9,3?
Kodėl MTK-su yra kritinė saugumo spraga
Pakartotinai, įprastas būdas pasiekti root prieigą „Android“ įrenginyje yra pirmiausia atrakinti įkrovos įkroviklį, kuris išjungia įkrovos skaidinio patvirtinimą. Kai įkrovos įkroviklis yra atrakintas, vartotojas gali įvesti sistemą supervartotojo dvejetainį failą ir supervartotojo valdymo programą, kad būtų galima valdyti, kurie procesai turi prieigą prie root. Atrakinant įkrovos įkroviklį sąmoningai išjungiama viena iš pagrindinių įrenginio saugos funkcijų, todėl vartotojas turi aiškiai leisti tai įvykti, paprastai kūrėjo parinktyse įjungiant perjungimą ir tada išduodant atrakinimo komandą įkrovos įkroviklis. Tačiau naudojant „MediaTek-su“, vartotojui nereikia atrakinti įkrovos, kad gautų root prieigą. Vietoj to, jiems tereikia nukopijuoti scenarijų į savo įrenginį ir vykdyti jį apvalkale. Tačiau vartotojas nėra vienintelis, galintis tai padaryti. Bet kuri jūsų telefono programa gali nukopijuoti MediaTek-su scenarijų į savo privatų katalogą ir paleisti jį, kad gautų pagrindinę prieigą prie apvalkalo. Tiesą sakant, XDA narys diplomatinis pabrėžia šią galimybę savo forumo gijoje, kai jie siūlo alternatyvų instrukcijų rinkinį naudodami bet kurį Terminalo emuliatorius, skirtas Android programai arba Termux o ne ADB.
Su root prieiga „Android“ saugos modelis iš esmės žlunga. Pavyzdžiui, leidimai netenka prasmės root kontekste, nes programa, turinti prieigą prie šakninio apvalkalo, gali suteikti sau bet kokį norimą leidimą. Be to, naudojant šakninį apvalkalą, pasiekiamas visas duomenų skaidinys, įskaitant failus, saugomus paprastai nepasiekiamuose programų privačiuose duomenų kataloguose. Programėlė su root programa taip pat gali tyliai įdiegti bet kurią kitą norimą programą fone ir suteikti jai bet kokius leidimus, kurių reikia norint pažeisti jūsų privatumą. Pasak XDA pripažinto kūrėjo topjohnwu, kenkėjiška programa netgi gali „įšvirkšti kodą tiesiai į Zygote, naudodama ptrace“, o tai reiškia, kad įprasta jūsų įrenginio programa gali būti užgrobta, kad būtų įvykdytas užpuolikas. Šie pavyzdžiai paliečia tik keletą būdų, kaip programa gali pažeisti jūsų pasitikėjimą fone be jūsų žinios. Tačiau kenkėjiškos programos gali sugriauti jūsų įrenginį, neslepdamos, ką daro. Pavyzdžiui, „ransomware“ yra nepaprastai galingas su root prieiga; jei nemokėsite, hipotetinė išpirkos reikalaujanti programa galėtų visiškai ir negrįžtamai padarykite įrenginį neveikiantį, nuvalydami visą įrenginį.
Vienintelis „MediaTek-su“ „silpnumas“ yra tai, kad programai suteikiama tik „laikina“ šakninė prieiga, o tai reiškia, kad procesas praranda supervartotojo prieigą po įrenginio perkrovimo. Be to, įrenginiuose, kuriuose veikia „Android 6.0 Marshmallow“ ir naujesnė versija, yra Patvirtinta įkrova ir dm-verity blokuoti tik skaitymo skaidinių, pvz., sistemos ir tiekėjo, modifikacijas. Tačiau šie du veiksniai dažniausiai yra tik kliūtys mūsų forumų modifikatoriams, o ne piktybiniams veikėjams. Norėdami įveikti laikinosios šaknies apribojimą, kenkėjiška programa gali tiesiog iš naujo paleisti MediaTek-su scenarijų kiekvieną įkrovą. Kita vertus, nereikia įveikti dm-verity, nes nuolatiniai sistemos arba tiekėjo skaidinių pakeitimai greičiausiai nesudomins daugumos kenkėjiškų programų autorių; juk jau yra tonų dalykų, kuriuos kenkėjiška programa gali padaryti su šakniniu apvalkalu.
Jei jums techniniu lygmeniu įdomu, ką naudoja „MediaTek-su“, „MediaTek“ pasidalijo su mumis žemiau esančia diagrama, kurioje apibendrinamas įėjimo taškas. Trūkumas, matyt, egzistuoja vienoje iš „MediaTek“ Linux branduolio tvarkyklių, vadinamų „CMDQ“. Apraše teigiama, kad „vykdant IOCTL komandos CMDQ įrenginio mazge“, vietinis užpuolikas gali „savavališkai skaityti / įrašyti fizinę atmintį, iškelti branduolio simbolių lentelę į iš anksto paskirtas DMA buferis, [ir] manipuliuoti DMA buferiu, kad pakeistumėte branduolio nustatymus, kad išjungtumėte SELinux ir perkeltumėte į „root“ privilegija."
Remiantis diagrama, kurią „MediaTek“ bendrino su mumis, šis pažeidžiamumas paveikia „MediaTek“ įrenginius su „Linux Kernel“ 3.18, 4.4, 4.9 arba 4.14 versijomis, kuriose veikia „Android“ 7 Nougat, 8 Oreo arba 9 Pie. Pažeidžiamumo negalima išnaudoti „MediaTek“ įrenginiuose, kuriuose veikia „Android 10“, matyt, nes „CMDQ prieigos leidimas įrenginio mazgus taip pat užtikrina SELinux. pats. Vienintelis „Android 10“ pažeidžiamumo mažinimas yra jo apribojimas programoms, vykdančioms dvejetainius failus savo namų kataloge; tačiau, kaip pažymi XDA Recognized Developer topjohnwu, kenkėjiška programa gali tiesiog paleisti MediaTek-su kodą dinaminėje bibliotekoje.
Nors „MediaTek“ ištaisė šią problemą visuose paveiktuose mikroschemų rinkiniuose, jie negali priversti įrenginių gamintojų įdiegti pataisų. „MediaTek“ mums pasakė, kad 2019 m. gegužės mėn. buvo paruošti pataisymai. Nenuostabu, kad „Amazon“ iš karto ištaisė problemą visuose savo įrenginiuose, kai apie juos sužinojo. Tačiau praėjo 10 mėnesių nuo tada, kai „MediaTek“ padarė pataisymą prieinamą savo partneriams 2020 m. kovo mėn. dešimtys originalios įrangos gamintojų nepataisė savo įrenginių. Dauguma paveiktų įrenginių yra senesniuose „Android“ leidimuose su pasenusiais „Android“ saugos pataisų lygiais (SPL), o naujinimo padėtis dar blogesnė, kai atsižvelgiama į šimtai mažiau žinomų įrenginių modelių, naudojančių šiuos „MediaTek“ lustus. „MediaTek“ turi a rimtas problemą, todėl jie kreipėsi pagalbos į „Google“.
Skirtingai nuo MediaTek, Google gali priversti OEM atnaujinti savo įrenginius per licencijos sutartys arba programos sąlygos (pvz., „Android One“). Kad OĮG galėtų paskelbti, kad įrenginys atitinka 2020-03-05 saugos pataisos lygį (SPL), įrenginyje turi būti visa sistema, „Linux“ branduolys ir taikomi pardavėjo tvarkyklės pataisymai 2020 m. kovo mėn. „Android“ saugos biuletenyje, kuriame yra CVE-2020-0069 pataisa arba MediaTek-su. (Atrodo, kad „Google“ to nevykdo Originalios įrangos gamintojai iš tikrųjų sujungia visas pataisas vis dėlto deklaruojant tam tikrą SPL.) Dabar, kai yra išleistas 2020 m. kovo mėn. biuletenis, ši istorija turėtų būti baigta, tiesa? Deja, mes taip pat turime laikyti „Google“ kojas prie ugnies už tai, kad jie vilkina juos įtraukdami pleistrus.
Saugos pataisos proceso trūkumas
Jei tai dar neaišku, ne kiekvienas saugos pažeidžiamumas turi patekti į „Android“ saugos biuletenį. Pardavėjai aptinka ir pataiso daugybę pažeidžiamumų, tačiau jie niekada neparodomi mėnesiniame biuletenyje. „MediaTek-su“ turėjo būti vienas iš jų, tačiau dėl kelių priežasčių keliems originalios įrangos gamintojams nepavyko integruoti „MediaTek“ siūlomų pataisų. (Yra daug galimų priežasčių, nuo išteklių trūkumo iki verslo sprendimų iki komunikacijos nesėkmės.) Kai aš anksčiau teigė, kad „MediaTek“ „kreipėsi į „Google“ pagalbos, tai reiškė, kad „MediaTek“ aktyviai ieškojo „Google“ pagalbos, siekdama, kad originalios įrangos gamintojai pagaliau ištaisytų savo prietaisai. Tačiau iš tikrųjų taip galėjo nebūti. Mano supratimu, „Google“ nežinojo apie „MediaTek-su“, kol ji atsitiktinai nebuvo įtraukta saugos ataskaitoje iš TrendMicro paskelbta 2020 m. sausio 6 d. Pranešime TrendMicro dokumentavo kitas saugumo pažeidžiamumas, vadinamas "naudoti po-free segtuvų tvarkyklėje" pažeidžiamumas, kuris buvo aktyviai išnaudojamas laukinėje gamtoje. TrendMicro pažymėjo, kaip trys kenkėjiškos programos gavo pagrindinę prieigą, naudodamos vieną iš dviejų metodų – pažeidžiamumą „naudoti po nemokamų segtuvų tvarkyklėje“ arba „MediaTek-su“.
Kode, kad TrendMicro bendrinami, aiškiai matome, kaip kenkėjiškos programos buvo nukreiptos į konkrečius įrenginių modelius (pvz., Nokia 3, OPPO F9 ir Redmi 6A) ir juose naudoti MediaTek-su.
Aš negaliu kalbėti už TrendMicro, bet atrodo, kad jie nežinojo, kad „MediaTek-su“ buvo dar nepataisytas išnaudojimas. Galų gale, jų dėmesys buvo sutelktas į „naudojimo po nenaudojimo segtuvų tvarkyklėje“ išnaudojimą, o „MediaTek-su“ naudojimo atradimas, atrodo, buvo vėlyvas. (Esu tikras, kad jei TrendMicro žinojo apie situaciją, susijusią su „MediaTek-su“, jie būtų suderinę savo pastangas atskleisti informaciją su „Google“.) Mums buvo pranešta tik apie 2020 m. vasario 5 d. mes patys ištyrėme, kaip tai blogai, vasario 7 d. susisiekėme su „Google“, 2020. „Google“ buvo taip susirūpinęs dėl „MediaTek-su“ viešinimo pasekmių, kad paprašė mūsų atidėti šios istorijos paskelbimą iki šios dienos. Apsvarsčius nepataisomą žalą, kuri gali būti padaryta vartotojams, kuriems taikoma kenkėjiška programa „MediaTek-su“, sutarėme sustabdyti šią istoriją iki 2020 m. kovo mėnesio „Android“ paskelbimo Saugumo biuletenis. Vis dėlto, atsižvelgiant į tai, kiek laiko užtruks daugelis įrenginių, kol gaus naujausią saugos naujinį, jei kada nors bus jei išvis tai supras, tikriausiai bus daugybė įrenginių, kurie vis dar bus pažeidžiami MediaTek-su po kelių mėnesių nuo dabar. Tai turėtų kelti siaubą visiems, turintiems pažeidžiamą įrenginį.
Nors šis labai rimtas, „kritinis“ pažeidžiamumas yra aktyviai išnaudojamas laukinėje gamtoje, tik „Google“ šios problemos pataisymas įtrauktas į 2020 m. kovo mėn. biuletenį, kuris yra maždaug po 2 mėnesių nuo tada, kai jie sužinojo apie sutrikimas. Nors „Google“ praneša savo „Android“ partneriams apie naujausią „Android“ saugos biuletenį likus 30 dienų iki biuletenio paskelbimo (ty. OĮG buvo informuoti apie tai, kas yra 2020 m. kovo mėn. biuletenyje 2020 m. vasario pradžioje), „Google“ gali ir dažnai atnaujina biuletenį su pakeitimais arba naujais pataisymais. Kodėl „Google“ nepasirinko paspartinti pataisos įtraukimo tokiai rimtai problemai, aš nesuprantu, ypač kai „MediaTek“ ją ištaisė prieš 10 mėnesių. Jei tokia klaida būtų aptikta „Apple“ įrenginiuose, beveik neabejoju, kad jie būtų pataisę daug, daug greičiau. „Google“ iš esmės rėmėsi rizikingu lažinimu, kad „MediaTek-su“ iki 2020 m. kovo mėn. Nors atrodo, kad „Google“ šiuo atžvilgiu pasisekė, neįsivaizduojame, kiek kenkėjiškų programų autorių jau žino apie išnaudojimą. Galų gale, tai sėdėjo atsitiktinėje XDA forumo temoje beveik visus metus.
Šioje nesėkmėje yra dar viena šalis, į kurią aš nelabai kalbėjausi, ir tai yra išnaudojimo autorius, XDA narys diplomatinis. Jo nuopelnas, nemanau, kad jis turėjo kokių nors piktų ketinimų skelbdamas „MediaTek-su“. Galime aiškiai atsekti išnaudojimo kilmę su diplomatiniu noru modifikuoti „Amazon Fire“ planšetinius kompiuterius. Diplomatas man sako, kad jo pagrindinis tikslas kuriant šį pagrindinį metodą buvo padėti bendruomenei. XDA yra jūsų įrenginio pritaikymas, o diplomatinės pastangos bendruomenėje yra tai, kas žmonėms patinka forumuose. Nors diplomato atsisakymas naudoti atvirojo kodo projektą kelia tam tikrą susirūpinimą, jis paaiškina, kad norėjo, kad bendruomenė kuo ilgiau mėgautųsi tuo, turėdama root prieigą. Kai pirmą kartą susisiekiau su diplomatu, jis taip pat pareiškė, kad bendradarbiauja su kai kuriais partneriais, todėl jis negalėjo dalytis projekto šaltinio kodu ir tyrimais. Nors man nepavyko gauti daugiau informacijos apie šį bendradarbiavimą, man įdomu, ar diplomatas būtų pasirinkęs viešai paskelbti šį išnaudojimą, jei „MediaTek“ būtų pasiūliusi klaidų kompensavimo programą. Neįsivaizduoju, kad tokio masto pažeidžiamumas nesumokėtų didelės pinigų sumos, jei „MediaTek“ iš tikrųjų turėtų tokią programą. Diplomatai teigia, kad šis išnaudojimas buvo įmanomas nuo 2015 m. pabaigos MediaTek MT6580 mikroschemų rinkinio, todėl tenka susimąstyti, ar diplomatas yra net pirmasis asmuo, radęs šį išnaudojimą. Jis man sako, kad iki šio straipsnio paskelbimo neturėjo supratimo, kad MediaTek-su buvo aktyviai išnaudojama.
Jei norite patikrinti, ar jūsų įrenginys yra pažeidžiamas MediaTek-su, rankiniu būdu paleiskite scenarijų, kurį paskelbė XDA narys diplomatinis šioje XDA forumo temoje. Jei įvesite šakninį apvalkalą (žinosite, kai simbolis pasikeis iš $ į #), tada žinosite, kad išnaudojimas veikia. Jei tai veikia, turėsite palaukti, kol įrenginio gamintojas išleis naujinimą, kuris pataisys MediaTek-su. Jei jūsų įrenginys praneša apie 2020-03-05 saugos pataisos lygį, kuris yra naujausias 2020 m. kovo mėn. SPL, jis beveik neabejotinai apsaugotas nuo MediaTek-su. Priešingu atveju turėsite tiesiog patikrinti, ar jūsų įrenginys yra pažeidžiamas.
1 atnaujinimas (2020-03-02 21:45 EST): Šis straipsnis buvo atnaujintas siekiant paaiškinti, kad XDA narys diplomatinis iš tikrųjų žinojo apie šio pažeidžiamumo mastą, kai tik atrado jį dar 2019 m. vasario mėn., tačiau iki šio dokumento paskelbimo jis nežinojo apie šio išnaudojimo gamtoje naudojimą. straipsnis. Mes taip pat pataisėme savo formuluotę dėl vienos priežasties, kodėl diplomatas atsisakė pasidalinti projekto šaltinio kodu.