รูทคิทที่สำคัญของ MediaTek ส่งผลกระทบต่ออุปกรณ์ Android หลายล้านเครื่อง

ทุกวันจันทร์แรกของทุกเดือน Google จะเผยแพร่ กระดานข่าวความปลอดภัยของ Androidซึ่งเป็นหน้าที่เปิดเผยช่องโหว่ด้านความปลอดภัยทั้งหมดและแพตช์ที่ Google ส่งมาเองหรือบุคคลที่สามอื่นๆ วันนี้ก็ไม่มีข้อยกเว้น: Google เพิ่งเผยแพร่ Android Security Bulletin ประจำเดือนมีนาคม 2020 ต่อสาธารณะ หนึ่งในช่องโหว่ที่ได้รับการบันทึกไว้ในกระดานข่าวล่าสุดคือ CVE-2020-0069 ซึ่งเป็นช่องโหว่ด้านความปลอดภัยที่สำคัญ โดยเฉพาะ รูทคิทซึ่งส่งผลกระทบต่ออุปกรณ์หลายล้านเครื่องที่มีชิปเซ็ตจาก MediaTek บริษัทออกแบบชิปรายใหญ่ของไต้หวัน แม้ว่าแถลงการณ์ความปลอดภัยของ Android ประจำเดือนมีนาคม 2020 จะดูเหมือนเป็นครั้งแรกที่ CVE-2020-0069 ได้รับการเปิดเผยต่อสาธารณะ รายละเอียดของการใช้ประโยชน์ได้รับการเปิดเผยอย่างเปิดเผยบนอินเทอร์เน็ต โดยเฉพาะในฟอรัม XDA-Developers ตั้งแต่เดือนเมษายน ประจำปี 2562 แม้ว่า MediaTek จะออกแพตช์ให้ใช้งานได้หนึ่งเดือนหลังจากการค้นพบ แต่ช่องโหว่ดังกล่าวยังคงสามารถหาประโยชน์ได้บนอุปกรณ์หลายสิบรุ่น

ที่แย่ไปกว่านั้นคือช่องโหว่นี้กำลังถูกแฮกเกอร์หาประโยชน์อย่างแข็งขัน ตอนนี้ MediaTek ได้หันมาใช้ Google เพื่อปิดช่องว่างแพตช์นี้และรักษาความปลอดภัยอุปกรณ์นับล้านจากช่องโหว่ด้านความปลอดภัยที่สำคัญนี้

สำหรับนักอ่านท่านใดที่ไม่คุ้นเคย XDA-นักพัฒนาเราเป็นไซต์ที่รวบรวมฟอรัมที่ใหญ่ที่สุดสำหรับการแก้ไขซอฟต์แวร์ Android โดยปกติแล้ว การปรับเปลี่ยนเหล่านี้จะเน้นไปที่การเข้าถึงรูทบนอุปกรณ์เพื่อลบโบลต์แวร์ ติดตั้งซอฟต์แวร์ที่กำหนดเอง หรือปรับแต่งพารามิเตอร์ระบบเริ่มต้น แท็บเล็ต Fire ของ Amazon เป็นเป้าหมายยอดนิยมสำหรับแฮ็กเกอร์ที่เป็นงานอดิเรกในฟอรัมของเรา—แท็บเล็ตเหล่านี้เต็มไปด้วยสิ่งที่ถอนการติดตั้งได้ bloatware ขาดการเข้าถึงแอปพลิเคชันซอฟต์แวร์พื้นฐานเช่น Google Play Store และที่สำคัญที่สุดคือเป็นอย่างมาก ราคาถูก. ความท้าทายในการรูทแท็บเล็ต Amazon Fire ก็คือพวกมันถูกล็อคอย่างหนักเพื่อป้องกันไม่ให้ผู้ใช้ก้าวออกไปนอกสวนที่มีกำแพงล้อมรอบของ Amazon Amazon ไม่มีวิธีการอย่างเป็นทางการในการปลดล็อค bootloader ของแท็บเล็ต Fire ซึ่งโดยปกติจะเป็นขั้นตอนแรกในการรูทอุปกรณ์ Android ใดๆ ดังนั้น วิธีเดียวที่จะรูทแท็บเล็ต Amazon Fire (โดยไม่ต้องดัดแปลงฮาร์ดแวร์) คือการค้นหาช่องโหว่ในซอฟต์แวร์ที่อนุญาตให้ผู้ใช้ข้ามโมเดลความปลอดภัยของ Android ในเดือนกุมภาพันธ์ปี 2019 นั่นคือ ตรงกับสิ่งที่นักการทูตอาวุโสของ XDA ทำ เมื่อเขาเผยแพร่กระทู้บนฟอรัมแท็บเล็ต Amazon Fire ของเรา เขาตระหนักได้อย่างรวดเร็วว่าช่องโหว่นี้มีขอบเขตกว้างกว่าแท็บเล็ต Fire ของ Amazon มาก

