Kriitiline MediaTeki juurkomplekt mõjutab miljoneid Android-seadmeid

MediaTeki protsessorite kriitiline viga jäi OEM-i hooletuse tõttu seadmetes parandamata. Google loodab, et 2020. aasta märtsi Androidi turvabülletään lahendab selle.

Iga kuu esimesel esmaspäeval avaldab Google Androidi turvabülletään, leht, mis avalikustab kõik Google'i enda või teiste kolmandate osapoolte esitatud turvaaukud ja nende paigad. Tänane päev ei olnud erand: Google avalikustas just Androidi turvabülletääni märtsiks 2020. Üks viimases bülletäänis dokumenteeritud haavatavus on CVE-2020-0069, kriitiline turbekasutus, täpsemalt juurkomplekt, mis mõjutab miljoneid seadmeid, millel on Taiwani suure kiibidisaini ettevõtte MediaTeki kiibistik. Kuigi 2020. aasta märtsi Androidi turvabülletään on näiliselt esimene kord, kui CVE-2020-0069 avalikustati, ärakasutamise üksikasjad on tegelikult Internetis – täpsemalt XDA-Developersi foorumites – olnud avalikult alates aprillist. 2019. aastast. Vaatamata sellele, et MediaTek tegi plaastri kättesaadavaks kuu aega pärast avastamist, on haavatavus endiselt kümnete seadmemudelite puhul kasutatav.

Veelgi hullem on see, et häkkerid kasutavad haavatavust aktiivselt ära. Nüüd on MediaTek pöördunud Google'i poole, et täita see lünk ja kaitsta miljoneid seadmeid selle kriitilise turvalisuse eest.

Kõigile lugejatele, kes pole tuttavad XDA-arendajad, oleme sait, mis on koduks suurimatele Androidi tarkvara muudatuste foorumitele. Tavaliselt keskenduvad need muudatused seadmete juurjuurdepääsu saavutamisele, et kustutada bloatware, installida kohandatud tarkvara või kohandada süsteemi vaikeparameetreid. Amazoni Fire tahvelarvutid on meie foorumites harrastajate häkkerite jaoks populaarsed sihtmärgid – need on täis desinstallitavaid bloatware, puudub juurdepääs põhilistele tarkvararakendustele, nagu Google Play pood, ja mis kõige tähtsam, on väga odav. Amazon Fire'i tahvelarvutite juurdumisega seotud väljakutse seisneb selles, et need on tugevalt lukustatud, et takistada kasutajatel Amazoni müüriga ümbritsetud aiast välja astumast; Amazon ei paku ametlikku meetodit Fire-tahvelarvutite alglaaduri avamiseks, mis on tavaliselt esimene samm mis tahes Android-seadme juurdumisel. Seetõttu on ainus viis Amazon Fire tahvelarvuti juurutamiseks (ilma riistvara muutmiseta) leida tarkvarast ärakasutamine, mis võimaldab kasutajal Androidi turvamudelist mööda minna. 2019. aasta veebruaris on see täpselt see, mida XDA vanemliige diplomaatiline tegi kui ta avaldas lõime meie Amazon Fire tahvelarvutite foorumites. Ta mõistis kiiresti, et selle ärakasutamise ulatus oli palju laiem kui lihtsalt Amazoni Fire tahvelarvutid.

Pärast mõningast testimist XDA liikme diplomaatiliste ja teiste kogukonna liikmete poolt leidis kinnitust, et see ärakasutamine töötab paljudel MediaTeki kiipidel. Autor väidab, et ärakasutamine töötab "peaaegu kõigi MediaTeki 64-bitiste kiipide peal" ja nad nimetavad haavatavateks konkreetselt järgmisi: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6779, MT6795, MT6779, MT6795, MT6779, MT6795, MT6796, MT679, 8, MT6796, 8 173, MT8176, MT8183, MT6580 ja MT6595. Kuna see ärakasutamine mõjutas mitut MediaTeki kiibikomplekti, anti sellele rünnakule nimi "MediaTek-su" või "MTK-su". 17. aprillil 2019 avaldas diplomaatia teise lõime pealkirjaga "Hämmastav Temp Root MediaTek ARMv8 jaoks" meie foorumis "Mitmesugune Androidi arendus". Selles lõimes jagas ta skripti, mida kasutajad saavad käivitada, et anda neile shellis superkasutaja juurdepääs, ja määrata SELinux, Linuxi kerneli moodul, mis tagab juurdepääsu juhtimise protsessidele väga ebaturvalistele "lubavatele" olek. Kasutajal on šokeerivalt lihtne saada juurjuurdepääs ja seada SELinux oma seadmes lubavaks: peate vaid kopeerima skript ajutisesse kausta, muutke kataloogid, kuhu skript on salvestatud, lisage skriptile käivitatavad õigused ja seejärel käivitage stsenaarium.

