Kritiskais MediaTek saknes komplekts ietekmē miljoniem Android ierīču

Būtisks MediaTek procesoru trūkums ierīcēs tika novērsts OEM nolaidības dēļ. Google cer, ka 2020. gada marta Android drošības biļetens to novērsīs.

Katra mēneša pirmajā pirmdienā Google publicē Android drošības biļetens, lapa, kurā ir atklātas visas drošības ievainojamības un to ielāpi, ko iesniedzis pats Google vai citas trešās puses. Šodiena nebija izņēmums: Google tikko publiskoja Android drošības biļetenu 2020. gada martam. Viena no ievainojamībām, kas ir dokumentēta jaunākajā biļetenā, ir CVE-2020-0069, kas ir kritisks drošības līdzeklis, jo īpaši rootkit, kas ietekmē miljoniem ierīču ar mikroshēmām no MediaTek, lielā Taivānas mikroshēmu projektēšanas uzņēmuma. Lai gan šķiet, ka 2020. gada marta Android drošības biļetens ir pirmā reize, kad CVE-2020-0069 tiek publiski izpausts, informācija par ekspluatāciju faktiski ir atklāta internetā, precīzāk, XDA-Developers forumos, kopš aprīļa. 2019. gada. Neskatoties uz to, ka MediaTek ir padarījis ielāpu pieejamu mēnesi pēc atklāšanas, ievainojamību joprojām var izmantot desmitiem ierīču modeļu.

Vēl ļaunāk, ievainojamību aktīvi izmanto hakeri. Tagad MediaTek ir vērsusies pie Google, lai novērstu šo ielāpu trūkumu un aizsargātu miljoniem ierīču pret šo kritisko drošības izmantošanu.

Visiem lasītājiem, kuri nav pazīstami ar XDA izstrādātāji, mēs esam vietne, kurā atrodas lielākie forumi Android programmatūras modifikācijām. Parasti šīs modifikācijas ir vērstas uz root piekļuves iegūšanu ierīcēs, lai dzēstu bloatware, instalētu pielāgotu programmatūru vai pielāgotu noklusējuma sistēmas parametrus. Amazon's Fire planšetdatori ir iecienīti hakeru mērķi mūsu forumos — tie ir pilni ar atinstalējamu. bloatware, trūkst piekļuves pamata programmatūras lietojumprogrammām, piemēram, Google Play veikalam, un, pats galvenais, ir ļoti lēts. Izaicinājums, kas saistīts ar Amazon Fire planšetdatoru iesakņošanos, ir tas, ka tie ir stipri bloķēti, lai neļautu lietotājiem iziet ārpus Amazon ieskautā dārza; Amazon nenodrošina oficiālu metodi Fire tablešu sāknēšanas ielādes atbloķēšanai, kas parasti ir pirmais solis jebkuras Android ierīces sakņošanā. Tāpēc vienīgais veids, kā sakņot Amazon Fire planšetdatoru (bez aparatūras modifikācijām), ir programmatūras izmantošana, kas ļauj lietotājam apiet Android drošības modeli. 2019. gada februārī tas ir tieši to, ko darīja XDA vecākais diplomātiskais loceklis kad viņš publicēja pavedienu mūsu Amazon Fire planšetdatoru forumos. Viņš ātri saprata, ka šī izmantošana ir daudz plašāka nekā tikai Amazon Fire planšetdatoriem.