หลังจากการทดสอบเล็กน้อยจากนักการทูตของสมาชิก XDA และสมาชิกชุมชนอื่น ๆ ก็ได้รับการยืนยันว่าช่องโหว่นี้ใช้ได้กับชิป MediaTek จำนวนมาก ผู้เขียนระบุว่าช่องโหว่นี้ใช้ได้กับ "ชิป 64 บิตเกือบทั้งหมดของ MediaTek" และระบุชื่อชิปต่อไปนี้โดยเฉพาะว่ามีความเสี่ยง: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8173, MT8176, MT8183, MT6 580 และ MT6595. เนื่องจากมีชิปเซ็ต MediaTek จำนวนเท่าใดที่ได้รับผลกระทบจากช่องโหว่นี้ ช่องโหว่ดังกล่าวจึงได้รับชื่อเรียกสั้นๆ ว่า "MediaTek-su" หรือ "MTK-su" เมื่อวันที่ 17 เมษายน 2562 นักการทูตได้เผยแพร่กระทู้ที่สองชื่อ "รูทชั่วคราวที่น่าทึ่งสำหรับ MediaTek ARMv8" ในฟอรัม "การพัฒนา Android เบ็ดเตล็ด" ของเรา ในกระทู้นี้ เขาได้แชร์สคริปต์ที่ผู้ใช้สามารถดำเนินการเพื่อให้สิทธิ์การเข้าถึง superuser ในเชลล์และการตั้งค่า SELinux ซึ่งเป็นโมดูลเคอร์เนล Linux ที่ให้การควบคุมการเข้าถึงสำหรับกระบวนการต่างๆ แก่ "การอนุญาต" ที่ไม่ปลอดภัยสูง สถานะ. สำหรับผู้ใช้ที่จะเข้าถึงรูทและตั้งค่า SELinux ให้อนุญาตบนอุปกรณ์ของตนเองนั้นทำได้ง่ายอย่างน่าตกใจ: สิ่งที่คุณต้องทำคือคัดลอกไฟล์ ไปยังโฟลเดอร์ชั่วคราว เปลี่ยนไดเร็กทอรีไปยังตำแหน่งที่จัดเก็บสคริปต์ เพิ่มสิทธิ์ในการเรียกทำงานให้กับสคริปต์ จากนั้นจึงดำเนินการ สคริปต์

สมาชิกชุมชน XDA ยืนยันว่าช่องโหว่นี้ใช้งานได้บนอุปกรณ์ต่อไปนี้เป็นอย่างน้อย:

1. เอเซอร์ Iconia One 10 B3-A30
2. เอเซอร์ Iconia One 10 B3-A40
3. แท็บเล็ตซีรีส์ Alba
4. อัลคาเทล 1 5033 ซีรีส์
5. อัลคาเทล 1C
6. อัลคาเทล 3L (2018) 5034 ซีรีส์
7. อัลคาเทล 3T 8
8. อัลคาเทล A5 LED 5085 ซีรีส์
9. อัลคาเทล A30 5049 ซีรีส์
10. อัลคาเทลไอดอล 5
11. อัลคาเทล/TCL A1 A501DL
12. อัลคาเทล/TCL LX A502DL
13. อัลคาเทล เตตร้า 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. เอซุส เซนโฟน แม็กซ์ พลัส X018D
22. เอซุส 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. แบล็ควิว A8 แม็กซ์
27. แบล็ควิว BV9600 โปร (เฮลิโอ P60)
28. บลู ไลฟ์ แม็กซ์
29. บลู ไลฟ์ วัน เอ็กซ์
30. บลู R1 ซีรีส์
31. บลู R2 LTE
32. บลูเอส1
33. บลูแทงค์เอ็กซ์ตรีมโปร
34. บลูวีโว่ 8L
35. บลูวีโว่ XI
36. บลูวีโว่ XL4
37. บลูบู เอส8
38. บีคิว อควาริส M8
39. กสท S41
40. Coolpad Cool Play 8 Lite
41. ดราก้อนทัช K10
42. ความรู้สึกสะท้อน
43. จีโอนี่ M7
44. HiSense Infinity H12 Lite
45. หัวเว่ย GR3 TAG-L21
46. หัวเหว่ย Y5II
47. หัวเว่ย Y6II MT6735 ซีรีส์
48. ลาวา ไอริส 88S
49. เลอโนโว C2 ซีรีส์
50. เลอโนโว แท็บ E8
51. เลอโนโว Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. แอลจี K10 (2017)
54. LG บรรณาการราชวงศ์
55. LG X power 2/M320 ซีรีส์ (MTK)
56. LG Xpression Plus 2/K40 LMX420 ซีรีส์
57. ลูมิกอน ที3
58. เมซู M5c
59. เมซู M6
60. เมซู โปร 7 พลัส
61. โนเกีย 1
62. โนเกีย 1 พลัส
63. โนเกีย 3
64. โนเกีย 3.1
65. โนเกีย 3.1 พลัส
66. โนเกีย 5.1
67. โนเกีย 5.1 พลัส/X5
68. แท็บเล็ต Android Onn 7"
69. ซีรีส์แท็บเล็ต Onn 8" & 10" (MT8163)
70. ออปโป้ A5s
71. OPPO F5 series/A73 -- Android 8.x เท่านั้น
72. ซีรีส์ OPPO F7 -- Android 8.x เท่านั้น
73. ซีรีส์ OPPO F9 -- Android 8.x เท่านั้น
74. โอคิเทล K12
75. โป่ง D7
76. เรียลมี1
77. โซนี่ เอ็กซ์พีเรีย C4
78. โซนี่ เอ็กซ์พีเรีย ซี 5
79. โซนี่ เอ็กซ์พีเรีย L1
80. โซนี่เอ็กซ์พีเรีย L3
81. โซนี่ Xperia XA ซีรีส์
82. โซนี่ เอ็กซ์พีเรีย XA1 ซีรีส์
83. ภาคใต้โทรคมนาคม Smartab ST1009X (MT8167)
84. เทคโน สปาร์ค 3 ซีรีส์
85. อูมิดิจิ F1 ซีรีส์
86. อูมิดิจิ พาวเวอร์
87. วีโก ไรด์
88. วีโก้ ซันนี่
89. วีโก้ วิว3
90. เสี่ยวมี่ เรดมี่ 6/6เอ ซีรีส์
91. แซดที เบลด A530
92. ZTE Blade D6/V6
93. ZTE เควส 5 Z3351S

อ่านเพิ่มเติม

ยกเว้นโทรศัพท์ที่ใช้ MediaTek จาก Vivo, Huawei/Honor (หลัง Android 8.0+), OPPO (หลัง Android 8.0+) และ สมาชิกชุมชน Samsung และ XDA พบว่า MediaTek-su ทำงานได้บ่อยกว่าปกติเมื่อพยายามบนอุปกรณ์ที่ได้รับผลกระทบ ชิปเซ็ต ตามการทูตของสมาชิก XDA อุปกรณ์ Vivo, Huawei/Honor, OPPO และ Samsung "ใช้การแก้ไขเคอร์เนลเพื่อยับยั้งการเข้าถึงรูทผ่าน การหาประโยชน์" ซึ่งหมายความว่านักพัฒนาจะต้องเจาะลึกซอร์สโค้ดเคอร์เนลของอุปกรณ์เหล่านี้เพื่อสร้าง "เวอร์ชันที่ปรับแต่ง" ของ หาประโยชน์ นั่นไม่คุ้มกับความพยายามที่เพิ่มเข้ามา ดังนั้นนักพัฒนาจึงเลือกที่จะไม่เพิ่มการรองรับสำหรับอุปกรณ์เหล่านี้ แม้ว่าตามทฤษฎีแล้ว การใช้ประโยชน์ยังคงใช้งานได้ก็ตาม