Lihtsad sammud juurjuurdepääsu saamiseks MediaTek-su abil. Allikas: XDA Senior Member Diplomatic

XDA kogukonna liikmed kinnitasid, et ärakasutamine töötas vähemalt järgmistes seadmetes:

  1. Acer Iconia One 10 B3-A30
  2. Acer Iconia One 10 B3-A40
  3. Alba tahvelarvuti seeria
  4. Alcatel 1 5033 seeria
  5. Alcatel 1C
  6. Alcatel 3L (2018) 5034 seeria
  7. Alcatel 3T 8
  8. Alcatel A5 LED 5085 seeria
  9. Alcatel A30 5049 seeria
  10. Alcatel Idol 5
  11. Alcatel/TCL A1 A501DL
  12. Alcatel/TCL LX A502DL
  13. Alcatel Tetra 5041C
  14. Amazon Fire 7 2019 – ainult kuni Fire OS 6.3.1.2 build 0002517050244
  15. Amazon Fire HD 8 2016 – ainult kuni Fire OS 5.3.6.4 build 626533320
  16. Amazon Fire HD 8 2017 – ainult kuni Fire OS 5.6.4.0 build 636558520
  17. Amazon Fire HD 8 2018 – ainult kuni operatsioonisüsteemi Fire OS 6.3.0.1
  18. Amazon Fire HD 10 2017 – ainult kuni Fire OS 5.6.4.0 build 636558520
  19. Amazon Fire HD 10 2019 – ainult kuni operatsioonisüsteemi Fire OS 7.3.1.0
  20. Amazon Fire TV 2 – ainult kuni operatsioonisüsteemi Fire OS 5.2.6.9
  21. ASUS ZenFone Max Plus X018D
  22. ASUS ZenPad 3s 10 Z500M
  23. ASUS ZenPad Z3xxM(F) MT8163 põhinev seeria
  24. Barnes & Noble NOOK tahvelarvuti 7" BNTV450 ja BNTV460
  25. Barnes & Noble NOOK tahvelarvuti 10,1" BNTV650
  26. Blackview A8 Max
  27. Blackview BV9600 Pro (Helio P60)
  28. BLU eluiga max
  29. BLU Life One X
  30. BLU R1 seeria
  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. KASS S41
  40. Coolpad Cool Play 8 Lite
  41. Dragon Touch K10
  42. Kaja tunne
  43. Gionee M7
  44. HiSense Infinity H12 Lite
  45. Huawei GR3 TAG-L21
  46. Huawei Y5II
  47. Huawei Y6II MT6735 seeria
  48. Laava Iris 88S
  49. Lenovo C2 seeria
  50. Lenovo Tab E8
  51. Lenovo Tab2 A10-70F
  52. LG K8+ (2018) X210ULMA (MTK)
  53. LG K10 (2017)
  54. LG Tribute dünastia
  55. LG X power 2/M320 seeria (MTK)
  56. LG Xpression Plus 2/K40 LMX420 seeria
  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-tolline Android-tahvelarvuti
  69. Onn 8- ja 10-tolliste tahvelarvutite seeria (MT8163)
  70. OPPO A5s
  71. OPPO F5 series/A73 – ainult Android 8.x
  72. OPPO F7 seeria – ainult Android 8.x
  73. OPPO F9 seeria – ainult Android 8.x
  74. Oukitel K12
  75. Protruly D7
  76. Realme 1
  77. Sony Xperia C4
  78. Sony Xperia C5 seeria
  79. Sony Xperia L1
  80. Sony Xperia L3
  81. Sony Xperia XA seeria
  82. Sony Xperia XA1 seeria
  83. Southern Telecom Smartab ST1009X (MT8167)
  84. TECNO Spark 3 seeria
  85. Umidigi F1 sari
  86. Umidigi võim
  87. Wiko sõit
  88. Wiko Sunny
  89. Wiko vaade3
  90. Xiaomi Redmi 6/6A seeria
  91. ZTE Blade A530
  92. ZTE Blade D6/V6
  93. ZTE Quest 5 Z3351S

