Rootkit קריטי של MediaTek משפיע על מיליוני מכשירי אנדרואיד

ביום שני הראשון של כל חודש, גוגל מפרסמת את עלון אבטחה של אנדרואיד, דף החושף את כל פרצות האבטחה והתיקונים שלהן שהוגשו על ידי Google עצמם או צדדים שלישיים אחרים. היום לא היה יוצא מן הכלל: גוגל בדיוק פרסמה את עלון האבטחה של אנדרואיד למרץ 2020. אחת מהפגיעויות המתועדות בעלון האחרון היא CVE-2020-0069, ניצול אבטחה קריטי, במיוחד rootkit, שמשפיע על מיליוני מכשירים עם ערכות שבבים מבית MediaTek, חברת עיצוב השבבים הטייוואנית הגדולה. למרות שעלון האבטחה של אנדרואיד מרץ 2020 הוא לכאורה הפעם הראשונה ש-CVE-2020-0069 נחשף בפומבי, הפרטים של הניצול נמצאים למעשה בגלוי באינטרנט - ליתר דיוק, בפורומים של XDA-Developers - מאז אפריל של 2019. למרות ש-MediaTek הפכה תיקון לזמין חודש לאחר הגילוי, הפגיעות עדיין ניתנת לניצול בעשרות דגמי מכשירים. גרוע מכך, הפגיעות מנוצלת באופן פעיל על ידי האקרים. כעת MediaTek פנתה לגוגל כדי לסגור את פער התיקונים הזה ולאבטח מיליוני מכשירים מפני ניצול אבטחה קריטי זה.

לכל קורא שלא מכיר

מפתחי XDA, אנחנו אתר שהוא ביתם של הפורומים הגדולים ביותר לשינויי תוכנת אנדרואיד. בדרך כלל, שינויים אלה מתרכזים סביב השגת גישת שורש במכשירים על מנת למחוק bloatware, להתקין תוכנה מותאמת אישית או לכוונן פרמטרים של מערכת ברירת המחדל. טאבלטי Fire של אמזון הם יעדים פופולריים עבור האקרים חובבים בפורומים שלנו - הם מלאים בהסרת התקנה bloatware, חסר גישה ליישומי תוכנה בסיסיים כמו חנות Google Play, והכי חשוב, הם מאוד זוֹל. האתגר בהשרשת טאבלטים של Amazon Fire הוא שהם נעולים מאוד כדי למנוע ממשתמשים לצאת מחוץ לגן המוקף חומה של אמזון; אמזון לא מספקת שיטה רשמית לפתוח את טוען האתחול של טאבלטים של Fire, שהוא בדרך כלל השלב הראשון בהשרשת כל מכשיר אנדרואיד נתון. לכן, הדרך היחידה לבצע רוט לטאבלט של Amazon Fire (ללא שינויי חומרה) היא למצוא בתוכנה ניצול המאפשר למשתמש לעקוף את מודל האבטחה של אנדרואיד. בפברואר 2019, זהו בדיוק מה שעשה חבר בכיר ב-XDA כאשר הוא פרסם שרשור בפורומים שלנו בטאבלטים של Amazon Fire. הוא הבין מהר מאוד שהמנצל הזה היה הרבה יותר רחב בהיקפו מאשר רק טאבלטי Fire של אמזון.

לאחר מעט בדיקות מחברי XDA דיפלומטיים וחברי קהילה אחרים, אושר כי ניצול זה עובד על מספר רב של שבבי MediaTek. המחבר מצהיר כי הניצול עובד על "כמעט כל שבבי ה-64 סיביות של MediaTek", והם מכנים במפורש את הדברים הבאים כפגיעים: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT679, MT679, MT679, MT6797 173, MT8176, MT8183, MT6580, ו MT6595. בגלל כמה ערכות שבבים של MediaTek הושפעו מהניצול הזה, הניצול קיבל את השם "MediaTek-su", או "MTK-su", בקיצור. ב-17 באפריל 2019, דיפלומטי פרסם שרשור שני שכותרתו "שורש טמפ' מדהים עבור MediaTek ARMv8" בפורום "פיתוח Android שונות". בשרשור זה, הוא שיתף סקריפט שמשתמשים יכולים להפעיל כדי להעניק להם גישת משתמש-על ב-Shell, כמו גם להגדיר SELinux, מודול ליבת לינוקס המספק בקרת גישה לתהליכים, ל"מתירנית" מאוד לא בטוחה מדינה. למשתמש לקבל גישת שורש ולהגדיר את SELinux כמתירנית במכשיר שלו קל להדהים לעשות: כל מה שאתה צריך לעשות הוא להעתיק את סקריפט לתיקיה זמנית, שנה ספריות למקום מאוחסן הסקריפט, הוסף הרשאות הפעלה לסקריפט ולאחר מכן הפעל את תַסרִיט.