ถึงตอนนี้ เป็นที่ชัดเจนว่าการหาประโยชน์นี้ส่งผลกระทบต่ออุปกรณ์จำนวนมากในตลาด ชิป MediaTek ขับเคลื่อนสมาร์ทโฟนรุ่นราคาประหยัดและระดับกลาง แท็บเล็ตราคาถูก และยี่ห้ออื่นหลายร้อยรุ่น กล่องแปลงสัญญาณโทรทัศน์ซึ่งส่วนใหญ่จำหน่ายโดยไม่ต้องคาดหวังว่าจะได้รับการอัปเดตอย่างทันท่วงทีจากผู้ผลิต อุปกรณ์จำนวนมากที่ยังคงได้รับผลกระทบจาก MediaTek-su จึงไม่น่าจะได้รับการแก้ไขเป็นเวลาหลายสัปดาห์หรือหลายเดือนหลังจากการเปิดเผยในวันนี้ หากพวกเขาได้รับการแก้ไขเลย ดังนั้นสิ่งที่ทำให้ MediaTek-su ได้รับความรุนแรง "วิกฤติ" ด้วย CVSS เวอร์ชัน 3.0 คะแนน 9.3?

เหตุใด MTK-su จึงเป็นช่องโหว่ด้านความปลอดภัยที่สำคัญ

เพื่อย้ำอีกครั้ง วิธีทั่วไปในการเข้าถึงรูทบนอุปกรณ์ Android คือการปลดล็อค bootloader ก่อน ซึ่งจะปิดใช้งานการตรวจสอบพาร์ติชันสำหรับบูต เมื่อปลดล็อคบูตโหลดเดอร์แล้ว ผู้ใช้สามารถแนะนำไบนารีผู้ใช้ขั้นสูงให้กับระบบและยังมีแอปการจัดการผู้ใช้ระดับสูงเพื่อควบคุมว่ากระบวนการใดสามารถเข้าถึงรูทได้ การปลดล็อค Bootloader เป็นการปิดการใช้งานคุณสมบัติความปลอดภัยที่สำคัญอย่างใดอย่างหนึ่งบนอุปกรณ์โดยเจตนา ซึ่งเป็นสาเหตุที่ผู้ใช้ต้อง อนุญาตให้มันเกิดขึ้นอย่างชัดเจนโดยเปิดใช้งานการสลับในตัวเลือกนักพัฒนาแล้วออกคำสั่งปลดล็อคไปที่ บูตโหลดเดอร์ อย่างไรก็ตาม ด้วย MediaTek-su ผู้ใช้ไม่จำเป็นต้องปลดล็อค bootloader เพื่อเข้าถึงรูท สิ่งที่พวกเขาต้องทำก็แค่คัดลอกสคริปต์ไปยังอุปกรณ์และดำเนินการในเชลล์ ผู้ใช้ไม่ใช่คนเดียวที่สามารถทำได้ แอปใดๆ บนโทรศัพท์ของคุณสามารถคัดลอกสคริปต์ MediaTek-su ไปยังไดเร็กทอรีส่วนตัว จากนั้นจึงดำเนินการเพื่อให้เข้าถึงรูทในเชลล์ได้ ในความเป็นจริง XDA สมาชิกนักการทูต เน้นย้ำถึงความเป็นไปได้นี้ ในกระทู้ฟอรั่มของพวกเขาเมื่อพวกเขาแนะนำชุดคำสั่งทางเลือกโดยใช้อย่างใดอย่างหนึ่ง Terminal Emulator สำหรับแอพ Android หรือ เทอร์แม็กซ์ แทนที่จะเป็น ADB

ด้วยการเข้าถึงรูท โมเดลความปลอดภัยของ Android โดยทั่วไปจะแตกสลาย ตัวอย่างเช่น การอนุญาตจะไม่มีความหมายในบริบทของรูท เนื่องจากแอปที่มีสิทธิ์เข้าถึงรูทเชลล์สามารถให้สิทธิ์ตามที่ต้องการได้ นอกจากนี้ ด้วยรูทเชลล์ ทำให้สามารถเข้าถึงพาร์ติชันข้อมูลทั้งหมด รวมถึงไฟล์ที่จัดเก็บไว้ในไดเร็กทอรีข้อมูลส่วนตัวของแอปพลิเคชันซึ่งโดยทั่วไปไม่สามารถเข้าถึงได้ แอปที่มีรูทจะสามารถติดตั้งแอปอื่น ๆ ที่ต้องการในเบื้องหลังได้อย่างเงียบ ๆ จากนั้นจึงให้สิทธิ์ใด ๆ ที่จำเป็นในการละเมิดความเป็นส่วนตัวของคุณ ตาม XDA นักพัฒนาที่ได้รับการยอมรับ ท็อปจอห์นวูแอปที่เป็นอันตรายยังสามารถ "แทรกโค้ดลงใน Zygote โดยตรงโดยใช้ ptrace" ซึ่งหมายความว่าแอปปกติบนอุปกรณ์ของคุณอาจถูกแย่งชิงเพื่อทำตามคำสั่งของผู้โจมตี ตัวอย่างเหล่านี้กล่าวถึงเพียงไม่กี่วิธีที่แอปสามารถละเมิดความไว้วางใจในเบื้องหลังโดยที่คุณไม่รู้ อย่างไรก็ตาม แอปที่เป็นอันตรายสามารถสร้างความเสียหายให้กับอุปกรณ์ของคุณได้โดยไม่ต้องซ่อนสิ่งที่พวกเขากำลังทำอยู่ ตัวอย่างเช่น Ransomware คือ อย่างที่สุด มีพลังในการเข้าถึงรูท หากคุณไม่จ่ายเงิน แอปแรนซัมแวร์สมมุติก็สามารถดำเนินการได้ โดยสิ้นเชิงและไม่สามารถย้อนกลับได้ ทำให้อุปกรณ์ของคุณใช้งานไม่ได้โดยการเช็ดอุปกรณ์ทั้งหมดให้สะอาด

