تؤثر الجذور الخفية الهامة لـ MediaTek على ملايين أجهزة Android

في أول يوم اثنين من كل شهر، تقوم Google بنشر نشرة أمان Android، وهي صفحة تكشف كافة الثغرات الأمنية وتصحيحاتها المقدمة من Google نفسها أو الجهات الخارجية الأخرى. لم يكن اليوم استثناءً: فقد أعلنت Google للتو عن نشرة أمان Android لشهر مارس 2020. إحدى الثغرات الأمنية الموثقة في النشرة الأخيرة هي CVE-2020-0069، وهي ثغرة أمنية خطيرة، وتحديدًا ثغرة أمنية rootkit، والذي يؤثر على ملايين الأجهزة المزودة بشرائح من شركة MediaTek، الشركة التايوانية الكبيرة لتصميم الشرائح. على الرغم من أن نشرة أمان Android لشهر مارس 2020 هي على ما يبدو المرة الأولى التي يتم فيها الكشف عن CVE-2020-0069 علنًا، لقد كانت تفاصيل الاستغلال موجودة بالفعل بشكل علني على الإنترنت - وبشكل أكثر تحديدًا، في منتديات XDA-Developers - منذ أبريل لعام 2019. وعلى الرغم من إتاحة MediaTek للتصحيح بعد شهر من اكتشافه، إلا أن الثغرة لا تزال قابلة للاستغلال على العشرات من طرازات الأجهزة. والأسوأ من ذلك هو أن المتسللين يستغلون الثغرة الأمنية بشكل نشط.

والآن لجأت MediaTek إلى Google لسد فجوة التصحيح هذه وتأمين ملايين الأجهزة ضد هذا الاستغلال الأمني ​​الحاسم.

لأي قراء لا يعرفون مطوري XDA، نحن موقع يضم أكبر المنتديات الخاصة بتعديلات برامج Android. عادةً ما تتمحور هذه التعديلات حول الوصول إلى الجذر على الأجهزة من أجل حذف برامج bloatware أو تثبيت برامج مخصصة أو تعديل معلمات النظام الافتراضية. تعد أجهزة Amazon Fire اللوحية أهدافًا شائعة للمتسللين الهواة في منتدياتنا، فهي مليئة بالبرامج القابلة للإلغاء bloatware، وتفتقر إلى إمكانية الوصول إلى تطبيقات البرامج الأساسية مثل متجر Google Play، والأهم من ذلك، أنها ضعيفة للغاية رخيص. التحدي المتمثل في تجذير أقراص Amazon Fire هو أنها مقفلة بشدة لمنع المستخدمين من الخروج من حديقة أمازون المسورة؛ لا توفر أمازون طريقة رسمية لإلغاء قفل أداة تحميل التشغيل لأجهزة 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، MT6797، MT6799، MT8163، MT8167، MT8173، MT8176، MT8183، MT6 580، و MT6595. ونظرًا لعدد شرائح MediaTek التي تأثرت بهذا الاستغلال، فقد أُطلق على هذا الاستغلال اسم "MediaTek-su" أو "MTK-su" باختصار. بتاريخ 17 أبريل 2019، نشر الدبلوماسي موضوعا ثانيا بعنوان "جذر درجة الحرارة المذهل لـ MediaTek ARMv8" في منتدى "تطوير Android المتنوع". في هذا الموضوع، شارك برنامجًا نصيًا يمكن للمستخدمين تنفيذه لمنحهم وصول المستخدم المتميز في Shell، بالإضافة إلى تعيينه SELinux، وحدة Linux kernel التي توفر التحكم في الوصول للعمليات إلى "المتسامحين" غير الآمنين للغاية ولاية. إن حصول المستخدم على حق الوصول إلى الجذر وتعيين SELinux ليكون متساهلاً على أجهزته هو أمر سهل للغاية: كل ما عليك فعله هو نسخ الملف البرنامج النصي إلى مجلد مؤقت، وتغيير الدلائل إلى مكان تخزين البرنامج النصي، وإضافة أذونات قابلة للتنفيذ إلى البرنامج النصي، ثم تنفيذ الأمر النصي.

أكد أعضاء مجتمع XDA أن الاستغلال يعمل على الأجهزة التالية على الأقل:

1. أيسر آيكونيا وان 10 B3-A30
2. أيسر آيكونيا وان 10 B3-A40
3. سلسلة ألبا اللوحية
4. سلسلة الكاتيل 1 5033
5. الكاتيل 1C
6. الكاتيل 3L (2018) سلسلة 5034
7. الكاتيل 3 تي 8
8. سلسلة الكاتيل A5 LED 5085
9. سلسلة الكاتيل A30 5049
10. الكاتيل ايدول 5
11. الكاتيل/تي سي ال A1 A501DL
12. الكاتيل/تي سي ال LX A502DL
13. الكاتيل تترا 5041C
14. Amazon Fire 7 2019 - حتى إصدار Fire OS 6.3.1.2 الإصدار 0002517050244 فقط
15. Amazon Fire HD 8 2016 - حتى إصدار Fire OS 5.3.6.4 الإصدار 626533320 فقط
16. Amazon Fire HD 8 2017 - حتى إصدار Fire OS 5.6.4.0 الإصدار 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 الإصدار 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. أسوس زينباد 3s 10 Z500M
23. سلسلة ASUS ZenPad Z3xxM(F) MT8163
24. تابلت بارنز أند نوبل نوك 7 بوصة BNTV450 & BNTV460
25. تابلت بارنز أند نوبل نوك 10.1 بوصة BNTV650
26. بلاك فيو A8 ماكس
27. بلاك فيو BV9600 برو (هيليو P60)
28. بلو لايف ماكس
29. بلو لايف وان اكس
30. سلسلة بلو R1
31. بلو ار 2 ال تي اي
32. بلو S1
33. بلو تانك اكستريم برو
34. بلو فيفو 8 لتر
35. بلو فيفو الحادي عشر
36. بلو فيفو XL4
37. بلوبو S8
38. بي كيو أكواريس M8
39. القط S41
40. كول باد كول بلاي 8 لايت
41. التنين تاتش K10
42. شعور الصدى
43. جيوني M7
44. هايسنس انفينيتي H12 لايت
45. هواوي GR3 تاغ-L21
46. هواوي Y5II
47. سلسلة هواوي Y6II MT6735
48. لافا ايريس 88S
49. سلسلة لينوفو C2
50. لينوفو تاب E8
51. لينوفو تاب 2 A10-70F
52. ال جي K8+ (2018) X210ULMA (MTK)
53. إل جي كيه 10 (2017)
54. LG تحية سلالة
55. سلسلة LG X power 2/M320 (MTK)
56. سلسلة LG Xpression Plus 2/K40 LMX420
57. لوميجون T3
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. تابلت أندرويد 7 بوصة
69. سلسلة تابلت أون 8 و10 بوصة (MT8163)
70. ممن لهم A5s
71. سلسلة OPPO F5/A73 - أندرويد 8.x فقط
72. سلسلة OPPO F7 - أندرويد 8.x فقط
73. سلسلة OPPO F9 - أندرويد 8.x فقط
74. أووكيتيل K12
75. بروترولي D7
76. ريلمى 1
77. سوني اكسبيريا سي 4
78. سلسلة سوني اكسبيريا C5
79. سوني اكسبيريا L1
80. سوني اكسبيريا L3
81. سلسلة سوني اكسبيريا XA
82. سلسلة سوني اكسبيريا XA1
83. شركة ساوثرن تيليكوم سمارتاب ST1009X (MT8167)
84. سلسلة تكنو سبارك 3
85. سلسلة أوميديجي F1
86. قوة أوميديجي
87. ركوب ويكو
88. ويكو صني
89. ويكو فيو3
90. سلسلة شاومي ريدمي 6/6A
91. زد تي إي بليد A530
92. زد تي إي بليد D6/V6
93. زد تي إي كويست 5 Z3351S

اقرأ أكثر

باستثناء الهواتف المستندة إلى MediaTek من Vivo، وHuawei/Honor (بعد Android 8.0+)، وOPPO (بعد Android 8.0+)، و Samsung، وجد أعضاء مجتمع XDA أن MediaTek-su يعمل في أغلب الأحيان عند محاولته على الأجهزة المتأثرة شرائح. وفقًا لدبلوماسي عضو XDA، فإن أجهزة Vivo وHuawei/Honor وOPPO وSamsung "تستخدم تعديلات kernel لردع الوصول إلى الجذر عبر استغلال،" مما يعني أن المطور سيحتاج إلى البحث في كود مصدر النواة لهذه الأجهزة لإنشاء "إصدار [إصدارات] مخصص" من يستغل. لم يكن ذلك يستحق الجهد الإضافي، لذلك اختار المطور عدم إضافة دعم لهذه الأجهزة على الرغم من أن الاستغلال "من الناحية النظرية" لا يزال من الممكن أن يعمل.