חברי קהילת XDA אישרו שהניצול עבד לפחות במכשירים הבאים:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. סדרת הטאבלטים של אלבה
4. סדרת אלקטל 1 5033
5. אלקטל 1C
6. סדרת 5034 של אלקטל 3L (2018).
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. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. סדרה מבוססת ASUS ZenPad Z3xxM(F) MT8163
24. Barnes & Noble NOOK Tablet 7 אינץ' BNTV450 & BNTV460
25. Barnes & Noble NOOK Tablet 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. לבה איריס 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 (MTK)
56. סדרת LG Xpression Plus 2/K40 LMX420
57. Lumigon T3
58. Meizu M5c
59. מייזו M6
60. Meizu Pro 7 Plus
61. נוקיה 1
62. נוקיה 1 פלוס
63. נוקיה 3
64. נוקיה 3.1
65. נוקיה 3.1 פלוס
66. נוקיה 5.1
67. Nokia 5.1 Plus/X5
68. Onn 7 אינץ' טאבלט אנדרואיד
69. סדרת טאבלטים Onn 8 אינץ' ו-10 אינץ' (MT8163)
70. OPPO A5s
71. סדרת OPPO F5/A73 -- אנדרואיד 8.x בלבד
72. סדרת OPPO F7 -- אנדרואיד 8.x בלבד
73. סדרת OPPO F9 - אנדרואיד 8.x בלבד
74. Oukitel K12
75. Protruly 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. וויקו 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+) ו חברי הקהילה של סמסונג, XDA גילו ש-MediaTek-su עובד לעתים קרובות יותר מאשר לא כאשר מנסים על מכשירים עם מושפעים ערכות שבבים. על פי מכשירי XDA, דיפלומטי, Vivo, Huawei/Honor, OPPO וסמסונג "משתמשים בשינויי ליבה כדי להרתיע גישה לשורש באמצעות exploits", כלומר המפתח יצטרך לחפור בקוד המקור של הליבה של מכשירים אלה כדי ליצור "גרסאות מותאמות" של לְנַצֵל. זה לא היה שווה את המאמץ הנוסף, אז המפתח בחר שלא להוסיף תמיכה למכשירים אלה למרות ש"בתיאוריה" הניצול עדיין יכול לעבוד.

נכון לעכשיו, זה אמור להיות ברור שהניצול הזה משפיע על מספר רב של מכשירים בשוק. שבבי MediaTek מניעים מאות דגמי סמארטפונים תקציביים ובינוניים, טאבלטים זולים ומחוץ למותג ממירים, רובם נמכרים ללא ציפייה לעדכונים בזמן מהיצרן. לכן, מכשירים רבים שעדיין מושפעים מ-MediaTek-su לא יקבלו תיקון במשך שבועות או חודשים לאחר החשיפה של היום, אם הם יקבלו כזה בכלל. אז מה גורם ל-MediaTek-su להרוויח את החומרה ה"קריטית" שלו עם א CVSS v3.0 ציון של 9.3?

מדוע MTK-su הוא פגיעות אבטחה קריטית

