კრიტიკული MediaTek rootkit გავლენას ახდენს მილიონობით Android მოწყობილობაზე

ყოველი თვის პირველ ორშაბათს Google აქვეყნებს Android უსაფრთხოების ბიულეტენი, გვერდი, რომელიც ასახავს უსაფრთხოების ყველა დაუცველობას და მათ პატჩებს, რომლებიც წარმოდგენილია თავად Google-ის ან სხვა მესამე მხარის მიერ. დღეს არ იყო გამონაკლისი: Google-მა ახლახან გამოაქვეყნა Android უსაფრთხოების ბიულეტენი 2020 წლის მარტისთვის. ერთ-ერთი დაუცველობა, რომელიც დოკუმენტირებულია უახლეს ბიულეტენში არის CVE-2020-0069, უსაფრთხოების კრიტიკული ექსპლოიტი, კონკრეტულად rootkit, რომელიც გავლენას ახდენს მილიონობით მოწყობილობაზე ჩიპსეტებით MediaTek-ისგან, დიდი ტაივანის ჩიპების დიზაინის კომპანიისგან. მიუხედავად იმისა, რომ 2020 წლის მარტის Android უსაფრთხოების ბიულეტენი, როგორც ჩანს, პირველი შემთხვევაა, როდესაც CVE-2020-0069 საჯაროდ არის გამჟღავნებული, ექსპლოიტის დეტალები რეალურად ღიად დევს ინტერნეტში, უფრო კონკრეტულად, XDA-დეველოპერების ფორუმებზე, აპრილიდან. 2019 წლის. მიუხედავად იმისა, რომ MediaTek-მა გამოაქვეყნა პატჩი ხელმისაწვდომი აღმოჩენიდან ერთი თვის შემდეგ, დაუცველობა კვლავ ექსპლუატირებულია მოწყობილობის ათობით მოდელზე.

კიდევ უფრო უარესი, დაუცველობას ჰაკერები აქტიურად იყენებენ. ახლა MediaTek-მა მიმართა Google-ს, რათა დახუროს ეს პატჩი და დაიცვას მილიონობით მოწყობილობა უსაფრთხოების ამ კრიტიკული ექსპლოიტისგან.

ნებისმიერი მკითხველისთვის, ვინც არ იცნობს XDA-დეველოპერები, ჩვენ ვართ საიტი, სადაც განთავსებულია Android პროგრამული უზრუნველყოფის ცვლილებების უდიდესი ფორუმები. ჩვეულებრივ, ეს ცვლილებები ორიენტირებულია მოწყობილობებზე root წვდომის მიღწევის გარშემო, რათა წაშალოთ bloatware, დააინსტალიროთ პერსონალური პროგრამული უზრუნველყოფა ან შეცვალოთ სისტემის ნაგულისხმევი პარამეტრები. Amazon's Fire ტაბლეტები პოპულარული სამიზნეა ჰობი ჰაკერებისთვის ჩვენს ფორუმებზე - ისინი სავსეა დეინსტალირებულით bloatware, არ აქვს წვდომა ძირითად პროგრამულ პროგრამებზე, როგორიცაა Google Play Store და, რაც მთავარია, ძალიან იაფი. Amazon Fire ტაბლეტების დაფესვიანების გამოწვევა არის ის, რომ ისინი ძლიერად არის ჩაკეტილი, რათა მომხმარებლებს არ დაუშვან ამაზონის კედლების ბაღის გარეთ გასვლა; Amazon არ გთავაზობთ ოფიციალურ მეთოდს Fire ტაბლეტების ჩამტვირთველის განბლოკვისთვის, რაც, როგორც წესი, პირველი ნაბიჯია ნებისმიერი მოცემული Android მოწყობილობის დასაფესვიანებლად. ამიტომ, Amazon Fire ტაბლეტის დაშლის ერთადერთი გზა (ტექნიკის მოდიფიკაციების გარეშე) არის პროგრამულ უზრუნველყოფაში ექსპლოიტის პოვნა, რომელიც საშუალებას აძლევს მომხმარებელს გვერდის ავლით Android-ის უსაფრთხოების მოდელი. 2019 წლის თებერვალში ასეა ზუსტად ის, რაც XDA-ს დიპლომატიურმა წევრმა გააკეთა როდესაც მან გამოაქვეყნა თემა ჩვენს Amazon Fire ტაბლეტის ფორუმებზე. მან სწრაფად გააცნობიერა, რომ ეს ექსპლოიტი ბევრად უფრო ფართო იყო, ვიდრე უბრალოდ Amazon-ის Fire ტაბლეტები.