الآن، يجب أن يكون من الواضح أن هذا الاستغلال يؤثر على عدد كبير من الأجهزة في السوق. تعمل شرائح MediaTek على تشغيل المئات من طرازات الهواتف الذكية ذات الميزانية المتوسطة والمتوسطة والأجهزة اللوحية الرخيصة والعلامات التجارية غير التجارية أجهزة فك التشفير، والتي يتم بيع معظمها دون توقع التحديثات في الوقت المناسب من الشركة المصنعة. وبالتالي، من غير المرجح أن تحصل العديد من الأجهزة التي لا تزال متأثرة بـ MediaTek-su على الإصلاح لمدة أسابيع أو أشهر بعد الكشف اليوم، هذا إذا حصلت على إصلاح على الإطلاق. إذن ما الذي يجعل MediaTek-su يكتسب شدته "الحرجة" من خلال ملف نظام CVSS v3.0 درجة 9.3؟

لماذا تعتبر MTK-su ثغرة أمنية خطيرة

للتكرار، الطريقة النموذجية لتحقيق الوصول إلى الجذر على جهاز Android هي فتح أداة تحميل التشغيل أولاً، مما يؤدي إلى تعطيل التحقق من قسم التمهيد. بمجرد إلغاء قفل أداة تحميل التشغيل، يمكن للمستخدم تقديم ثنائي مستخدم متميز للنظام وأيضًا تطبيق إدارة مستخدم متميز للتحكم في العمليات التي يمكنها الوصول إلى الجذر. يؤدي إلغاء قفل أداة تحميل التشغيل إلى تعطيل إحدى ميزات الأمان الرئيسية على الجهاز عمدًا، ولهذا السبب يتعين على المستخدم القيام بذلك السماح بحدوث ذلك بشكل صريح عن طريق تمكين التبديل في خيارات المطور ثم إصدار أمر إلغاء القفل إلى محمل الإقلاع. ومع ذلك، مع MediaTek-su، لا يتعين على المستخدم إلغاء قفل أداة تحميل التشغيل للوصول إلى الجذر. بدلاً من ذلك، كل ما عليهم فعله هو نسخ البرنامج النصي إلى أجهزتهم وتنفيذه في الصدفة. ومع ذلك، فإن المستخدم ليس هو الشخص الوحيد الذي يمكنه القيام بذلك. يمكن لأي تطبيق على هاتفك نسخ البرنامج النصي MediaTek-su إلى الدليل الخاص به ثم تنفيذه للوصول إلى الجذر في Shell. في الواقع، عضو XDA دبلوماسي يسلط الضوء على هذا الاحتمال في سلسلة رسائل المنتدى الخاصة بهم عندما يقترحون مجموعة بديلة من التعليمات باستخدام إما محاكي المحطة الطرفية لتطبيق Android أو ترموكس بدلاً من بنك التنمية الآسيوي.

مع الوصول إلى الجذر، ينهار نموذج أمان Android بشكل أساسي. على سبيل المثال، تصبح الأذونات بلا معنى في سياق الجذر حيث يمكن للتطبيق الذي يتمتع بإمكانية الوصول إلى shell الجذر أن يمنح نفسه أي إذن يريده. علاوة على ذلك، باستخدام غلاف الجذر، يمكن الوصول إلى قسم البيانات بالكامل - بما في ذلك الملفات المخزنة في أدلة البيانات الخاصة للتطبيقات التي لا يمكن الوصول إليها عادةً. يمكن أيضًا للتطبيق الذي لديه الجذر تثبيت أي تطبيق آخر يريده في الخلفية بصمت ثم منحه أي أذونات يحتاجها لانتهاك خصوصيتك. وفقًا لمطور XDA المعترف به com.topjohnwu، يمكن للتطبيق الضار أيضًا "حقن التعليمات البرمجية مباشرة في Zygote باستخدام ptrace"، مما يعني أنه يمكن اختراق التطبيق العادي على جهازك لتنفيذ أوامر المهاجم. تتناول هذه الأمثلة فقط بعض الطرق التي يمكن أن ينتهك بها التطبيق ثقتك في الخلفية دون علمك. ومع ذلك، يمكن للتطبيقات الضارة أن تلحق الضرر بجهازك دون إخفاء ما تفعله. برامج الفدية، على سبيل المثال، هي لأقصى حد قوية مع الوصول إلى الجذر. إذا لم تقم بالدفع، يمكن لتطبيق افتراضي لبرامج الفدية أن يفعل ذلك تماما وبشكل لا رجعة فيه اجعل جهازك غير صالح للعمل عن طريق مسح الجهاز بالكامل نظيفًا.