כדי להדגיש, הדרך האופיינית להשיג גישת שורש במכשיר אנדרואיד היא תחילה לפתוח את נעילה של טוען האתחול, אשר משבית את האימות של מחיצת האתחול. לאחר ביטול הנעילה של טוען האתחול, המשתמש יכול להציג בינארי של משתמש-על למערכת וגם אפליקציית ניהול משתמש-על כדי לשלוט לאילו תהליכים יש גישה לשורש. ביטול נעילת טוען האתחול משבית בכוונה את אחת מתכונות האבטחה המרכזיות במכשיר, וזו הסיבה שהמשתמש צריך אפשר במפורש לזה לקרות על ידי הפעלת החלפת מצב באפשרויות המפתחים ולאחר מכן הוצאת פקודת ביטול נעילה ל- טוען אתחול. עם MediaTek-su, לעומת זאת, המשתמש לא צריך לבטל את נעילת טוען האתחול כדי לקבל גישת שורש. במקום זאת, כל מה שהם צריכים לעשות הוא להעתיק סקריפט למכשיר שלהם ולהפעיל אותו במעטפת. המשתמש הוא לא היחיד שיכול לעשות זאת. כל אפליקציה בטלפון שלך יכולה להעתיק את הסקריפט של MediaTek-su לספרייה הפרטית שלהם ואז להפעיל אותו כדי לקבל גישת שורש במעטפת. למעשה, חבר XDA דיפלומטי מדגיש אפשרות זו בשרשור הפורום שלהם כאשר הם מציעים קבוצה חלופית של הוראות באמצעות ה- אמולטור מסוף לאפליקציית אנדרואיד אוֹ טרמוקס ולא ADB.

עם גישת שורש, מודל האבטחה של אנדרואיד בעצם מתפרק. לדוגמה, הרשאות הופכות חסרות משמעות בהקשר של שורש מכיוון שאפליקציה עם גישה למעטפת שורש יכולה להעניק לעצמה כל הרשאה שהיא רוצה. יתר על כן, עם מעטפת שורש, כל מחיצת הנתונים - כולל קבצים המאוחסנים בספריות הנתונים הפרטיות של יישומים לא נגישות בדרך כלל - נגישה. אפליקציה עם שורש יכולה גם להתקין בשקט כל אפליקציה אחרת שהיא רוצה ברקע ואז להעניק להם את כל ההרשאות שהם צריכים כדי להפר את הפרטיות שלך. לפי XDA Recognized Developer topjohnwu, אפליקציה זדונית יכולה אפילו "להחדיר קוד ישירות ל-Zygote באמצעות ptrace", מה שאומר שאפליקציה רגילה במכשיר שלך עלולה להיחטף כדי לבצע את הצעת התוקף. דוגמאות אלו נוגעות רק לכמה דרכים שבהן אפליקציה יכולה להפר את האמון שלך ברקע ללא ידיעתך. עם זאת, אפליקציות זדוניות עלולות לזרוע הרס במכשיר שלך מבלי להסתיר את מה שהם עושים. תוכנת כופר, למשל, היא מְאוֹד חזק עם גישה לשורש; אם לא תשלם, אפליקציית תוכנת כופר היפותטית יכולה באופן מוחלט ובלתי הפיך הפוך את המכשיר שלך לבלתי פעיל על ידי ניגוב כל המכשיר נקי.

ה"חולשה" היחידה ב-MediaTek-su היא שהיא מעניקה לאפליקציה גישת שורש "זמנית" בלבד, מה שאומר שתהליך מאבד גישת משתמש-על לאחר אתחול מחדש של המכשיר. יתר על כן, במכשירים המריצים אנדרואיד 6.0 מרשמלו ומעלה, נוכחות של אתחול מאומת ו-dm-verity לחסום שינויים למחיצות לקריאה בלבד כמו מערכת וספק. עם זאת, שני הגורמים הללו הם לרוב רק מכשולים למודדים בפורומים שלנו ולא לשחקנים זדוניים. כדי להתגבר על המגבלה של שורש זמני, אפליקציה זדונית יכולה פשוט להריץ מחדש את סקריפט MediaTek-su בכל אתחול. מצד שני, אין צורך להתגבר על dm-verity מכיוון ששינויים קבועים במערכת או במחיצות הספק לא יעניינו את רוב מחברי התוכנה הזדונית; אחרי הכל, יש כבר טונות של דברים שאפליקציה זדונית יכולה לעשות עם מעטפת שורש.