"จุดอ่อน" เพียงอย่างเดียวใน MediaTek-su ก็คือให้สิทธิ์แก่แอปพลิเคชันเพียงการเข้าถึงรูท "ชั่วคราว" ซึ่งหมายความว่ากระบวนการจะสูญเสียการเข้าถึงของผู้ใช้ขั้นสูงหลังจากรีบูตอุปกรณ์ นอกจากนี้ บนอุปกรณ์ที่ใช้ Android 6.0 Marshmallow ขึ้นไป จะมี ยืนยันการบูตและ dm-verity บล็อกการแก้ไขพาร์ติชันแบบอ่านอย่างเดียว เช่น ระบบและผู้จำหน่าย อย่างไรก็ตาม ปัจจัยทั้งสองนี้ส่วนใหญ่เป็นเพียงอุปสรรคต่อผู้ดูแลฟอรัมของเรา มากกว่าจะเป็นอุปสรรคต่อผู้ประสงค์ร้าย เพื่อเอาชนะข้อจำกัดของการรูทชั่วคราว แอปที่เป็นอันตรายสามารถเรียกใช้สคริปต์ MediaTek-su อีกครั้งในทุกการบู๊ต ในทางกลับกัน ไม่จำเป็นต้องเอาชนะ dm-verity เพียงเล็กน้อย เนื่องจากการแก้ไขระบบหรือพาร์ติชันของผู้จำหน่ายอย่างถาวรไม่น่าจะสนใจผู้เขียนมัลแวร์ส่วนใหญ่ ท้ายที่สุดก็มีอยู่แล้ว ตัน สิ่งต่าง ๆ ที่แอปที่เป็นอันตรายสามารถทำได้ด้วยรูทเชลล์

หากคุณสงสัยในระดับทางเทคนิคว่า MediaTek-su ใช้ประโยชน์จากอะไร MediaTek ได้แชร์แผนภูมิด้านล่างนี้กับเราซึ่งสรุปจุดเริ่มต้น เห็นได้ชัดว่ามีข้อบกพร่องอยู่ในไดรเวอร์ Linux Kernel ตัวหนึ่งของ MediaTek ที่เรียกว่า "CMDQ" คำอธิบายระบุว่า "โดยการดำเนินการ IOCTL คำสั่งในโหนดอุปกรณ์ CMDQ" ผู้โจมตีในพื้นที่สามารถ "อ่าน/เขียนหน่วยความจำกายภาพโดยพลการ ถ่ายโอนตารางสัญลักษณ์เคอร์เนล [the] ไปยัง บัฟเฟอร์ DMA ที่จัดสรรไว้ล่วงหน้า [และ] จัดการบัฟเฟอร์ DMA เพื่อแก้ไขการตั้งค่าเคอร์เนลเพื่อปิดการใช้งาน SELinux และเลื่อนระดับเป็น 'รูท' สิทธิพิเศษ."