Loe rohkem

Välja arvatud Vivo, Huawei/Honori (pärast Android 8.0+), OPPO (pärast Android 8.0+) ja MediaTeki-põhised telefonid Samsungi ja XDA kogukonna liikmed leidsid, et MediaTek-su töötab sagedamini, kui seda proovitakse mõjutatud seadmetes kiibistikud. XDA liikme diplomaatiliste andmete kohaselt kasutavad Vivo, Huawei/Honor, OPPO ja Samsungi seadmed kerneli muudatusi, et takistada juurjuurdepääsu ärakasutamine", mis tähendab, et arendaja peab uurima nende seadmete tuuma lähtekoodi, et luua seadmete kohandatud versioonid. ära kasutada. See ei olnud lisapingutust väärt, nii et arendaja otsustas nendele seadmetele tuge mitte lisada, kuigi "teoreetiliselt" võiks ärakasutamine siiski töötada.

Praeguseks peaks olema selge, et see ärakasutamine mõjutab paljusid turul olevaid seadmeid. MediaTeki kiibid toidavad sadu eelarve- ja keskklassi nutitelefonide mudeleid, odavaid tahvelarvuteid ja brändiväliseid mudeleid digibokse, millest enamik müüakse ilma tootjalt õigeaegseid uuendusi ootamata. Paljud seadmed, mida MediaTek-su endiselt mõjutab, ei saa tõenäoliselt pärast tänast avalikustamist nädalate või kuude jooksul parandust, kui nad seda üldse saavad. Mis paneb MediaTek-su oma "kriitilise" raskusastme välja teenima a CVSS v3.0 skoor 9,3?

Miks MTK-su on kriitiline turvahaavatavus?

Kordame, et tüüpiline viis Android-seadme juurjuurdepääsu saavutamiseks on esmalt alglaaduri avamine, mis keelab alglaadija partitsiooni kontrollimise. Kui alglaadur on lukust vabastatud, saab kasutaja juurutada süsteemi superkasutaja binaarfaili ja ka superkasutaja haldusrakenduse, et juhtida, millistel protsessidel on juurjuurdepääs. Alglaaduri avamine keelab tahtlikult seadme ühe peamise turvafunktsiooni, mistõttu peab kasutaja lubab sel selgesõnaliselt juhtuda, lubades tavaliselt arendaja valikutes lüliti ja andes seejärel avamiskäsu alglaadur. MediaTek-su puhul ei pea kasutaja aga juurjuurdepääsu saamiseks alglaadurit avama. Selle asemel peavad nad vaid kopeerima skripti oma seadmesse ja käivitama selle shellis. Kuid kasutaja pole ainus, kes seda teha saab. Iga teie telefoni rakendus võib kopeerida MediaTek-su skripti oma privaatkataloogi ja seejärel käivitada, et saada shellis juurjuurdepääs. Tegelikult XDA liige diplomaatiline tõstab selle võimaluse esile oma foorumi lõimes, kui nad soovitavad alternatiivset juhiste komplekti, kasutades kas Terminali emulaator Androidi rakenduse jaoks või Termux mitte ADB.

Juurjuurdepääsuga laguneb Androidi turvamudel põhimõtteliselt laiali. Näiteks kaotavad load root kontekstis mõttetuks, kuna juurkestale juurdepääsuga rakendus võib anda endale mis tahes loa, mida ta soovib. Lisaks on juurkestaga juurdepääs kogu andmepartitsioonile, sealhulgas failid, mis on salvestatud rakenduste tavaliselt ligipääsmatutesse privaatsetesse andmekataloogidesse. Juurrakendusega rakendus võib ka vaikselt installida taustal mis tahes muu soovitud rakenduse ja seejärel anda neile mis tahes õigused, mida nad teie privaatsuse rikkumiseks vajavad. Vastavalt XDA tunnustatud arendajale topjohnwu, võib pahatahtlik rakendus isegi "ptrace'i abil koodi otse Zygote'i süstida", mis tähendab, et teie seadme tavaline rakendus võidakse kaaperdada, et teha ründaja pakkumisi. Need näited puudutavad vaid mõnda viisi, kuidas rakendus võib taustal teie teadmata teie usaldust rikkuda. Pahatahtlikud rakendused võivad aga teie seadet laastada, varjamata, mida nad teevad. Lunavara näiteks on äärmiselt võimas juurjuurdepääsuga; kui te ei maksa, võib hüpoteetiline lunavararakendus täielikult ja pöördumatult muutke oma seade kasutuskõlbmatuks, pühkides kogu seadme puhtaks.