אם אתה תוהה ברמה הטכנית מה MediaTek-su מנצל, MediaTek שיתפה איתנו את התרשים שלהלן שמסכם את נקודת הכניסה. הפגם כנראה קיים באחד ממנהלי ההתקן של Linux Kernel של MediaTek הנקרא "CMDQ". התיאור קובע כי "על ידי ביצוע IOCTL פקודות בצומת התקן CMDQ", תוקף מקומי יכול "לקרוא/לכתוב באופן שרירותי זיכרון פיזי, לזרוק את טבלת סמלי הליבה ל- מאגר DMA שהוקצה מראש, [וגם] לתפעל את מאגר ה-DMA כדי לשנות את הגדרות הליבה כדי להשבית את SELinux ולהסלים ל-'root' זְכוּת."

לפי התרשים ש-MediaTek שיתפה איתנו, פגיעות זו משפיעה על מכשירי MediaTek עם גרסאות Linux Kernel 3.18, 4.4, 4.9 או 4.14 עם גרסאות אנדרואיד 7 Nougat, 8 Oreo או 9 Pie. הפגיעות אינה ניתנת לניצול במכשירי MediaTek המריצים אנדרואיד 10, ככל הנראה, מכיוון ש"הרשאת הגישה של CMDQ צמתי מכשיר נאכף גם על ידי SELinux." הפחתה זו מגיעה ככל הנראה מעדכון ל-BSP של MediaTek ולא מאנדרואיד עצמו. ההפחתה היחידה של אנדרואיד 10 עבור פגיעות זו היא שלה הגבלה על אפליקציות המבצעות קבצים בינאריים בספריית הבית שלהם; עם זאת, כפי ש-XDA Recognized Developer topjohnwu מציין, אפליקציה זדונית יכולה פשוט להריץ את קוד MediaTek-su בספרייה דינמית.

למרות ש-MediaTek תיקנה בעיה זו בכל ערכות השבבים המושפעות, הן לא יכולות להכריח יצרניות מכשירים ליישם את התיקונים. MediaTek אמרו לנו שהיו להם תיקונים מוכנים כל הדרך במאי 2019. אמזון, באופן לא מפתיע, תיקנה מיד את הבעיה במכשיריה לאחר שהודעו להם. עם זאת, 10 חודשים חלפו מאז ש-MediaTek העמידה תיקון לרשות השותפים שלה, ובכל זאת במרץ 2020, עשרות יצרני OEM לא תיקנו את המכשירים שלהם. רוב המכשירים המושפעים נמצאים במהדורות אנדרואיד ישנות יותר עם רמות תיקון אבטחה מיושנות של אנדרואיד (SPLs), ומצב העדכונים גרוע עוד יותר כשחושבים על מאות של דגמי מכשירים פחות מוכרים המשתמשים בשבבי MediaTek אלה. ל- MediaTek יש א רְצִינִי בעיה על ידיה כאן, אז הם פנו לגוגל לעזרה.

שלא כמו MediaTek, גוגל פחית לאלץ יצרני OEM לעדכן את המכשירים שלהם הסכמי רישיון או מונחי תוכנית (כגון Android One). כדי ש-OEM יצהיר שמכשיר תואם לרמת תיקון האבטחה של 2020-03-05 (SPL), המכשיר חייב לכלול את כל המסגרת, ליבת לינוקס ותיקוני מנהלי התקנים רלוונטיים של ספק בעלון האבטחה של אנדרואיד מרץ 2020, הכולל תיקון עבור CVE-2020-0069, או MediaTek-su. (נראה שגוגל למעשה לא אוכפת את זה יצרני OEM למעשה ממזגים את כל התיקונים עם זאת, כאשר מכריזים על SPL מסוים.) כעת, כאשר עלון מרץ 2020 יצא, הסיפור הזה אמור להסתיים, נכון? למרבה הצער, אנחנו צריכים גם להחזיק את הרגליים של גוגל לאש בגלל גרירת הרגליים שלהם בשילוב הטלאים.

הפגם בתהליך תיקון האבטחה