Pēc nelielas XDA dalībvalstu diplomātiskās un citu kopienas locekļu pārbaudes tika apstiprināts, ka šī izmantošana darbojas ar lielu skaitu MediaTek mikroshēmu. Autors norāda, ka ļaunprātīga izmantošana darbojas "gandrīz visās MediaTek 64 bitu mikroshēmās", un viņi īpaši nosauc šādus elementus kā neaizsargātus: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6779, MT6795, MT6779, MT6795, MT6796, MT679, 3, MT679, 3, MT679, 3 173, MT8176, MT8183, MT6580 un MT6595. Sakarā ar to, cik daudz MediaTek mikroshēmojumu ietekmēja šī izmantošana, izmantošanai tika piešķirts nosaukums "MediaTek-su" vai saīsināti "MTK-su". 2019. gada 17. aprīlī diplomātisks publicēja otro pavedienu ar nosaukumu "Amazing Temp Root MediaTek ARMv8" mūsu forumā "Dažāda Android izstrāde". Šajā pavedienā viņš kopīgoja skriptu, ko lietotāji var izpildīt, lai piešķirtu viņiem superlietotāja piekļuvi čaulā, kā arī iestatītu SELinux, Linux kodola modulis, kas nodrošina piekļuves kontroli procesiem ļoti nedrošajiem "atļaujošajiem" Valsts. Lai lietotājs iegūtu root piekļuvi un iestatītu SELinux uz atļaujošu savā ierīcē, ir šokējoši viegli: viss, kas jums jādara, ir kopēt skriptu uz pagaidu mapi, mainiet direktorijus, kuros skripts tiek glabāts, pievienojiet skriptam izpildāmās atļaujas un pēc tam izpildiet skripts.

Vienkāršas darbības, lai iegūtu root piekļuvi, izmantojot MediaTek-su. Avots: XDA Senior Member Diplomatic

XDA kopienas locekļi apstiprināja, ka ekspluatācija darbojās vismaz šādās ierīcēs:

  1. Acer Iconia One 10 B3-A30
  2. Acer Iconia One 10 B3-A40
  3. Alba planšetdatoru sērija
  4. Alcatel 1 5033 sērija
  5. Alcatel 1C
  6. Alcatel 3L (2018) 5034 sērija
  7. Alcatel 3T 8
  8. Alcatel A5 LED 5085 sērija
  9. Alcatel A30 5049 sērija
  10. Alcatel Idol 5
  11. Alcatel/TCL A1 A501DL
  12. Alcatel/TCL LX A502DL
  13. Alcatel Tetra 5041C
  14. Amazon Fire 7 2019 — tikai līdz Fire OS 6.3.1.2 build 0002517050244
  15. Amazon Fire HD 8 2016 — tikai līdz Fire OS 5.3.6.4 build 626533320
  16. Amazon Fire HD 8 2017 — tikai līdz Fire OS 5.6.4.0 build 636558520
  17. Amazon Fire HD 8 2018 — tikai līdz Fire OS 6.3.0.1
  18. Amazon Fire HD 10 2017 — tikai līdz Fire OS 5.6.4.0 build 636558520
  19. Amazon Fire HD 10 2019 — tikai līdz Fire OS 7.3.1.0
  20. Amazon Fire TV 2 — tikai līdz Fire OS 5.2.6.9
  21. ASUS ZenFone Max Plus X018D
  22. ASUS ZenPad 3s 10 Z500M
  23. ASUS ZenPad Z3xxM(F) MT8163 sērija
  24. Barnes & Noble NOOK planšetdators 7 collu BNTV450 un BNTV460
  25. Barnes & Noble NOOK planšetdators 10,1 collu BNTV650
  26. Blackview A8 Max
  27. Blackview BV9600 Pro (Helio P60)
  28. BLU Life Max
  29. BLU Life One X
  30. BLU R1 sērija
  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. Atbalss sajūta
  43. Gionee M7
  44. HiSense Infinity H12 Lite
  45. Huawei GR3 TAG-L21
  46. Huawei Y5II
  47. Huawei Y6II MT6735 sērija
  48. Lava Iris 88S
  49. Lenovo C2 sērija
  50. Lenovo Tab E8
  51. Lenovo Tab2 A10-70F
  52. LG K8+ (2018) X210ULMA (MTK)
  53. LG K10 (2017)
  54. LG Tribute dinastija
  55. LG X power 2/M320 sērija (MTK)
  56. LG Xpression Plus 2/K40 LMX420 sērija
  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 planšetdators
  69. Onn 8" un 10" planšetdatoru sērija (MT8163)
  70. OPPO A5s
  71. OPPO F5 series/A73 — tikai operētājsistēmai Android 8.x
  72. OPPO F7 sērija — tikai operētājsistēmai Android 8.x
  73. OPPO F9 sērija — tikai operētājsistēmai Android 8.x
  74. Oukitel K12
  75. Protruly D7
  76. Realme 1
  77. Sony Xperia C4
  78. Sony Xperia C5 sērija
  79. Sony Xperia L1
  80. Sony Xperia L3
  81. Sony Xperia XA sērija
  82. Sony Xperia XA1 sērija
  83. Southern Telecom Smartab ST1009X (MT8167)
  84. TECNO Spark 3 sērija
  85. Umidigi F1 sērija
  86. Umidigi spēks
  87. Wiko brauciens
  88. Wiko Sunny
  89. Wiko skats3
  90. Xiaomi Redmi 6/6A sērija
  91. ZTE Blade A530
  92. ZTE Blade D6/V6
  93. ZTE Quest 5 Z3351S