XDA წევრი დიპლომატიური და საზოგადოების სხვა წევრების მცირე ტესტირების შემდეგ, დადასტურდა, რომ ეს ექსპლოიტი მუშაობს MediaTek-ის უამრავ ჩიპზე. ავტორი აცხადებს, რომ ექსპლოიტი მუშაობს "პრაქტიკულად MediaTek-ის 64-ბიტიან ჩიპებზე" და ისინი კონკრეტულად ასახელებენ შემდეგს, როგორც დაუცველს: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT61MT797, MT6795, MT61MT797 173, MT8176, MT8183, MT6580 და MT6595. იმის გამო, თუ რამდენ MediaTek ჩიპსეტზე დაზარალდა ეს ექსპლოიტი, ექსპლოიტს მიენიჭა სახელი "MediaTek-su" ან "MTK-su", მოკლედ. 2019 წლის 17 აპრილს დიპლომატიურმა გამოაქვეყნა მეორე თემა სახელწოდებით "საოცარი ტემპერატურის ფესვი MediaTek ARMv8-ისთვისჩვენს "Android-ის სხვადასხვა განვითარების" ფორუმზე. ამ თემაში მან გააზიარა სკრიპტი, რომელიც მომხმარებლებს შეუძლიათ შეასრულონ, რათა მათ სუპერმომხმარებლის წვდომა მიანიჭონ shell-ში, ასევე დააყენონ SELinux, Linux-ის ბირთვის მოდული, რომელიც უზრუნველყოფს პროცესებზე წვდომის კონტროლს, უაღრესად დაუცველ "ნებადართულს" სახელმწიფო. იმისათვის, რომ მომხმარებელმა მიიღოს root წვდომა და დააყენოს SELinux ნებადართულზე საკუთარ მოწყობილობაზე, შოკისმომგვრელი მარტივია: ყველაფერი რაც თქვენ უნდა გააკეთოთ არის დააკოპიროთ სკრიპტი დროებით საქაღალდეში, შეცვალეთ დირექტორიები სადაც ინახება სკრიპტი, დაამატეთ შესრულებადი ნებართვები სკრიპტში და შემდეგ შეასრულეთ სკრიპტი.

XDA საზოგადოების წევრებმა დაადასტურეს, რომ ექსპლოიტი მუშაობდა მინიმუმ შემდეგ მოწყობილობებზე:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. ალბას ტაბლეტების სერია
4. Alcatel 1 5033 სერია
5. ალკატელი 1C
6. Alcatel 3L (2018) 5034 სერია
7. Alcatel 3T 8
8. Alcatel A5 LED 5085 სერია
9. 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 -- მდე Fire OS 6.3.1.2 build 0002517050244 მხოლოდ
15. Amazon Fire HD 8 2016 -- მდე Fire OS 5.3.6.4 build 626533320 მხოლოდ
16. Amazon Fire HD 8 2017 -- მდე Fire OS 5.6.4.0 build 636558520 მხოლოდ
17. Amazon Fire HD 8 2018 - მხოლოდ Fire OS 6.3.0.1-მდე
18. Amazon Fire HD 10 2017 -- მდე Fire OS 5.6.4.0 build 636558520 მხოლოდ
19. Amazon Fire HD 10 2019 - მხოლოდ Fire OS 7.3.1.0-მდე
20. Amazon Fire TV 2 - მხოლოდ Fire OS 5.2.6.9-მდე
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. ASUS ZenPad Z3xxM(F) MT8163-ზე დაფუძნებული სერია
24. Barnes & Noble NOOK ტაბლეტი 7" BNTV450 & BNTV460
25. Barnes & Noble NOOK ტაბლეტი 10.1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Life Max
29. BLU Life One X
30. BLU R1 სერია
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. ექო გრძნობა
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Huawei Y6II MT6735 სერია
48. Lava Iris 88S
49. Lenovo C2 სერია
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. LG Tribute Dynasty
55. LG X power 2/M320 series (MTK)
56. LG Xpression Plus 2/K40 LMX420 სერია
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" ანდროიდის ტაბლეტი
69. Onn 8" და 10" ტაბლეტების სერია (MT8163)
70. OPPO A5s
71. OPPO F5 სერია/A73 - მხოლოდ Android 8.x
72. OPPO F7 სერია -- მხოლოდ Android 8.x
73. OPPO F9 სერია -- მხოლოდ Android 8.x
74. Oukitel K12
75. პროტრალურად D7
76. Realme 1
77. Sony Xperia C4
78. Sony Xperia C5 სერია
79. Sony Xperia L1
80. Sony Xperia L3
81. Sony Xperia XA სერია
82. Sony Xperia XA1 სერია
83. Southern Telecom Smartab ST1009X (MT8167)
84. TECNO Spark 3 სერია
85. Umidigi F1 სერია
86. Umidigi Power
87. Wiko Ride
88. ვიკო სანი
89. Wiko View3
90. Xiaomi Redmi 6/6A სერია
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