MediaTek-su ainus "nõrkus" on see, et see annab rakendusele lihtsalt "ajutise" juurjuurdepääsu, mis tähendab, et protsess kaotab pärast seadme taaskäivitamist superkasutaja juurdepääsu. Lisaks on seadmetes, mis käitavad operatsioonisüsteemi Android 6.0 Marshmallow ja uuemat versiooni, olemasolu Kontrollitud alglaadimine ja dm-verity blokeerige kirjutuskaitstud partitsioonide (nt süsteem ja tarnija) muudatused. Need kaks tegurit takistavad aga enamasti ainult meie foorumite modifitseerijaid, mitte aga pahatahtlikke tegijaid. Ajutise juurfaili piirangutest ülesaamiseks võib pahatahtlik rakendus lihtsalt MediaTek-su skripti igal alglaadimisel uuesti käivitada. Teisest küljest ei ole dm-verity'ist vaja üle saada, kuna süsteemi või müüja partitsioonide püsivad muudatused ei huvita tõenäoliselt enamikku pahavara autoreid; ju neid juba on tonni asjadest, mida pahatahtlik rakendus juurkestaga teha saab.

Kui teil on tehnilisel tasandil küsimus, mida MediaTek-su kasutab, jagas MediaTek meiega allolevat tabelit, mis võtab kokku sisenemispunkti. Ilmselt on viga ühes MediaTeki Linuxi kerneli draiveris nimega "CMDQ". Kirjelduses öeldakse, et "täites IOCTL käsud [CMDQ seadme sõlmes", saab kohalik ründaja "suvaliselt lugeda/kirjutada füüsilist mälu, kustutada [tuuma sümbolite tabel] eelnevalt eraldatud DMA puhver [ja] manipuleerida DMA puhvriga, et muuta kerneli sätteid, et keelata SELinux ja eskaleeruda 'root'ks privileeg."

MediaTeki CVE-2020-0069 turvahaavatavuse kokkuvõte

MediaTeki meiega jagatud diagrammi kohaselt mõjutab see haavatavus MediaTeki seadmeid, millel on Linuxi tuuma versioon 3.18, 4.4, 4.9 või 4.14, millel on Androidi versioon 7 Nougat, 8 Oreo või 9 Pie. Ilmselt ei saa haavatavust kasutada MediaTeki seadmetes, mis käitavad operatsioonisüsteemi Android 10, kuna "CMDQ juurdepääsuluba SELinux jõustab ka seadme sõlmed." See leevendus tuleneb tõenäoliselt MediaTeki BSP värskendusest, mitte Androidist ise. Android 10 ainus selle haavatavuse leevendaja on see piirangud rakendustele, mis käivitavad oma kodukataloogis binaarfaile; aga nagu märgib XDA tunnustatud arendaja topjohnwu, võib pahatahtlik rakendus MediaTek-su koodi lihtsalt dünaamilises teegis käivitada.

Kuigi MediaTek on selle probleemi parandanud kõigis mõjutatud kiibikomplektides, ei saa nad sundida seadmetootjaid plaastreid rakendama. MediaTek ütles meile, et neil olid plaastrid valmis juba 2019. aasta mais. Pole üllatav, et Amazon parandas probleemi kohe oma seadmetes, kui nad sellest teadlikud olid. Sellest ajast, kui MediaTek tegi paranduse oma partneritele kättesaadavaks, on aga möödunud 10 kuud 2020. aasta märtsis pole kümned originaalseadmete tootjad oma seadmeid parandanud. Enamik mõjutatud seadmeid on vanematel Androidi versioonidel, millel on aegunud Androidi turvapaigatasemed (SPL-id) ja värskenduste olukord on veelgi hullem, kui arvestada sadu vähemtuntud seadmemudelid, mis kasutavad neid MediaTeki kiipe. MediaTekil on a tõsine probleem on siin käes, nii et nad on abi saamiseks pöördunud Google'i poole.