Lasīt vairāk

Izņemot MediaTek tālruņus no Vivo, Huawei/Honor (pēc Android 8.0+), OPPO (pēc Android 8.0+) un Samsung, XDA kopienas locekļi atklāja, ka MediaTek-su darbojas biežāk, ja to mēģina ietekmēt ierīcēs mikroshēmas. Saskaņā ar XDA Member diplomātisko teikto, Vivo, Huawei/Honor, OPPO un Samsung ierīces "izmanto kodola modifikācijas, lai novērstu root piekļuvi, izmantojot exploits", kas nozīmē, ka izstrādātājam ir jāiedziļinās šo ierīču kodola pirmkodā, lai izveidotu ierīces "pielāgotas versijas". izmantot. Tas nebija papildu pūļu vērts, tāpēc izstrādātājs izvēlējās nepievienot atbalstu šīm ierīcēm, lai gan "teorētiski" izmantošana joprojām varētu darboties.

Šobrīd ir jābūt skaidram, ka šī izmantošana ietekmē lielu skaitu tirgū pieejamo ierīču. MediaTek mikroshēmas nodrošina simtiem budžeta un vidējas klases viedtālruņu modeļu, lētu planšetdatoru un citu zīmolu viedtālruņu modeļus televizora pierīces, no kurām lielākā daļa tiek pārdota, negaidot savlaicīgus atjauninājumus no ražotāja. Tāpēc maz ticams, ka daudzas ierīces, kuras joprojām ietekmē MediaTek-s, nevarēs labot vairākas nedēļas vai mēnešus pēc šodienas informācijas atklāšanas, ja tās vispār tiks labotas. Tātad, kas liek MediaTek-su nopelnīt savu "kritisko" smagumu ar a CVSS v3.0 rezultāts 9,3?

Kāpēc MTK-su ir kritiska drošības ievainojamība

Atkārtoti jāatkārto, ka parasts veids, kā Android ierīcē iegūt root piekļuvi, ir vispirms atbloķēt sāknēšanas ielādētāju, kas atspējo sāknēšanas nodalījuma verifikāciju. Kad sāknēšanas ielādētājs ir atbloķēts, lietotājs var ieviest sistēmā superlietotāja bināro failu un arī superlietotāju pārvaldības lietotni, lai kontrolētu, kuriem procesiem ir piekļuve saknei. Atbloķējot sāknēšanas ielādētāju, tiek apzināti atspējota viena no galvenajām ierīces drošības funkcijām, tāpēc lietotājam ir skaidri atļaut to notikt, parasti iespējojot slēdzi izstrādātāja opcijās un pēc tam izdodot atbloķēšanas komandu sāknēšanas ielādētājs. Tomēr, izmantojot MediaTek-su, lietotājam nav jāatbloķē sāknēšanas ielādētājs, lai iegūtu root piekļuvi. Tā vietā viņiem atliek tikai kopēt skriptu savā ierīcē un izpildīt to čaulā. Tomēr lietotājs nav vienīgais, kurš to var izdarīt. Jebkura jūsu tālruņa lietotne var kopēt MediaTek-su skriptu savā privātajā direktorijā un pēc tam izpildīt to, lai iegūtu saknes piekļuvi čaulā. Faktiski XDA loceklis diplomātisks uzsver šo iespēju savā foruma pavedienā, kad viņi iesaka alternatīvu instrukciju kopu, izmantojot vai nu Termināļa emulators Android lietotnei vai Termux nevis ADB.