წაიკითხე მეტი

გარდა MediaTek-ზე დაფუძნებული ტელეფონებისა Vivo-დან, Huawei/Honor-დან (Android 8.0+), OPPO-დან (Android 8.0+) და Samsung-ის, XDA საზოგადოების წევრებმა დაადგინეს, რომ MediaTek-su უფრო ხშირად მუშაობს, ვიდრე არა, როდესაც მცდელობა აქვთ დაზიანებულ მოწყობილობებზე ჩიპსეტები. XDA წევრის დიპლომატიური ვერსიით, Vivo, Huawei/Honor, OPPO და Samsung მოწყობილობები „იყენებენ ბირთვის მოდიფიკაციებს Root წვდომის შესაჩერებლად. ექსპლოიტები", რაც ნიშნავს, რომ დეველოპერს დასჭირდება ამ მოწყობილობების ბირთვის საწყის კოდის გათხრა, რათა შექმნას "მორგებული ვერსიები" ექსპლუატაცია. ეს არ ღირდა დამატებით ძალისხმევაზე, ამიტომ დეველოპერმა არჩია არ დაემატებინა მხარდაჭერა ამ მოწყობილობებისთვის, მიუხედავად იმისა, რომ „თეორიულად“ ექსპლოიტი მაინც იმუშავებდა.

ამ დროისთვის ნათელი უნდა იყოს, რომ ეს ექსპლოიტი გავლენას ახდენს ბაზარზე არსებულ მოწყობილობებზე. MediaTek-ის ჩიპები ასობით ბიუჯეტურ და საშუალო დონის სმარტფონის მოდელს, იაფ ტაბლეტებსა და სმარტფონების სმარტფონს ამუშავებს სეტ-ტოპ ბოქსები, რომელთა უმეტესობა იყიდება მწარმოებლისგან დროული განახლების მოლოდინის გარეშე. ამგვარად, MediaTek-su-ს მიერ ჯერ კიდევ დაზარალებულ ბევრ მოწყობილობას ნაკლებად სავარაუდოა, რომ გამოსწორდეს დღევანდელი გამჟღავნების შემდეგ კვირების ან თვეების განმავლობაში, თუ ისინი საერთოდ მიიღებენ მას. ასე რომ, რა ხდის MediaTek-su-ს თავისი "კრიტიკული" სიმძიმის ა CVSS v3.0 ქულა 9.3?

რატომ არის MTK-su უსაფრთხოების კრიტიკული დაუცველობა

გავიმეოროთ, Android მოწყობილობაზე root წვდომის მიღწევის ტიპიური გზაა ჯერ ჩამტვირთველის განბლოკვა, რომელიც გამორთავს ჩატვირთვის დანაყოფის შემოწმებას. მას შემდეგ, რაც ჩამტვირთავი განბლოკილია, მომხმარებელს შეუძლია შემოიტანოს სუპერმომხმარებლის ორობითი სისტემა და ასევე სუპერმომხმარებლის მართვის აპი, რათა გააკონტროლოს რომელ პროცესებს აქვს წვდომა root-ზე. ჩამტვირთველის განბლოკვა განზრახ გამორთავს მოწყობილობის უსაფრთხოების ერთ-ერთ ძირითად ფუნქციას, რის გამოც მომხმარებელს უწევს ცალსახად დაუშვით, რომ მოხდეს დეველოპერის ოფციებში გადართვის ჩართვით და შემდეგ განბლოკვის ბრძანების გაცემით ჩამტვირთავი. თუმცა, MediaTek-su-სთან ერთად, მომხმარებელს არ სჭირდება ჩამტვირთველის განბლოკვა root წვდომის მისაღებად. ამის ნაცვლად, ყველაფერი რაც მათ უნდა გააკეთონ არის სკრიპტის კოპირება მათ მოწყობილობაზე და შეასრულონ იგი ჭურვიში. თუმცა, მომხმარებელი არ არის ერთადერთი, ვისაც ამის გაკეთება შეუძლია. თქვენს ტელეფონზე არსებულ ნებისმიერ აპს შეუძლია MediaTek-su სკრიპტის კოპირება მის პირად დირექტორიაში და შემდეგ შეასრულოს ის, რომ მოიპოვოს root წვდომა Shell-ში. ფაქტობრივად, XDA წევრი დიპლომატიური ხაზს უსვამს ამ შესაძლებლობას მათი ფორუმის თემაში, როდესაც ისინი გვთავაზობენ ინსტრუქციების ალტერნატიულ კომპლექტს ან ტერმინალის ემულატორი Android აპისთვის ან Termux ვიდრე ADB.