"الضعف" الوحيد في MediaTek-su هو أنه يمنح التطبيق حق الوصول إلى الجذر "المؤقت" فقط، مما يعني أن العملية تفقد وصول المستخدم المتميز بعد إعادة تشغيل الجهاز. علاوة على ذلك، على الأجهزة التي تعمل بنظام التشغيل Android 6.0 Marshmallow والإصدارات الأحدث، يوجد تم التحقق من التمهيد وdm-verity حظر التعديلات على أقسام القراءة فقط مثل النظام والبائعين. ومع ذلك، فإن هذين العاملين لا يشكلان في الغالب سوى عوائق أمام المشرفين على منتدياتنا وليس الجهات الفاعلة الضارة. للتغلب على قيود الجذر المؤقت، يمكن للتطبيق الضار ببساطة إعادة تشغيل البرنامج النصي MediaTek-su في كل عملية تشغيل. من ناحية أخرى، ليست هناك حاجة للتغلب على dm-verity نظرًا لأن التعديلات الدائمة على النظام أو أقسام البائع من غير المرجح أن تثير اهتمام معظم مؤلفي البرامج الضارة؛ بعد كل شيء، هناك بالفعل طن من الأشياء التي يمكن لتطبيق ضار القيام بها باستخدام واجهة الجذر.

إذا كنت تتساءل على المستوى الفني عما يستغله MediaTek-su، فقد شاركت MediaTek معنا الرسم البياني أدناه الذي يلخص نقطة الدخول. يبدو أن الخلل موجود في أحد برامج تشغيل Linux Kernel الخاصة بـ MediaTek والتي تسمى "CMDQ". ينص الوصف على أنه "من خلال تنفيذ IOCTL الأوامر الموجودة في عقدة جهاز CMDQ،" يمكن للمهاجم المحلي "قراءة/كتابة الذاكرة الفعلية بشكل تعسفي، وتفريغ جدول رموز kernel إلى المخزن المؤقت DMA المخصص مسبقًا، [و] التعامل مع المخزن المؤقت DMA لتعديل إعدادات kernel لتعطيل 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." من المحتمل أن يأتي هذا التخفيف من تحديث لـ MediaTek's BSP بدلاً من Android بحد ذاتها. إن التخفيف الوحيد لهذه الثغرة الأمنية في Android 10 هو القيود المفروضة على التطبيقات التي تنفذ الثنائيات في الدليل الرئيسي الخاص بهم; ومع ذلك، كما لاحظ Topjohnwu، مطور XDA المعترف به، يمكن للتطبيق الضار ببساطة تشغيل كود MediaTek-su في مكتبة ديناميكية.

على الرغم من أن MediaTek قامت بتصحيح هذه المشكلة في جميع الشرائح المتأثرة، إلا أنها لا تستطيع إجبار صانعي الأجهزة على تنفيذ التصحيحات. أخبرنا MediaTek أن لديهم تصحيحات جاهزة منذ مايو 2019. ومن غير المستغرب أن تقوم أمازون بتصحيح المشكلة على الفور عبر أجهزتها بمجرد علمها بذلك. ومع ذلك، فقد مرت 10 أشهر منذ أن قامت MediaTek بتوفير الإصلاح لشركائها، حتى الآن في مارس 2020، لم تقم العشرات من الشركات المصنعة للمعدات الأصلية بإصلاح أجهزتها. تعمل معظم الأجهزة المتأثرة على إصدارات Android الأقدم مع مستويات تصحيح أمان Android (SPLs) القديمة، ويكون وضع التحديث أسوأ عندما تأخذ في الاعتبار مئات من طرز الأجهزة الأقل شهرة التي تستخدم شرائح MediaTek هذه. ميدياتيك لديها جاد المشكلة بين يديها هنا، لذلك لجأوا إلى Google للحصول على المساعدة.