Izmantojot root piekļuvi, Android drošības modelis būtībā sabrūk. Piemēram, atļaujas saknes kontekstā kļūst bezjēdzīgas, jo lietotne ar piekļuvi saknes apvalkam var piešķirt sev jebkuru atļauju, ko tā vēlas. Turklāt, izmantojot saknes apvalku, ir pieejams viss datu nodalījums, tostarp faili, kas glabājas lietojumprogrammu parasti nepieejamos privātajos datu direktorijos. Lietojumprogramma ar root var arī klusi fonā instalēt jebkuru citu lietotni, ko tā vēlas, un pēc tam piešķirt tām visas nepieciešamās atļaujas, lai pārkāptu jūsu privātumu. Saskaņā ar XDA Recognized Developer teikto topjohnwu, ļaunprātīga lietotne var pat "ievadīt kodu tieši Zygote, izmantojot ptrace", kas nozīmē, ka parasta lietotne jūsu ierīcē var tikt nolaupīta, lai veiktu uzbrucēja solījumu. Šie piemēri skar tikai dažus veidus, kā lietotne var pārkāpt jūsu uzticību fonā bez jūsu ziņas. Tomēr ļaunprātīgas lietotnes var radīt postījumus jūsu ierīcē, neslēpjot, ko tās dara. Piemēram, Ransomware ir ārkārtīgi spēcīgs ar piekļuvi saknei; ja jūs nemaksāsit, hipotētiska izspiedējvīrusa lietotne varētu pilnīgi un neatgriezeniski padariet ierīci nederīgu, noslaukot visu ierīci.

Vienīgais MediaTek-su "vājums" ir tas, ka tas lietojumprogrammai piešķir tikai "pagaidu" root piekļuvi, kas nozīmē, ka process zaudē superlietotāja piekļuvi pēc ierīces atsāknēšanas. Turklāt ierīcēs, kurās darbojas operētājsistēma Android 6.0 Marshmallow un jaunāka versija, ir pieejams Verified Boot un dm-verity bloķēt modifikācijas tikai lasāmiem nodalījumiem, piemēram, sistēmai un piegādātājam. Tomēr šie divi faktori lielākoties ir tikai šķēršļi modderiem mūsu forumos, nevis ļaunprātīgiem dalībniekiem. Lai pārvarētu pagaidu saknes ierobežojumu, ļaunprātīga lietotne var vienkārši atkārtoti palaist MediaTek-su skriptu katrā sāknēšanas reizē. No otras puses, ir maza vajadzība pārvarēt dm-verity, jo pastāvīgās izmaiņas sistēmā vai pārdevēja nodalījumos, visticamāk, neinteresēs lielāko daļu ļaunprātīgas programmatūras autoru; galu galā tādas jau ir tonnas no lietām, ko ļaunprātīga lietotne var paveikt ar saknes apvalku.

Ja tehniskā līmenī vēlaties uzzināt, ko MediaTek-su izmanto, MediaTek ar mums kopīgoja zemāk esošo diagrammu, kurā ir apkopots ievades punkts. Trūkums acīmredzot pastāv vienā no MediaTek Linux kodola draiveriem ar nosaukumu "CMDQ". Aprakstā teikts, ka "izpildot IOCTL komandas [CMDQ ierīces mezglā", vietējais uzbrucējs var "patvaļīgi lasīt/rakstīt fizisko atmiņu, izmest [] kodola simbolu tabulu iepriekš piešķirtu DMA buferi, [un] manipulējiet ar DMA buferi, lai modificētu kodola iestatījumus, atspējotu SELinux un pārietu uz "root" privilēģija."