במקרה שזה לא ברור כבר, לא כל פגיעות אבטחה צריכה להיגמר בעלון אבטחה של אנדרואיד. נקודות תורפה רבות מתגלות ומתוקנות על ידי ספקים מבלי שהן מופיעות אי פעם בעלון החודשי. MediaTek-su היה צריך להיות אחד מהם, אבל מסיבות מרובות, כמה יצרני OEM לא הצליחו לשלב את התיקונים שמציעה MediaTek. (יש הרבה סיבות אפשריות לכך, החל מחוסר משאבים ועד להחלטות עסקיות ועד לכשל בתקשורת). הצהיר ש-MediaTek "פנתה ל-Google" לעזרה, זה רומז ש-MediaTek ביקשה עזרה מגוגל באופן אקטיבי כדי לגרום ליצרני OEM לתקן סוף סוף את מכשירים. עם זאת, אולי זה לא היה המקרה בפועל. אני מבין שגוגל לא הייתה מודעת ל-MediaTek-su עד שזה הועלה אגב בדו"ח אבטחה מאת TrendMicro פורסם ב-6 בינואר 2020. בדוח, TrendMicro תיעד אַחֵר פגיעות אבטחה, המכונה "שימוש-אחרי-ללא בדרייבר של קלסר"פגיעות, שניצלה באופן פעיל בטבע. TrendMicro ציין כיצד שלוש אפליקציות זדוניות השיגו גישה לשורש באמצעות אחת משתי שיטות, או הפגיעות "שימוש לאחר-חופשי במנהל התקן קלסר" או MediaTek-su.

בקוד ש TrendMicro משותף, אנו יכולים לראות בבירור כיצד האפליקציות הזדוניות כוונו לדגמי מכשירים ספציפיים (למשל. Nokia 3, OPPO F9 ו-Redmi 6A) ושימוש ב-MediaTek-su עליהם.

אני לא יכול לדבר בשם TrendMicro, אבל נראה שהם לא היו מודעים לכך ש-MediaTek-su הוא ניצול שטרם תוקן. ההתמקדות שלהם הייתה בניצול "השימוש-ללא שימוש ב-Binder Driver", אחרי הכל, ונראה שהגילוי של השימוש ב-MediaTek-su היה מחשבה שלאחר מכן. (אני בטוח שאם TrendMicro היו מודעים למצב סביב MediaTek-su, הם היו מתאמים את מאמצי החשיפה שלהם עם גוגל.) הודענו רק על הניצול הזה בעצמנו ב-5 בפברואר 2020, ואחרי שחקרנו בעצמנו כמה זה גרוע, יצרנו קשר עם גוגל בקשר לזה ב-7 בפברואר, 2020. גוגל הייתה כל כך מודאגת מההשלכות של פרסום MediaTek-su שהם ביקשו מאיתנו לדחות את פרסום הסיפור הזה עד היום. לאחר ששקלנו את הנזק הבלתי הפיך שיכול להיגרם למשתמשים הממוקדים באמצעות תוכנות זדוניות MediaTek-su, הסכמנו לעצור את הסיפור הזה עד להכרזה על אנדרואיד מרץ 2020 עלון אבטחה. ובכל זאת, בהתחשב בכמה זמן ייקח להרבה מכשירים לקבל את עדכון האבטחה האחרון, אם אי פעם קבל את זה בכלל, בטח יהיו המון מכשירים שעדיין פגיעים ל-MediaTek-su כמה חודשים מ עַכשָׁיו. זה אמור להיות מחריד לכל מי שיש לו מכשיר פגיע.