على عكس ميديا ​​تيك وجوجل يستطيع إجبار مصنعي المعدات الأصلية على تحديث أجهزتهم من خلال اتفاقيات الترخيص أو مصطلحات البرنامج (مثل Android One). لكي يعلن مصنع المعدات الأصلية (OEM) أن الجهاز يتوافق مع مستوى تصحيح الأمان (SPL) لعام 2020-03-05، يجب أن يتضمن الجهاز كل إطار العمل، إصلاحات Linux kernel وبرامج تشغيل البائع المعمول بها في نشرة أمان Android لشهر مارس 2020، والتي تتضمن إصلاحًا لـ CVE-2020-0069، أو ميدياتيك سو. (لا يبدو أن Google تطبق ذلك في الواقع يقوم مصنعو المعدات الأصلية في الواقع بدمج كافة التصحيحات عند الإعلان عن SPL معين.) الآن بعد أن صدرت نشرة مارس 2020، يجب أن تنتهي هذه القصة، أليس كذلك؟ ولسوء الحظ، يتعين علينا أيضًا أن نضع أقدام Google على النار بسبب تباطؤها في دمج التصحيحات.

الخلل في عملية التصحيح الأمني

في حالة عدم وضوح الأمر بالفعل، فليس من الضروري أن تنتهي كل ثغرة أمنية في نشرة أمان Android. يتم اكتشاف العديد من الثغرات الأمنية وتصحيحها بواسطة البائعين دون ظهورها في النشرة الشهرية. كان من المفترض أن يكون MediaTek-su واحدًا منهم، ولكن لأسباب متعددة، فشل العديد من مصنعي المعدات الأصلية في دمج التصحيحات التي تقدمها MediaTek. (هناك الكثير من الأسباب المحتملة لذلك، بدءًا من الافتقار إلى الموارد إلى قرارات العمل إلى الفشل في التواصل). ذكرت أن MediaTek "لجأت إلى Google" للحصول على المساعدة، وهذا يعني ضمنيًا أن MediaTek طلبت المساعدة من Google للحصول على مصنعي المعدات الأصلية لإصلاح مشاكلهم أخيرًا الأجهزة. ومع ذلك، ربما لم يكن هذا هو الحال في الواقع. أفهم أن Google لم تكن على علم بـ MediaTek-su حتى تم طرحها بالمصادفة في تقرير أمني من تريند مايكرو تم النشر في 6 يناير 2020. في التقرير، تريند مايكرو كان يوثق آخر ثغرة أمنية يطلق عليها اسم "الاستخدام بعد الاستخدام مجانًا في برنامج تشغيل الموثق"الثغرة الأمنية التي تم استغلالها بشكل نشط في البرية. تريند مايكرو لاحظت كيف تمكنت ثلاثة تطبيقات ضارة من الوصول إلى الجذر باستخدام إحدى الطريقتين، إما ثغرة "الاستخدام بعد الاستخدام المجاني في برنامج تشغيل الموثق" أو 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، أي بعد حوالي شهرين من إعلامهم بالمشكلة مشكلة. بينما تقوم Google بإبلاغ شركاء Android بأحدث نشرة أمان Android قبل 30 يومًا كاملة من نشر النشرة (على سبيل المثال. تم إعلام مصنعي المعدات الأصلية بما ورد في نشرة مارس 2020 في أوائل فبراير 2020)، ويمكن لشركة Google، وغالبًا ما تفعل ذلك، تحديث النشرة بالتغييرات أو الإصلاحات الجديدة. إن السبب وراء عدم اختيار Google لتسريع تضمين التصحيح لمثل هذه المشكلة الخطيرة هو أمر خارج نطاق سيطرتي، خاصة عندما قامت شركة MediaTek بإصلاحها قبل 10 أشهر. إذا تم اكتشاف مثل هذا الخلل في أجهزة Apple، فليس لدي أدنى شك في أنهم كانوا سيصدرون إصلاحًا أسرع بكثير. اعتمدت Google بشكل أساسي على الرهان المحفوف بالمخاطر المتمثل في أن MediaTek-su ستظل منخفضة المستوى كما كانت بالفعل حتى نشرة مارس 2020. وبينما يبدو أن شركة Google كانت محظوظة في هذا الصدد، ليس لدينا أي فكرة عن عدد مؤلفي البرامج الضارة الذين يعرفون بالفعل عن هذا الاستغلال. بعد كل شيء، لقد كان موجودًا في موضوع عشوائي في منتدى XDA لمدة ما يقرب من عام كامل.