MediaTek drošības ievainojamības kopsavilkums CVE-2020-0069

Saskaņā ar diagrammu, ko MediaTek kopīgoja ar mums, šī ievainojamība ietekmē MediaTek ierīces ar Linux kodola versiju 3.18, 4.4, 4.9 vai 4.14, kurās darbojas Android versija 7 Nougat, 8 Oreo vai 9 Pie. Acīmredzot ievainojamību nevar izmantot MediaTek ierīcēs, kurās darbojas operētājsistēma Android 10, jo "CMDQ piekļuves atļauja SELinux nodrošina arī ierīču mezglus." Šo mazināšanu, visticamāk, nodrošina MediaTek BSP atjauninājums, nevis Android. pati par sevi. Android 10 vienīgais šīs ievainojamības mazināšanas līdzeklis ir tā ierobežojums lietotnēm, kas savā mājas direktorijā izpilda bināros failus; tomēr, kā atzīmē XDA Recognized Developer topjohnwu, ļaunprātīga lietotne var vienkārši palaist MediaTek-su kodu dinamiskā bibliotēkā.

Lai gan MediaTek ir izlabojis šo problēmu visās ietekmētajās mikroshēmojumos, viņi nevar piespiest ierīču ražotājus ieviest ielāpus. MediaTek mums pastāstīja, ka ielāpi bija gatavi 2019. gada maijā. Nav pārsteidzoši, ka Amazon nekavējoties novērsa problēmu savās ierīcēs, tiklīdz tās tika informētas. Tomēr ir pagājuši 10 mēneši, kopš MediaTek saviem partneriem darīja pieejamu labojumu 2020. gada martā desmitiem oriģinālo iekārtu ražotāju nav labojuši savas ierīces. Lielākajai daļai ietekmēto ierīču ir vecāki Android laidieni ar novecojušiem Android drošības ielāpu līmeņiem (SPL), un atjaunināšanas situācija ir vēl sliktāka, ja ņem vērā simtiem mazāk zināmu ierīču modeļu, izmantojot šīs MediaTek mikroshēmas. MediaTek ir a nopietni problēmu, tāpēc viņi ir vērsušies pēc palīdzības pie Google.

Atšķirībā no MediaTek, Google var piespiest OEM atjaunināt savas ierīces, izmantojot licences līgumi vai programmas noteikumiem (piemēram, Android One). Lai OEM varētu paziņot, ka ierīce atbilst 2020-03-05 drošības ielāpu līmenim (SPL), ierīcē ir jāietver visas sistēmas, Linux kodols un piemērojamie piegādātāja draiveru labojumi 2020. gada marta Android drošības biļetenā, kurā ir iekļauts CVE-2020-0069 labojums vai MediaTek-su. (Šķiet, ka Google faktiski to nepiespiež OEM faktiski apvieno visus ielāpus tomēr deklarējot noteiktu SPL.) Tagad, kad ir iznācis 2020. gada marta biļetens, šim stāstam vajadzētu būt beigtam, vai ne? Diemžēl mums ir arī jātur Google kājas pie uguns, jo viņi vilcinās ar ielāpu iekļaušanu.

Drošības ielāpu procesa trūkums