root წვდომით, Android-ის უსაფრთხოების მოდელი ძირითადად იშლება. მაგალითად, ნებართვები უაზრო ხდება root-ის კონტექსტში, რადგან აპს, რომელსაც აქვს წვდომა root shell-ზე, შეუძლია თავად მისცეს ნებისმიერი ნებართვა, რაც მას სურს. გარდა ამისა, root shell-ით, მონაცემთა დანაყოფის მთლიანობა - მათ შორის ფაილები, რომლებიც ინახება ჩვეულებრივ მიუწვდომელ აპლიკაციების მონაცემთა მონაცემთა დირექტორიაში - ხელმისაწვდომია. Root-ის მქონე აპს ასევე შეუძლია ჩუმად დააინსტალიროს ნებისმიერი სხვა აპი, რომელიც მას სურს ფონზე და შემდეგ მიანიჭოს მას ნებართვები, რაც მათ სჭირდებათ თქვენი კონფიდენციალურობის დარღვევისთვის. XDA Recognized Developer-ის მიხედვით topjohnwu, მავნე აპს შეუძლია „პირდაპირი კოდის შეყვანა Zygote-ში ptrace-ის გამოყენებით“, რაც ნიშნავს, რომ თქვენი მოწყობილობის ნორმალური აპი შეიძლება გაიტაცეს თავდამსხმელის შეთავაზების შესასრულებლად. ეს მაგალითები ეხება მხოლოდ რამდენიმე გზას, რომლითაც აპმა შეიძლება დაარღვიოს თქვენი ნდობა ფონზე თქვენი ცოდნის გარეშე. თუმცა, მავნე აპებმა შეიძლება დაარღვიონ თქვენი მოწყობილობა ისე, რომ არ დაიმალონ რას აკეთებენ. Ransomware, მაგალითად, არის უკიდურესად ძლიერი root ხელმისაწვდომობით; თუ არ გადაიხდით, შეიძლება ჰიპოთეტური გამოსასყიდი პროგრამა სრულიად და შეუქცევადად გახადეთ თქვენი მოწყობილობა უფუნქციოდ მთელი მოწყობილობის გაწმენდით.

MediaTek-su-ს ერთადერთი „სისუსტე“ არის ის, რომ იგი ანიჭებს აპლიკაციას მხოლოდ „დროებით“ root წვდომას, რაც ნიშნავს, რომ პროცესი კარგავს სუპერმომხმარებლის წვდომას მოწყობილობის გადატვირთვის შემდეგ. გარდა ამისა, Android 6.0 Marshmallow და ზემოთ მომუშავე მოწყობილობებზე, არსებობს დამოწმებული ჩატვირთვა და dm-verity დაბლოკოს ცვლილებები მხოლოდ წასაკითხად ტიხრებზე, როგორიცაა სისტემა და გამყიდველი. თუმცა, ეს ორი ფაქტორი ძირითადად მხოლოდ ხელს უშლის ჩვენს ფორუმებზე მოდერატორებს და არა მავნე აქტორებს. დროებითი root-ის შეზღუდვის დასაძლევად, მავნე აპს შეუძლია უბრალოდ ხელახლა გაუშვას MediaTek-su სკრიპტი ყოველ ჩატვირთვაზე. მეორეს მხრივ, dm-verity-ის გადალახვა არ არის საჭირო, რადგან სისტემის მუდმივი ცვლილებები ან გამყიდველის დანაყოფები ნაკლებად სავარაუდოა, რომ დააინტერესოს მავნე პროგრამების ავტორთა უმეტესობა; ყოველივე ამის შემდეგ, უკვე არსებობს ტონა რისი გაკეთებაც მავნე აპს შეუძლია root shell-ით.