ตามแผนภูมิที่ MediaTek แบ่งปันกับเรา ช่องโหว่นี้ส่งผลกระทบต่ออุปกรณ์ MediaTek ที่ใช้ Linux Kernel เวอร์ชัน 3.18, 4.4, 4.9 หรือ 4.14 ที่ใช้ Android เวอร์ชัน 7 Nougat, 8 Oreo หรือ 9 Pie ช่องโหว่นี้ไม่สามารถหาประโยชน์ได้บนอุปกรณ์ MediaTek ที่ใช้ Android 10 เนื่องจาก "สิทธิ์การเข้าถึงของ CMDQ โหนดอุปกรณ์ก็ถูกบังคับใช้โดย SELinux เช่นกัน" การบรรเทาผลกระทบนี้อาจมาจากการอัปเดต BSP ของ MediaTek แทนที่จะเป็นจาก Android ตัวมันเอง การบรรเทาช่องโหว่นี้เพียงอย่างเดียวของ Android 10 ก็คือ ข้อ จำกัด ของแอพที่รันไบนารีในโฮมไดเร็กตอรี่; อย่างไรก็ตาม ตามที่ topjohnwu นักพัฒนาที่ได้รับการยอมรับ XDA ระบุไว้ แอปที่เป็นอันตรายสามารถเรียกใช้โค้ด MediaTek-su ในไลบรารีไดนามิกได้

แม้ว่า MediaTek จะแก้ไขปัญหานี้ในชิปเซ็ตที่ได้รับผลกระทบทั้งหมดแล้ว แต่ก็ไม่สามารถบังคับให้ผู้ผลิตอุปกรณ์ติดตั้งแพตช์ได้ MediaTek บอกเราว่าพวกเขามีแพตช์ที่พร้อมแล้วตั้งแต่เดือนพฤษภาคม 2019 ไม่น่าแปลกใจเลยที่ Amazon จะแก้ไขปัญหานี้ในอุปกรณ์ต่างๆ ทันทีที่ได้รับแจ้ง อย่างไรก็ตาม 10 เดือนผ่านไปแล้วนับตั้งแต่ MediaTek ได้ทำการแก้ไขให้กับพันธมิตรของตน แต่ยังเข้ามา ในเดือนมีนาคมปี 2020 OEM หลายสิบรายยังไม่ได้ซ่อมอุปกรณ์ของตน. อุปกรณ์ที่ได้รับผลกระทบส่วนใหญ่อยู่ใน Android รุ่นเก่าที่มีระดับแพตช์ความปลอดภัย (SPL) ของ Android ที่ล้าสมัย และสถานการณ์การอัปเดตจะยิ่งแย่ลงไปอีกเมื่อคุณพิจารณาถึง หลายร้อย ของอุปกรณ์รุ่นที่ไม่ค่อยมีคนรู้จักที่ใช้ชิป MediaTek เหล่านี้ MediaTek มี จริงจัง ปัญหาอยู่ในมือของพวกเขาที่นี่ พวกเขาจึงหันไปขอความช่วยเหลือจาก Google

ต่างจาก MediaTek, Google สามารถ บังคับให้ OEM อัปเดตอุปกรณ์ผ่าน ข้อตกลงใบอนุญาต หรือเงื่อนไขโปรแกรม (เช่น Android One) เพื่อให้ OEM ประกาศว่าอุปกรณ์เป็นไปตามระดับแพตช์รักษาความปลอดภัย (SPL) ปี 2020-03-05 อุปกรณ์จะต้องมีเฟรมเวิร์กทั้งหมด การแก้ไขเคอร์เนล Linux และไดรเวอร์ของผู้จำหน่ายที่เกี่ยวข้องในกระดานข่าวความปลอดภัยของ Android เดือนมีนาคม 2020 ซึ่งรวมถึงการแก้ไขสำหรับ CVE-2020-0069 หรือ MediaTek-su. (ดูเหมือนว่า Google จะไม่บังคับใช้สิ่งนั้นจริงๆ OEM ได้รวมแพตช์ทั้งหมดเข้าด้วยกัน แต่ตอนประกาศ SPL บางอย่าง) ตอนนี้ประกาศเดือนมีนาคม 2563 ออกมาแล้ว เรื่องนี้ก็น่าจะจบแล้วใช่ไหม? น่าเสียดายที่เราต้องยึดเท้าของ Google ไว้กับไฟเพื่อลากเท้าของพวกเขาไปรวมเอาแพทช์

ข้อบกพร่องในกระบวนการแพตช์ความปลอดภัย