Erinevalt MediaTekist, Google'ist saab sundida originaalseadmete tootjaid oma seadmeid värskendama litsentsilepingud või programmi tingimused (nt Android One). Selleks et originaalseadmete tootja saaks kinnitada, et seade vastab 2020-03-05 turvapaigatasemele (SPL), peab seade hõlmama kogu raamistikku, Linuxi kernel ja kohaldatavad müüja draiveri parandused 2020. aasta märtsi Androidi turvabülletäänis, mis sisaldab CVE-2020-0069 parandust või MediaTek-su. (Tundub, et Google seda tegelikult ei jõusta OEM-id ühendavad tegelikult kõik plaastrid teatud SPL-i deklareerimisel.) Nüüd, kui 2020. aasta märtsi bülletään on välja antud, peaks see lugu läbi saama, eks? Kahjuks peame ka Google'i jalad tulel hoidma, et nad plaastrite lisamisel jalgu tõmbavad.

Viga turvapaiga protsessis

Kui see pole juba selge, ei pea iga turvaauku sattuma Androidi turvabülletääni. Müüjad avastavad ja parandavad palju turvaauke, ilma et neid igakuises bülletäänis ilmutaks. MediaTek-su oleks pidanud olema üks neist, kuid mitmel põhjusel ei suutnud mitmed originaalseadmete tootjad MediaTeki pakutavaid plaastreid integreerida. (Sellel on palju võimalikke põhjuseid, alates ressursside puudumisest kuni äriotsusteni ja lõpetades kommunikatsiooni ebaõnnestumisega.) Kui ma varem väitis, et MediaTek "pöördus abi saamiseks Google'i poole", viitas see sellele, et MediaTek otsis aktiivselt Google'ilt abi, et panna originaalseadmete tootjad lõpuks oma probleemid parandama. seadmeid. See ei pruugi aga tegelikult nii olla. Arvan, et Google ei teadnud MediaTek-su-st enne, kui see juhuslikult välja toodi turvaaruandes TrendMicro avaldatud 6. jaanuaril 2020. Aruandes TrendMicro dokumenteeris teine turvahaavatavus, mida nimetatakse "kasutus pärast vaba sideaine draiveris" haavatavus, mida looduses aktiivselt ära kasutati. TrendMicro märkis, kuidas kolm pahatahtlikku rakendust said juurjuurdepääsu, kasutades ühte kahest meetodist, kas haavatavust "kasuta pärast tasuta sidedraiveris" või MediaTek-su.

Väidetavad Play poe rakendused kuritarvitavad MediaTek-su. Allikas: TrendMicro.

Koodis, mis TrendMicro jagatud, näeme selgelt, kuidas pahatahtlikud rakendused sihivad konkreetseid seadmemudeleid (nt. Nokia 3, OPPO F9 ja Redmi 6A) ning kasutades nendes MediaTek-su.