თუ ტექნიკურ დონეზე გაინტერესებთ, რას იყენებს MediaTek-su, MediaTek-მა გაგვიზიარა ქვემოთ მოცემული დიაგრამა, რომელიც აჯამებს შესვლის წერტილს. როგორც ჩანს, ხარვეზი არსებობს MediaTek-ის Linux Kernel-ის ერთ-ერთ დრაივერში, სახელწოდებით "CMDQ". აღწერაში ნათქვამია, რომ „IOCTL-ის შესრულებით ბრძანებები [CMDQ] მოწყობილობის კვანძში“, ადგილობრივ თავდამსხმელს შეუძლია „თვითნებურად წაიკითხოს/ჩაწეროს ფიზიკური მეხსიერება, გადააგდოს [ბირთის] სიმბოლოების ცხრილი წინასწარ გამოყოფილი DMA ბუფერი, [და] მანიპულირება DMA ბუფერით, რათა შეცვალოთ ბირთვის პარამეტრები, რათა გამორთოთ SELinux და გადავიდეთ "root"-ზე პრივილეგია."

დიაგრამის მიხედვით, რომელიც MediaTek-მა გაგვიზიარა, ეს დაუცველობა გავლენას ახდენს MediaTek მოწყობილობებზე Linux Kernel ვერსიებით 3.18, 4.4, 4.9 ან 4.14, რომლებიც მუშაობენ Android 7 Nougat, 8 Oreo ან 9 Pie ვერსიებით. დაუცველობა არ არის ექსპლუატირებადი MediaTek მოწყობილობებზე, რომლებსაც აქვთ Android 10, როგორც ჩანს, რადგან "CMDQ-ის წვდომის ნებართვა მოწყობილობის კვანძები ასევე დანერგილია SELinux-ის მიერ." ეს შერბილება სავარაუდოდ მოდის MediaTek-ის BSP-ის განახლებიდან და არა Android-ისგან. თავად. Android 10-ის ერთადერთი შერბილება ამ დაუცველობისთვის არის მისი შეზღუდვა აპლიკაციებზე, რომლებიც ასრულებენ ბინარებს თავიანთ მთავარ დირექტორიაში; თუმცა, როგორც XDA Recognized Developer topjohnwu აღნიშნავს, მავნე აპს შეუძლია უბრალოდ გაუშვას MediaTek-su კოდი დინამიურ ბიბლიოთეკაში.

მიუხედავად იმისა, რომ MediaTek-მა ეს პრობლემა მოაგვარა ყველა დაზარალებულ ჩიპსეტში, მათ არ შეუძლიათ აიძულონ მოწყობილობების შემქმნელები განახორციელონ პატჩები. MediaTek-მა გვითხრა, რომ მათ 2019 წლის მაისში მზად ჰქონდათ პატჩები. ამაზონმა, რაც არ უნდა გასაკვირი იყოს, მაშინვე მოაგვარა ეს საკითხი თავის მოწყობილობებზე, როგორც კი მათ გააცნობიერეს. თუმცა, 10 თვე გავიდა მას შემდეგ, რაც MediaTek-მა გამოსწორება ხელმისაწვდომი გახადა თავისი პარტნიორებისთვის, ჯერ კიდევ 2020 წლის მარტში, ათობით OEM-მა არ გაასწორა თავისი მოწყობილობები. დაზარალებული მოწყობილობების უმეტესობა არის ძველ Android გამოშვებებზე, მოძველებული Android უსაფრთხოების პაჩების დონეებით (SPL) და განახლების მდგომარეობა კიდევ უფრო უარესია, როდესაც გაითვალისწინებთ ასობით ნაკლებად ცნობილი მოწყობილობების მოდელები ამ MediaTek ჩიპების გამოყენებით. MediaTek-ს აქვს ა სერიოზული პრობლემა აქ არის, ამიტომ მათ დახმარებისთვის Google-ს მიმართეს.