ในกรณีที่ยังไม่ชัดเจน ช่องโหว่ด้านความปลอดภัยไม่จำเป็นต้องปรากฏในกระดานข่าวความปลอดภัยของ Android ทุกรายการ ช่องโหว่จำนวนมากถูกค้นพบและแก้ไขโดยผู้จำหน่ายโดยไม่เคยปรากฏในกระดานข่าวรายเดือน MediaTek-su ควรเป็นหนึ่งในนั้น แต่ด้วยเหตุผลหลายประการ ทำให้ OEM หลายรายไม่สามารถรวมแพตช์ที่ MediaTek นำเสนอได้ (มีเหตุผลที่เป็นไปได้หลายประการ ตั้งแต่การขาดแคลนทรัพยากร การตัดสินใจทางธุรกิจ ไปจนถึงความล้มเหลวในการสื่อสาร) เมื่อก่อนหน้านี้ฉัน ระบุว่า MediaTek "หันมาหา Google" เพื่อขอความช่วยเหลือ ซึ่งบอกเป็นนัยว่า MediaTek ขอความช่วยเหลือจาก Google อย่างกระตือรือร้นเพื่อให้ OEM มาแก้ไขปัญหาในที่สุด อุปกรณ์ อย่างไรก็ตามนั่นอาจไม่เป็นเช่นนั้นจริงๆ ฉันเข้าใจว่า Google ไม่ทราบ MediaTek-su จนกว่าจะมีการนำขึ้นมาในรายงานความปลอดภัยโดยไม่ได้ตั้งใจจาก เทรนด์ไมโคร เผยแพร่เมื่อวันที่ 6 มกราคม 2020 ในรายงาน เทรนด์ไมโคร กำลังจัดทำเอกสาร อื่น ช่องโหว่ด้านความปลอดภัยที่เรียกว่า "ใช้งานฟรีในไดรเวอร์ Binder" ช่องโหว่ที่ถูกโจมตีอย่างแข็งขันในป่า เทรนด์ไมโคร สังเกตว่าแอปที่เป็นอันตรายสามแอปเข้าถึงรูทได้อย่างไรโดยใช้หนึ่งในสองวิธี ไม่ว่าจะเป็นช่องโหว่ "ใช้หลังจากฟรีในไดรเวอร์ Binder" หรือ MediaTek-su

ในโค้ดนั้น เทรนด์ไมโคร เมื่อแชร์แล้ว เราจะเห็นได้อย่างชัดเจนว่าแอปที่เป็นอันตรายกำหนดเป้าหมายอุปกรณ์รุ่นใดรุ่นหนึ่ง (เช่น Nokia 3, OPPO F9 และ Redmi 6A) และใช้ MediaTek-su