למרות שפגיעת חומרה חמורה מאוד ו"קריטית" זו מנוצלת באופן פעיל בטבע, גוגל בלבד הכנס את התיקון לבעיה זו בעלון מרץ 2020, שהוא כחודשיים לאחר שנודע להם על נושא. אמנם גוגל מודיעה לשותפי האנדרואיד שלה על עלון האבטחה האחרון של אנדרואיד 30 ימים שלמים לפני שהעלון מתפרסם (כלומר. יצרני ציוד מקורי הודעו על מה שיש בעלון מרץ 2020 בתחילת פברואר 2020), גוגל יכולה, ולעתים קרובות עושה, לעדכן את העלון עם שינויים או תיקונים חדשים. הסיבה שגוגל לא בחרה לזרז את הכללת תיקון לבעיה כה רצינית היא מעבר לי, במיוחד כאשר ל-MediaTek היה תיקון לזה לפני 10 חודשים. אם באג כזה היה מתגלה במכשירים של אפל, אין לי ספק שהם היו מוציאים תיקון הרבה הרבה יותר מהר. גוגל בעצם התבססה על ההימור המסוכן ש-MediaTek-su תישאר בפרופיל נמוך לכאורה כפי שכבר היה עד לעליון מרץ 2020. למרות שנראה שלגוגל התמזל מזל בהקשר זה, אין לנו מושג כמה מחברי תוכנות זדוניות כבר יודעים על הניצול. אחרי הכל, זה כבר יושב בשרשור אקראי בפורום XDA עבור כמעט שנה שלמה.

יש עוד מפלגה אחת במחדל הזה שלא התייחסתי אליו הרבה, והוא מחבר הניצול, דיפלומטי חבר XDA. לזכותו ייאמר, שאני לא חושב שהייתה לו כוונה זדונית בפרסום MediaTek-su. אנו יכולים לאתר בבירור את מקור הניצול לרצון הדיפלומטי לשנות את הטאבלטים של Amazon Fire. דיפלומטי אומר לי שהמטרה העיקרית שלו בפיתוח שיטת השורש הזו הייתה לעזור לקהילה. התאמה אישית של המכשיר שלך היא מה שמעניין XDA, והמאמצים הדיפלומטיים בקהילה הם מה שאנשים נהנים בפורומים. למרות שסירובו של דיפלומטי לפתוח את הפרויקט בקוד פתוח מעורר כמה חששות, הוא מסביר שהוא רצה שהקהילה תהנה מזה עם גישה שורשית כמה שיותר זמן. כשפניתי לראשונה לדיפלומטי, הוא גם הצהיר שהוא בשיתוף פעולה עם כמה שותפים שמנעו ממנו לשתף את קוד המקור והמחקר של הפרויקט. למרות שלא הצלחתי לקבל פרטים נוספים על שיתוף הפעולה הזה, אני תוהה אם דיפלומטי היה בוחר לצאת לציבור עם הניצול הזה אם MediaTek הציעה תוכנית פרס באג. אני לא יכול לדמיין שפגיעות בסדר גודל כזה לא תשלם סכום כסף נכבד אם ל-MediaTek באמת הייתה תוכנית כזו. דיפלומטי טוען שהניצול הזה היה אפשרי מאז ערכת השבבים MediaTek MT6580 המאוחרת של 2015, אז צריך לתהות אם דיפלומטי הוא בכלל האדם הראשון שמצא את הניצול הזה. הוא אומר לי שלא היה לו מושג ש-MediaTek-su מנוצל באופן פעיל עד לפרסום המאמר הזה.

אם אתה רוצה לבדוק אם המכשיר שלך פגיע ל-MediaTek-su, הפעל ידנית את הסקריפט שפורסם על ידי XDA Member diplomatic בשרשור זה בפורום XDA. אם תזין מעטפת שורש (תדע מתי הסמל משתנה מ-$ ל-#), אז תדע שהניצול עובד. אם זה עובד, תצטרך לחכות ליצרן המכשיר שלך כדי להפיץ עדכון שמתקן את MediaTek-su. אם המכשיר שלך מדווח על רמת תיקון האבטחה של 2020-03-05, שהיא ה-SPL האחרון של מרץ 2020, אז הוא כמעט בוודאות מוגן מפני MediaTek-su. אחרת, תצטרך פשוט לבדוק אם המכשיר שלך פגיע.

---

עדכון 1 (3/2/2020 בשעה 21:45 EST): מאמר זה עודכן כדי להבהיר שחבר XDA דיפלומטי היה מודע למעשה להיקף הפגיעות הזו ברגע שהוא גילה אותו בפברואר 2019, אך הוא לא היה מודע לשימוש בטבע עד לפרסום זה מאמר. תיקנו גם את הניסוח שלנו לגבי סיבה אחת מדוע דיפלומטי סירב לשתף את קוד המקור של הפרויקט.