MediaTek-ისგან განსხვავებით, Google შეუძლია აიძულეთ OEM-ები განაახლონ მოწყობილობების მეშვეობით სალიცენზიო ხელშეკრულებები ან პროგრამის პირობები (როგორიცაა Android One). იმისათვის, რომ OEM-მა განაცხადოს, რომ მოწყობილობა შეესაბამება 2020-03-05 უსაფრთხოების პაჩის დონეს (SPL), მოწყობილობა უნდა შეიცავდეს ყველა ჩარჩოს, Linux-ის ბირთვი და შესაბამისი გამყიდველის დრაივერი შესწორებულია 2020 წლის მარტის Android Security Bulletin-ში, რომელიც მოიცავს CVE-2020-0069-ის შესწორებას, ან MediaTek-su. (როგორც ჩანს, Google არ ახორციელებს ამას OEM ფაქტობრივად აერთიანებს ყველა პატჩს თუმცა, გარკვეული SPL-ის გამოცხადებისას.) ახლა, როცა 2020 წლის მარტის ბიულეტენი გამოვიდა, ეს ამბავი უნდა დასრულდეს, არა? სამწუხაროდ, ჩვენ ასევე გვიწევს Google-ის ფეხები ცეცხლზე მივაწოდოთ, რადგან მათ ფეხებს აჭიანურებენ პატჩების ჩართვისას.

ხარვეზი უსაფრთხოების პაჩის პროცესში

თუ ეს უკვე გაუგებარია, უსაფრთხოების ყველა დაუცველობა არ უნდა დასრულდეს Android Security Bulletin-ში. ბევრი დაუცველობა აღმოჩენილია და ასწორებს მოვაჭრეებს ყოველთვიურ ბიულეტენში მათი გამოჩენის გარეშე. MediaTek-su უნდა ყოფილიყო ერთ-ერთი მათგანი, მაგრამ მრავალი მიზეზის გამო, რამდენიმე OEM-მა ვერ შეძლო MediaTek-ის მიერ შემოთავაზებული პატჩების ინტეგრირება. (არის ამის უამრავი პოტენციური მიზეზი, დაწყებული რესურსების ნაკლებობით, ბიზნეს გადაწყვეტილებებით დამთავრებული კომუნიკაციის წარუმატებლობით.) როდესაც მე ადრე განაცხადა, რომ MediaTek-მა "მიმართა Google-ს" დახმარებისთვის, ეს გულისხმობდა, რომ MediaTek აქტიურად სთხოვდა დახმარებას Google-ისგან, რათა OEM-ები საბოლოოდ გამოესწორებინათ. მოწყობილობები. თუმცა, შესაძლოა, ეს სინამდვილეში ასე არ ყოფილიყო. მე მესმის, რომ Google-მა არ იცოდა MediaTek-su-ს შესახებ, სანამ ის შემთხვევით არ იყო მოხსენიებული უსაფრთხოების ანგარიშში. TrendMicro გამოქვეყნდა 2020 წლის 6 იანვარს. მოხსენებაში, TrendMicro დოკუმენტირებას აკეთებდა სხვა უსაფრთხოების დაუცველობა, სახელწოდებით "გამოყენება-უფასო ბაინდერის დრაივერში„დაუცველობა, რომელიც აქტიურად გამოიყენებოდა ველურ ბუნებაში. TrendMicro აღნიშნეს, თუ როგორ მიაღწიეს სამმა მავნე აპმა Root წვდომას ორიდან ერთ-ერთი მეთოდის გამოყენებით, ან „გამოყენების შემდეგ უფასოდ ბაინდერის დრაივერში“ ან MediaTek-su.

კოდში რომ TrendMicro გაზიარებული, ჩვენ ნათლად ვხედავთ, თუ როგორ მიზნად ისახავდა მავნე აპლიკაციები კონკრეტული მოწყობილობის მოდელებს (მაგ. Nokia 3, OPPO F9 და Redmi 6A) და მათზე MediaTek-su-ის გამოყენება.