ฉันไม่สามารถพูดเพื่อ เทรนด์ไมโครแต่ดูเหมือนว่าพวกเขาไม่รู้ว่า MediaTek-su เป็นช่องโหว่ที่ยังไม่มีแพตช์ พวกเขามุ่งเน้นไปที่การหาประโยชน์จาก "การใช้งานฟรีในโปรแกรมควบคุมเครื่องผูก" และการค้นพบการใช้ MediaTek-su ดูเหมือนจะเป็นความคิดในภายหลัง (ผมมั่นใจว่าถ้า. เทรนด์ไมโคร ตระหนักถึงสถานการณ์โดยรอบ MediaTek-su พวกเขาจะประสานความพยายามในการเปิดเผยข้อมูลกับ Google) เราเพียงแต่ได้รับรู้ สิ่งนี้หาประโยชน์จากตัวเราเองในวันที่ 5 กุมภาพันธ์ 2020 และหลังจากตรวจสอบด้วยตนเองว่ามันแย่แค่ไหน เราก็ติดต่อ Google เกี่ยวกับเรื่องนี้ในวันที่ 7 กุมภาพันธ์ 2020. Google มีความกังวลเกี่ยวกับผลสะท้อนกลับของการเผยแพร่ MediaTek-su มากจนพวกเขาขอให้เราระงับการเผยแพร่เรื่องราวนี้จนถึงทุกวันนี้ หลังจากพิจารณาถึงอันตรายที่แก้ไขไม่ได้ที่อาจเกิดกับผู้ใช้ที่เป็นเป้าหมายของการใช้มัลแวร์ MediaTek-su เราตกลงที่จะระงับเรื่องราวนี้ไว้จนกว่าจะมีการประกาศเปิดตัว Android ในเดือนมีนาคม 2020 ประกาศด้านความปลอดภัย อย่างไรก็ตาม ให้พิจารณาว่าอุปกรณ์จำนวนมากจะต้องใช้เวลานานแค่ไหนในการรับการอัปเดตความปลอดภัยล่าสุด หากเป็นเช่นนั้น เข้าใจแล้ว ในอีกไม่กี่เดือนข้างหน้าจะมีอุปกรณ์มากมายที่ยังคงเสี่ยงต่อการโจมตีของ 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 นักการทูตบอกฉันว่าเป้าหมายหลักของเขาในการพัฒนาวิธีการหลักนี้คือการช่วยเหลือชุมชน การปรับแต่งอุปกรณ์ของคุณคือสิ่งสำคัญของ XDA และความพยายามทางการทูตในชุมชนคือสิ่งที่ผู้คนชื่นชอบเกี่ยวกับฟอรัม แม้ว่านักการทูตจะปฏิเสธที่จะเปิดโครงการโอเพ่นซอร์สทำให้เกิดข้อกังวลบางประการ แต่เขาอธิบายว่าเขาต้องการให้ชุมชนเพลิดเพลินกับสิ่งนี้โดยสามารถเข้าถึงรูทได้นานที่สุด เมื่อฉันติดต่อนักการทูตครั้งแรก เขายังระบุด้วยว่าเขาร่วมมือกับพันธมิตรบางรายซึ่งทำให้เขาไม่สามารถแบ่งปันซอร์สโค้ดและการวิจัยของโครงการได้ แม้ว่าฉันไม่สามารถรับรายละเอียดเพิ่มเติมเกี่ยวกับความร่วมมือนี้ได้ แต่ฉันสงสัยว่านักการทูตจะเลือกที่จะเปิดเผยต่อสาธารณะด้วยการใช้ประโยชน์นี้หรือไม่ หาก MediaTek เสนอโปรแกรมรางวัลข้อบกพร่อง ฉันจินตนาการไม่ออกว่าช่องโหว่ขนาดนี้จะไม่สามารถจ่ายเงินจำนวนมหาศาลได้หาก MediaTek มีโปรแกรมดังกล่าวจริงๆ นักการทูตอ้างว่าการใช้ประโยชน์นี้เกิดขึ้นได้ตั้งแต่ปลายปี 2558 ชิปเซ็ต MediaTek MT6580 ดังนั้นจึงต้องสงสัยว่านักการฑูตเป็นคนแรกที่พบการใช้ประโยชน์นี้หรือไม่ เขาบอกฉันว่าเขาไม่รู้ว่า MediaTek-su กำลังถูกเอาเปรียบอย่างแข็งขันจนกระทั่งมีการตีพิมพ์บทความนี้

หากคุณต้องการตรวจสอบว่าอุปกรณ์ของคุณเสี่ยงต่อ MediaTek-su หรือไม่ ให้เรียกใช้สคริปต์ที่โพสต์โดยนักการทูต XDA Member ด้วยตนเอง ในกระทู้ฟอรัม XDA นี้. หากคุณป้อนรูทเชลล์ (คุณจะรู้เมื่อสัญลักษณ์เปลี่ยนจาก $ เป็น #) คุณจะรู้ว่าช่องโหว่นั้นใช้งานได้ หากใช้งานได้ คุณจะต้องรอให้ผู้ผลิตอุปกรณ์ของคุณออกการอัปเดตที่แก้ไข MediaTek-su หากอุปกรณ์ของคุณรายงานระดับแพตช์ความปลอดภัยประจำปี 2020-03-05 ซึ่งเป็น SPL ประจำเดือนมีนาคม 2020 ล่าสุด แสดงว่าอุปกรณ์ดังกล่าวได้รับการปกป้องจาก MediaTek-su เกือบจะอย่างแน่นอน ไม่เช่นนั้น คุณจะต้องตรวจสอบว่าอุปกรณ์ของคุณมีช่องโหว่หรือไม่

---

อัปเดต 1 (2/3/2020 @ 21:45 น. EST): บทความนี้ได้รับการอัปเดตเพื่อชี้แจงว่านักการทูตของ XDA Member ทราบถึงขอบเขตของช่องโหว่นี้ทันทีที่เขา ค้นพบมันย้อนกลับไปในเดือนกุมภาพันธ์ปี 2019 แต่เขาไม่ทราบถึงการใช้งานในป่าของการหาประโยชน์ดังกล่าวจนกระทั่งมีการเผยแพร่สิ่งนี้ บทความ. นอกจากนี้เรายังแก้ไขถ้อยคำของเราเกี่ยวกับสาเหตุหนึ่งที่ทำให้นักการทูตปฏิเสธที่จะเปิดเผยซอร์สโค้ดของโครงการ