Ja tas vēl nav skaidrs, ne katrai drošības ievainojamībai ir jānonāk Android drošības biļetenā. Pārdevēji atklāj un izlabo daudzas ievainojamības, tās nekad neparādās ikmēneša biļetenā. MediaTek-su vajadzēja būt vienam no tiem, taču vairāku iemeslu dēļ vairākiem oriģinālo iekārtu ražotājiem neizdevās integrēt MediaTek piedāvātos ielāpus. (Ir daudzi iespējamie iemesli, sākot no resursu trūkuma līdz biznesa lēmumiem un neveiksmēm komunikācijā.) Kad es iepriekš norādīja, ka MediaTek "griezās pie Google" pēc palīdzības, tas nozīmēja, ka MediaTek aktīvi meklēja palīdzību no Google, lai liktu oriģinālo iekārtu ražotājiem beidzot salabot savus ierīces. Tomēr patiesībā tas varēja nebūt. Es saprotu, ka Google nezināja par MediaTek-su, līdz tas nejauši tika minēts drošības ziņojumā no TrendMicro publicēts 2020. gada 6. janvārī. Ziņojumā TrendMicro dokumentēja cits drošības ievainojamība, saukta par "izmantošana pēc brīvas saistvielas draiverī" ievainojamība, kas tika aktīvi izmantota savvaļā. TrendMicro atzīmēja, kā trīs ļaunprātīgas lietotnes ieguva root piekļuvi, izmantojot vienu no divām metodēm — vai nu ievainojamību “izmantošana pēc brīvas saistīšanas draiverī” vai MediaTek-su.

Iespējamās Play veikala lietotnes, kas ļaunprātīgi izmanto MediaTek-su. Avots: TrendMicro.

Kodā, kas TrendMicro kopīgots, mēs varam skaidri redzēt, kā ļaunprātīgās lietotnes bija mērķētas uz konkrētiem ierīču modeļiem (piem., Nokia 3, OPPO F9 un Redmi 6A) un tajos izmanto MediaTek-su.

Es nevaru runāt vārdā TrendMicro, taču šķiet, ka viņi nezināja, ka MediaTek-su ir vēl neizlabots izmantojums. Galu galā viņu galvenā uzmanība tika pievērsta "izmantošanai pēc-bezmaksas saistvielu draiverī", un šķiet, ka MediaTek-su izmantošanas atklāšana bija pēcpārdomāta. (Esmu pārliecināts, ka, ja TrendMicro zinājuši par situāciju saistībā ar MediaTek-su, viņi būtu saskaņojuši savus informācijas izpaušanas centienus ar Google.) Mēs bijām informēti tikai par 2020. gada 5. februārī mēs paši izpētījām, cik tas ir slikti, un 7. februārī par to sazinājāmies ar uzņēmumu Google. 2020. Google bija tik noraizējies par MediaTek-su publicēšanas sekām, ka lūdza mūs atlikt šī stāsta publicēšanu līdz šodienai. Ņemot vērā nelabojamo kaitējumu, kas var tikt nodarīts lietotājiem, kuru mērķauditorija ir ļaunprātīga programmatūra MediaTek-su, mēs vienojāmies apturēt šo stāstu līdz paziņojumam par 2020. gada marta Android Drošības biļetens. Tomēr, ņemot vērā, cik ilgs laiks būs nepieciešams daudzām ierīcēm, lai iegūtu jaunāko drošības atjauninājumu, ja tāds vispār būs pieejams lai to saprastu, noteikti būs ļoti daudz ierīču, kuras joprojām būs neaizsargātas pret MediaTek-su dažus mēnešus no plkst. tagad. Tam vajadzētu būt šausminošam ikvienam, kam ir neaizsargāta ierīce.

Lai gan šī ļoti nopietnā, “kritiskā” ievainojamība tiek aktīvi izmantota savvaļā, tikai Google šīs problēmas labojums tika ievietots 2020. gada marta biļetenā, kas ir aptuveni 2 mēneši pēc tam, kad viņi tika informēti par izdevums. Lai gan Google informē savus Android partnerus par jaunāko Android drošības biļetenu 30 dienas pirms biļetena publiskošanas (t. Oriģinālo iekārtu ražotāji tika informēti par 2020. gada marta biļetena saturu 2020. gada februāra sākumā), Google var un bieži arī dara, lai atjauninātu biļetenu ar izmaiņām vai jauniem labojumiem. Es nesaprotu, kāpēc Google neizvēlējās paātrināt ielāpa iekļaušanu tik nopietnai problēmai, it īpaši, ja MediaTek to laboja pirms 10 mēnešiem. Ja šāda kļūda tiktu atklāta Apple ierīcēs, man nav šaubu, ka tās būtu izlaidušas labojumu daudz, daudz ātrāk. Google būtībā balstījās uz riskantām likmēm, ka MediaTek-su paliks tikpat šķietami zema profila kā tas jau bija līdz 2020. gada marta biļetenam. Lai gan šķiet, ka Google šajā ziņā ir paveicies, mums nav ne jausmas, cik daudz ļaunprātīgas programmatūras autoru jau zina par ļaunprātīgu izmantošanu. Galu galā, tas ir sēdējis nejaušā XDA foruma pavedienā gandrīz veselu gadu.