Ma ei saa rääkida TrendMicro, kuid tundub, et nad ei teadnud, et MediaTek-su oli veel parandamata äpardus. Lõppkokkuvõttes keskendusid nad "kasuta pärast tasuta sideaine draiverile" ja MediaTek-su kasutamise avastamine näib olevat järelmõte. (Ma olen kindel, et kui TrendMicro olid MediaTek-suga ümbritsevast olukorrast teadlikud, oleksid nad kooskõlastanud oma avalikustamisalased jõupingutused Google'iga.) Meid teavitati ainult see ärakasutamine toimus 5. veebruaril 2020 ja pärast seda, kui olime ise uurinud, kui halb see oli, võtsime 7. veebruaril Google'iga ühendust, 2020. Google oli MediaTek-su avalikustamise tagajärgede pärast nii mures, et palus meil selle loo avaldamist tänaseni edasi lükata. Pärast seda, kui on kaalutud korvamatut kahju, mis võib tekitada kasutajatele, kelle sihtmärgiks on pahavara MediaTek-su, leppisime kokku, et hoiame selle loo kinni kuni 2020. aasta märtsi Androidi väljakuulutamiseni Turvabülletään. Arvestades siiski, kui kaua kulub paljudel seadmetel uusima turvavärskenduse hankimine, kui üldse kui aru saada, on kindlasti palju seadmeid, mis on mõne kuu pärast MediaTek-su suhtes haavatavad. nüüd. See peaks olema kohutav kõigile, kellel on haavatav seade.

Kuigi seda väga tõsist, "kriitilist" haavatavust kasutatakse looduses aktiivselt ära, kasutab ainult Google lisati selle probleemi parandus 2020. aasta märtsi bülletäänisse, mis on umbes 2 kuud pärast seda, kui neile teatati probleem. Kuigi Google teavitab oma Androidi partnereid uusimast Androidi turvabülletäänist tervelt 30 päeva enne bülletääni avalikustamist (st. OEM-i teavitati 2020. aasta märtsi bülletääni sisust 2020. aasta veebruari alguses). Google saab bülletääni muudatuste või uute parandustega värskendada ja teeb seda sageli. Miks Google ei otsustanud nii tõsise probleemi puhul plaastri lisamist kiirendada, pole mulle selge, eriti kui MediaTekil oli see 10 kuud tagasi parandatud. Kui Apple'i seadmetes selline viga avastataks, siis ma ei kahtle, et nad oleksid selle paranduse välja andnud palju, palju kiiremini. Google panustas sisuliselt riskantsele panusele, et MediaTek-su jääb kuni 2020. aasta märtsi bülletäänini sama näiliselt madala profiiliga, nagu see juba oli. Kuigi näib, et Google'il on selles osas vedanud, pole meil aimugi, kui paljud pahavara autorid juba sellest ärakasutamisest teavad. Lõppude lõpuks on see olnud juhuslikus XDA foorumi lõimes peaaegu terve aasta.

Selles katastroofis on veel üks osapool, kellega ma pole palju kõnelnud, ja see on ärakasutamise autor, XDA liige diplomaatiline. Tema kiituseks tuleb öelda, et ma ei usu, et tal oli MediaTek-su avaldamisel pahatahtlikke kavatsusi. Võime selgelt jälgida ärakasutamise päritolu diplomaatilise sooviga muuta Amazon Fire tahvelarvuteid. Diplomaatiline ütleb mulle, et tema peamine eesmärk selle juurmeetodi väljatöötamisel oli kogukonna abistamine. XDA eesmärk on seadme kohandamine ja foorumites meeldivad inimestele diplomaatilised jõupingutused kogukonnas. Kuigi diplomaatiline keeldumine avatud lähtekoodiga projektist tekitab muret, selgitab ta, et soovis, et kogukond naudiks seda juurjuurdepääsu omamist nii kaua kui võimalik. Kui ma esimest korda diplomaatilisega ühendust võtsin, teatas ta ka, et teeb koostööd mõne partneriga, mis takistas tal projekti lähtekoodi ja uuringuid jagada. Kuigi ma ei saanud selle koostöö kohta rohkem üksikasju, mõtlen, kas diplomaatiline oleks otsustanud selle ärakasutamise avalikustada, kui MediaTek oleks pakkunud vigade eest tasumise programmi. Ma ei kujuta ette, et sellise ulatusega haavatavus kopsakat rahasummat välja ei maksaks, kui MediaTekil selline programm tegelikult oleks. Diplomaatiline väidab, et see ärakasutamine on olnud võimalik alates 2015. aasta lõpust MediaTek MT6580 kiibistikust, seega tuleb mõelda, kas diplomaatiline on isegi esimene inimene, kes selle ärakasutamise leiab. Ta ütleb mulle, et tal polnud kuni selle artikli avaldamiseni aimugi, et MediaTek-su aktiivselt ära kasutati.

Kui soovite kontrollida, kas teie seade on MediaTek-su suhtes haavatav, käivitage käsitsi XDA Member diplomatic postitatud skript selles XDA foorumi lõimes. Kui sisestate juurkesta (saate teada, kui sümbol muutub $-lt #-ks), siis teate, et ärakasutamine töötab. Kui see töötab, peate ootama, kuni teie seadme tootja võtab välja MediaTek-su paikamist pakkuva värskenduse. Kui teie seadme turvapaiga tase on 2020-03-05, mis on viimane märtsi 2020 SPL, on see peaaegu kindlasti MediaTek-su eest kaitstud. Vastasel juhul peate lihtsalt kontrollima, kas teie seade on haavatav.


Värskendus 1 (02.03.2020 kell 21:45 EST): Seda artiklit värskendati, et selgitada, et XDA liige diplomaatiline teadis selle haavatavuse ulatusest kohe, kui ta avastas selle 2019. aasta veebruaris, kuid ta ei teadnud selle ärakasutamist looduses enne selle avaldamist. artiklit. Samuti parandasime oma sõnastust seoses ühe põhjusega, miks diplomaatiline keeldus projekti lähtekoodi jagamast.