هناك طرف آخر في هذه الكارثة لم أتناوله كثيرًا، وهو مؤلف هذه الثغرة، وهو عضو XDA دبلوماسي. ويُحسب له أنه لم يكن لديه أي نية خبيثة في نشر MediaTek-su. يمكننا بوضوح تتبع أصل الاستغلال إلى رغبة الدبلوماسي في تعديل أقراص Amazon Fire. أخبرني الدبلوماسي أن هدفه الأساسي في تطوير هذه الطريقة الجذرية كان مساعدة المجتمع. تخصيص جهازك هو ما يدور حوله XDA، والجهود الدبلوماسية في المجتمع هي ما يستمتع به الناس في المنتديات. على الرغم من أن رفض الدبلوماسي فتح المصدر للمشروع يثير بعض المخاوف، إلا أنه يوضح أنه أراد أن يستمتع المجتمع بهذا الوصول إلى الجذر لأطول فترة ممكنة. عندما اتصلت بالدبلوماسي لأول مرة، ذكر أيضًا أنه كان يتعاون مع بعض الشركاء مما منعه من مشاركة الكود المصدري للمشروع والبحث. على الرغم من أنني لم أتمكن من الحصول على مزيد من التفاصيل حول هذا التعاون، إلا أنني أتساءل عما إذا كان الدبلوماسيون سيختارون الإعلان عن هذا الاستغلال إذا عرضت MediaTek برنامج مكافأة الأخطاء. لا أستطيع أن أتخيل أن ثغرة أمنية بهذا الحجم لن تدفع مبلغًا ضخمًا من المال إذا كان لدى MediaTek بالفعل مثل هذا البرنامج. يدعي الدبلوماسيون أن هذا الاستغلال كان ممكنًا منذ أواخر عام 2015 مع شريحة MediaTek MT6580، لذلك يتعين على المرء أن يتساءل عما إذا كان الدبلوماسي هو أول شخص اكتشف هذا الاستغلال. أخبرني أنه لم يكن لديه أي فكرة عن استغلال MediaTek-su بشكل نشط حتى نشر هذا المقال.

إذا كنت تريد التحقق مما إذا كان جهازك عرضة لهجوم MediaTek-su، فقم بتشغيل البرنامج النصي الذي نشره دبلوماسي عضو XDA يدويًا في موضوع منتدى XDA هذا. إذا قمت بإدخال غلاف جذر (ستعرف متى يتغير الرمز من $ إلى #)، فستعرف أن الاستغلال يعمل. إذا نجح الأمر، فستحتاج إلى الانتظار حتى تقوم الشركة المصنعة لجهازك بإصدار تحديث يقوم بتصحيح MediaTek-su. إذا أبلغ جهازك عن مستوى التصحيح الأمني ​​2020-03-05، وهو أحدث إصدار من SPL لشهر مارس 2020، فمن المؤكد تقريبًا أنه محمي ضد MediaTek-su. بخلاف ذلك، سيتعين عليك فقط التحقق مما إذا كان جهازك عرضة للخطر.

---

التحديث 1 (3/2/2020 @ 9:45 مساءً بتوقيت شرق الولايات المتحدة): تم تحديث هذه المقالة لتوضيح أن عضو XDA الدبلوماسي كان على علم فعليًا بنطاق هذه الثغرة الأمنية بمجرد اكتشافه اكتشفها مرة أخرى في فبراير من عام 2019، لكنه لم يكن على علم بالاستخدام الفعلي للبرمجية حتى نشر هذا شرط. لقد قمنا أيضًا بتصحيح صياغتنا فيما يتعلق بأحد أسباب رفض الدبلوماسي مشاركة الكود المصدري للمشروع.