Šajā neveiksmē ir vēl viena puse, kurai es neesmu daudz runājis, un tā ir varoņdarba autors, XDA loceklis diplomātisks. Viņa gods jāsaka, ka, manuprāt, viņam nebija ļaunu nolūku, publicējot MediaTek-su. Mēs varam skaidri izsekot ekspluatācijas izcelsmei līdz diplomātiskajai vēlmei modificēt Amazon Fire planšetdatorus. Diplomātisks man saka, ka viņa galvenais mērķis, izstrādājot šo saknes metodi, bija palīdzēt sabiedrībai. XDA ir ierīces pielāgošana, un forumos cilvēkiem patīk diplomātiskās pūles. Lai gan diplomātiskā atteikšanās atvērt projektu rada zināmas bažas, viņš skaidro, ka vēlējies, lai kopiena pēc iespējas ilgāk izbaudītu šo iespēju ar root piekļuvi. Kad es pirmo reizi sazinājos ar diplomātu, viņš arī paziņoja, ka sadarbojas ar dažiem partneriem, kas viņam neļāva koplietot projekta pirmkodu un pētījumus. Lai gan es nevarēju iegūt sīkāku informāciju par šo sadarbību, es brīnos, vai diplomātiskie spēki būtu izvēlējušies publiskot šo izmantošanu, ja MediaTek piedāvātu kļūdu novēršanas programmu. Es nevaru iedomāties, ka šāda mēroga ievainojamība nemaksātu lielu naudas summu, ja MediaTek patiešām būtu šāda programma. Diplomātiskie apgalvojumi, ka šī izmantošana ir bijusi iespējama kopš 2015. gada beigām MediaTek MT6580 mikroshēmojuma, tāpēc jādomā, vai diplomātiskais ir pat pirmais, kurš atklāj šo ekspluatāciju. Viņš man saka, ka viņam nebija ne jausmas, ka MediaTek-su tiek aktīvi izmantots līdz šī raksta publicēšanai.

Ja vēlaties pārbaudīt, vai jūsu ierīce ir neaizsargāta pret MediaTek-su, manuāli palaidiet skriptu, ko ievietojis XDA Member diplomatic. šajā XDA foruma pavedienā. Ja ievadīsit saknes čaulu (jūs zināt, kad simbols mainīsies no $ uz #), tad jūs zināt, ka izmantojums darbojas. Ja tas darbojas, jums būs jāgaida, līdz ierīces ražotājs izlaiž atjauninājumu, kas izlabo MediaTek-su. Ja jūsu ierīce ziņo par drošības ielāpa līmeni 2020-03-05, kas ir jaunākais 2020. gada marta SPL, tad tā gandrīz noteikti ir aizsargāta pret MediaTek-su. Pretējā gadījumā jums būs vienkārši jāpārbauda, ​​​​vai jūsu ierīce ir neaizsargāta.


1. atjauninājums (2.03.2020. plkst. 21:45 EST): Šis raksts tika atjaunināts, lai precizētu, ka XDA loceklis diplomātiskais faktiski apzinājās šīs ievainojamības apjomu, tiklīdz viņš atklāja to 2019. gada februārī, taču viņš nezināja par ekspluatācijas izmantošanu savvaļā līdz šī dokumenta publicēšanai. rakstu. Mēs arī labojām savu formulējumu saistībā ar vienu iemeslu, kāpēc diplomātiskais atteicās kopīgot projekta pirmkodu.