არ შემიძლია ლაპარაკი TrendMicro, მაგრამ როგორც ჩანს, მათ არ იცოდნენ, რომ MediaTek-su ჯერ კიდევ დაუმუშავებელი ექსპლოიტი იყო. ბოლოს და ბოლოს, მათი ყურადღება გამახვილდა „შემკვრელ დრაივერში გამოყენების შემდეგ“ ექსპლუატზე და MediaTek-su-ს გამოყენების აღმოჩენა, როგორც ჩანს, შემდგომი აზრი იყო. (დარწმუნებული ვარ, რომ თუ TrendMicro იცოდნენ MediaTek-su-ს ირგვლივ არსებული ვითარების შესახებ, ისინი კოორდინაციას გაუწევდნენ Google-თან გამჟღავნების მცდელობებს.) ჩვენ მხოლოდ შეგვატყობინეს. ეს ექსპლუატაცია საკუთარ თავზე 2020 წლის 5 თებერვალს მოხდა და მას შემდეგ რაც გამოვიკვლიეთ, რამდენად ცუდი იყო, ჩვენ დავუკავშირდით Google-ს ამის შესახებ 7 თებერვალს, 2020. Google იმდენად იყო შეშფოთებული MediaTek-su-ს გამოქვეყნების შედეგებით, რომ მათ გვთხოვეს, შეგვეჩერებინა ამ ამბის გამოქვეყნება დღემდე. გამოუსწორებელი ზიანის გათვალისწინების შემდეგ, რომელიც შეიძლება მიაყენოს მომხმარებლებს, რომლებიც მიზანმიმართულია მავნე პროგრამის გამოყენებით MediaTek-su, ჩვენ შევთანხმდით, რომ შევაჩეროთ ეს ამბავი 2020 წლის მარტის Android-ის გამოცხადებამდე უსაფრთხოების ბიულეტენი. მიუხედავად ამისა, იმის გათვალისწინებით, რამდენი დრო დასჭირდება ბევრ მოწყობილობას უსაფრთხოების უახლესი განახლების მისაღებად, თუ ოდესმე მიიღეთ ეს საერთოდ, აუცილებლად იქნება უამრავი მოწყობილობა, რომელიც კვლავ დაუცველი იქნება MediaTek-su-ზე რამდენიმე თვის შემდეგ ახლა. ეს უნდა იყოს შემზარავი ყველასთვის, ვისაც აქვს დაუცველი მოწყობილობა.

მიუხედავად იმისა, რომ ეს ძალიან სერიოზული, "კრიტიკული" სიმძიმის დაუცველობა აქტიურად გამოიყენება ველურ ბუნებაში, მხოლოდ Google შეტანილია ამ საკითხის შესწორებაში 2020 წლის მარტის ბიულეტენში, რაც დაახლოებით 2 თვის შემდეგ გახდა ცნობილი პრობლემა. მიუხედავად იმისა, რომ Google აცნობებს თავის Android პარტნიორებს Android უსაფრთხოების უახლესი ბიულეტენის შესახებ 30 დღით ადრე ბიულეტენის გასაჯაროებამდე (ე.ი. OEM-ებმა იცოდნენ რა არის 2020 წლის მარტის ბიულეტენში 2020 წლის თებერვლის დასაწყისში), Google-ს შეუძლია და ხშირად აკეთებს ბიულეტენის განახლებას ცვლილებებით ან ახალი შესწორებებით. რატომ არ აირჩია Google-მა დააჩქარა პატჩის ჩართვა ასეთი სერიოზული პრობლემისთვის, ჩემთვის მიღმაა, განსაკუთრებით მაშინ, როდესაც MediaTek-მა 10 თვის წინ გაასწორა ეს. Apple-ის მოწყობილობებში ასეთი ხარვეზი რომ აღმოჩენილიყო, ეჭვი არ მეპარება, რომ გამოსწორებას გასცემდნენ ბევრად, ბევრად უფრო სწრაფად. Google-მა არსებითად დადო სარისკო ფსონი, რომ MediaTek-su დარჩებოდა ისეთივე დაბალი დონის, როგორც ეს იყო 2020 წლის მარტის ბიულეტენამდე. მიუხედავად იმისა, რომ Google-ს, როგორც ჩანს, გაუმართლა ამ მხრივ, ჩვენ წარმოდგენაც არ გვაქვს, რამდენმა მავნე პროგრამის ავტორმა იცის უკვე ექსპლოიტის შესახებ. ბოლოს და ბოლოს, ის ზის შემთხვევით XDA ფორუმის თემაში თითქმის მთელი წელი.

არის კიდევ ერთი მხარე ამ დეგუსტაციაში, რომელსაც ბევრი არ მივმართე და ეს არის ექსპლოიტის ავტორი, XDA წევრი დიპლომატიური. მის დამსახურებად, მე არ ვფიქრობ, რომ მას რაიმე ბოროტი განზრახვა ჰქონდა MediaTek-su-ს გამოქვეყნებით. ჩვენ აშკარად შეგვიძლია მივაკვლიოთ ექსპლოიტის წარმოშობას დიპლომატიური სურვილით შეცვალონ Amazon Fire ტაბლეტები. Diplomatic მეუბნება, რომ მისი მთავარი მიზანი ამ ძირეული მეთოდის შემუშავებისას იყო საზოგადოების დახმარება. თქვენი მოწყობილობის მორგება არის ის, რაც XDA-ს ეხება და საზოგადოებაში დიპლომატიური ძალისხმევა არის ის, რაც ხალხს სიამოვნებს ფორუმებზე. მიუხედავად იმისა, რომ დიპლომატიური უარი პროექტზე ღია წყაროზე აჩენს გარკვეულ შეშფოთებას, ის განმარტავს, რომ მას სურდა საზოგადოებას რაც შეიძლება დიდხანს ესარგებლა ამით root წვდომით. როდესაც პირველად დავუკავშირდი დიპლომატიურ კომპანიას, მან ასევე განაცხადა, რომ თანამშრომლობდა ზოგიერთ პარტნიორთან, რამაც ხელი შეუშალა მას პროექტის წყაროს კოდისა და კვლევის გაზიარებაში. მიუხედავად იმისა, რომ მე ვერ მივიღე მეტი დეტალი ამ თანამშრომლობის შესახებ, მაინტერესებს, აირჩევდა თუ არა დიპლომატიური ამ ექსპლოიტის საჯაროდ გამოსვლას, თუ MediaTek შესთავაზებდა bug bounty პროგრამას. მე ვერ წარმომიდგენია, რომ ასეთი მასშტაბის დაუცველობა არ გადაიხდის სოლიდურ თანხას, თუ MediaTek-ს ნამდვილად ჰქონია ასეთი პროგრამა. დიპლომატიური ამტკიცებს, რომ ეს ექსპლუატაცია შესაძლებელი გახდა 2015 წლის ბოლოს MediaTek MT6580 ჩიპსეტის შემდეგ, ამიტომ უნდა იფიქროთ, არის თუ არა დიპლომატიური პირველი ადამიანი, ვინც იპოვა ეს ექსპლოიტი. ის მეუბნება, რომ ამ სტატიის გამოქვეყნებამდე წარმოდგენა არ ჰქონდა, რომ MediaTek-su-ს აქტიური ექსპლუატაცია ხდებოდა.

თუ გსურთ შეამოწმოთ არის თუ არა თქვენი მოწყობილობა დაუცველი MediaTek-su-ს მიმართ, მაშინ ხელით გაუშვით XDA Member diplomatic-ის მიერ გამოქვეყნებული სკრიპტი ამ XDA ფორუმის თემაში. თუ თქვენ შეიყვანთ root shell-ს (თქვენ გეცოდინებათ, როდის იცვლება სიმბოლო $-დან #-მდე), მაშინ გეცოდინებათ, რომ ექსპლოიტი მუშაობს. თუ ის მუშაობს, მაშინ უნდა დაელოდოთ თქვენი მოწყობილობის მწარმოებელს განაახლებს MediaTek-su-ს. თუ თქვენი მოწყობილობა იტყობინება უსაფრთხოების პაჩის დონეს 2020-03-05, რომელიც არის 2020 წლის მარტის უახლესი SPL, მაშინ ის თითქმის დაცულია MediaTek-su-სგან. წინააღმდეგ შემთხვევაში, თქვენ უბრალოდ უნდა შეამოწმოთ არის თუ არა თქვენი მოწყობილობა დაუცველი.

---

განახლება 1 (3/2/2020 @ 9:45 PM EST): ეს სტატია განახლდა იმის გასარკვევად, რომ XDA წევრი დიპლომატიურმა ფაქტობრივად იცოდა ამ დაუცველობის ფარგლები, როგორც კი იგი აღმოაჩინა ის ჯერ კიდევ 2019 წლის თებერვალში, მაგრამ რომ მან არ იცოდა ექსპლოიტის ველურში გამოყენების შესახებ ამ ინფორმაციის გამოქვეყნებამდე. სტატია. ჩვენ ასევე შევასწორეთ ჩვენი ფორმულირება ერთ-ერთ მიზეზთან დაკავშირებით, რის გამოც დიპლომატიურმა უარი თქვა პროექტის წყაროს კოდის გაზიარებაზე.