dingo97/cve-2026-20516اكتب تقريرًا وإثبات مفهوم ADB لـ CVE-2026-20516، وهو خلل "الوكيل المربك" في MediaTek Android TV MiracastService يسمح بتغييرات حالة Wi-Fi Direct المحلية.
البحث والإفصاح من قبل Davide Di Matteo (@Dingo97).
هذا أول CVE يُنسب إليّ. اكتشفت خدمة Miracast مُصدَّرة بشكل غير صحيح وذات صلاحيات نظام أثناء بحثي على جهاز PEAQ Android TV. يمكن للمُستدعي تمرير intent extra يجعل الخدمة تغيّر حالة Wi-Fi Direct باستخدام صلاحياتها الخاصة.
نشرت MediaTek المشكلة في نشرة الأمان لشهر سبتمبر 2026 وتنسب الفضل إلى Davide Di Matteo في شكر وتقدير الأمان. يُنشر هذا التقرير وإعادة الإنتاج الأصلية عبر ADB بعد الإفصاح المنسّق والحصول على إذن من المورّد.
اقرأ على موقعي · مستودع GitHub
| الحقل | القيمة |
|---|---|
| CVE | CVE-2026-20516 |
| المكوّن | com.mediatek.androidbox.MiracastService |
| خطورة المورّد | متوسطة |
| CVSS v3.1 المنشور | 5.5 — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (Tenable) |
| الضعف الرسمي | CWE-926: التصدير غير الصحيح لمكوّنات تطبيقات Android |
| الآلية | كوسيط مُضلَّل / غياب ضبط الوصول |
| التأثير الموصوف من المورّد | حجب خدمة محلي عبر تصعيد صلاحيات محتمل |
| متطلبات الهجوم | تنفيذ كود محلي بصلاحيات المستخدم؛ لا يتطلب تفاعل المستخدم |
| معرّفات التصحيح | ALPS11060069 / DTV04881615 |
| مشكلة MediaTek | MSV-7882 |
| نشر المورّد | 7 سبتمبر 2026 |
| نشر التقرير | 11 سبتمبر 2026 |
التأثير ومعرّفات التصحيح ومتطلبات الهجوم المحلي موثّقة في سجل CVE. الدرجة الرقمية والمتجه أعلاه هما ما نشرته Tenable. وهما يحلّان محل التقييم الأولي 5.1 في تقريري الأصلي. يصف CWE-284 (ضبط وصول غير صحيح) وCWE-441 (كوسيط مُضلَّل) التحليل الأصلي؛ بينما تصنّف MediaTek المشكلة على أنها CWE-926.
| الحقل | القيمة |
|---|---|
| الجهاز | PEAQ Smart TV، الطراز AI PONT |
| الشركة المصنّعة / المنصة | Changhong / MediaTek |
| نظام التشغيل | Android TV 11 |
| مستوى تصحيح أمان Android | يونيو 2025 |
| البناء | RTMA.250416.192 |
| النواة | 4.19.116++ (#1 Sat Aug 23 09:58:11 CST 2025) |
| البرنامج | V03.06037 |
| الحزمة | com.mediatek.androidbox |
| APK | WFDSinkTest_CH.apk |
| إصدار التطبيق | 1.0.0.16 |
| UID المشترك المُعلن | android.uid.system |
هذه تفاصيل الجهاز المستخدم في البحث الأصلي، وليست قائمة بجميع إصدارات البرامج الثابتة المصابة أو المُصحّحة.
يُظهر تحليل المانيفست المُسجَّل في التقرير الأصلي أن MiracastService مُصدَّرة بـ android:exported="true"، دون إذن يحمي الوصول إلى الخدمة. ويُعلن التطبيق android:sharedUserId="android.uid.system".
يقرأ onStartCommand() الخاص بالخدمة قيمة intent extra المنطقية screen_share دون التحقق مما إذا كان المُستدعي مُصرَّحًا له بالتحكم في Miracast. ثم تُنفّذ الخدمة عمليات في سياقها ذي الصلاحيات. هذا هو الوسيط المُضلَّل: المُستدعي يوفّر الطلب، بينما توفّر خدمة النظام الصلاحية.
في التنفيذ المُحلَّل، يمكن لمسار screen_share=false استدعاء WifiP2pManager.createGroup(). الاستدعاء مشروط: يجب أن تكون مشاركة الشاشة معطّلة في حالة الخدمة، ويجب أن يكون Wi-Fi P2P مُفعَّلًا، ويجب ألا توجد مجموعة بالفعل. لا ينبغي تفسير اسم المتغير المنطقي كبيان مباشر حول ما إذا كانت المجموعة ستُنشأ أو ستُزال.
يسجّل التقرير أيضًا كتابة إلى Settings.Global.putInt(..., "miracast_enable", 1) في onCreate(). لذا فإن تفعيل دورة حياة الخدمة قد يتسبب في كتابة إعدادات محمية عبر الخدمة. هذه ملاحظة من تحليل التنفيذ؛ ومقتطف السجل أدناه لا يُثبت تلك الكتابة بشكل مستقل.
تعتمد فحوصات الأذونات ذات الصلة على إطار عمل Android وبناء الشركة المصنّعة. القضية الأساسية هي غياب التصريح عند حدود الخدمة المُصدَّرة، وليس الادعاء بأن كل إصدار من Android يفرض مجموعة أذونات متطابقة لـ Wi-Fi Direct.
تصف MediaTek خطر حجب خدمة محلي. على التلفاز المُختبر، تُظهر جلسة ADB المُسجَّلة أن الخدمة تقبل screen_share=false وتنجح في إنشاء مجموعة Wi-Fi Direct. يمكن للتغييرات غير المتوقعة في هذه الحالة أن تتعارض مع الاستخدام المشروع لـ Miracast وقد تكشف عن حالة مستقبِل لم يطلبها المستخدم.
المكوّن المُصدَّر وغياب ضبط الوصول يدعمان مسار هجوم عبر تطبيق محلي في التحليل الأصلي. يعمل ADB shell بهوية Android shell، وليس بمعرّف تطبيق عادي. وبالتالي، تُظهر هذه الأوامر والسجلات سلوك الخدمة من ADB؛ لكنها لا تُثبت بحد ذاتها التنفيذ من تطبيق بلا أذونات. لا يتضمن هذا المستودع إعادة إنتاج مُختبرة بشكل منفصل عبر تطبيق.
لا يُثبت المقتطف تنفيذ كود عشوائي، أو صدفة root، أو اتصالًا مكتملًا من جهاز قريب، أو إزالة ناجحة للمجموعة. لا يحصل المُستدعي على UID النظام الخاص بالخدمة؛ بل يحمل الخدمة على التصرف نيابة عنه.
ما يلي هو إعادة الإنتاج اليدوية من التقرير الأصلي. تُغيّر حالة Miracast وتُوقف حزمة المستقبِل قسريًا. سجّل حالة البث الحالية قبل تشغيلها.
في الطرفية الأولى:
adb logcat | grep -i -E 'screen_share|createGroup|removeGroup'
في الطرفية الثانية:
adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true
sleep 3
adb shell am force-stop com.mediatek.androidbox
sleep 2
هذا هو تسلسل إعادة الضبط المستخدم في إعادة الإنتاج الأصلية. لا يضمن الإيقاف القسري للحزمة أن نظام Wi-Fi الفرعي في Android قد أزال مجموعة موجودة. إذا استمرت المجموعة، فأعد ضبط المستقبِل عبر عناصر التحكم في التلفاز وتحقق من حالته قبل إعادة المحاولة.
adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share false
ابحث عن Enter createGroup متبوعة بـ createGroup success. إذا ظهر Received screen_share tag فقط، فقد تمت معالجة الـ intent، لكن إنشاء المجموعة لم يُثبَت: تحقق من الشروط المسبقة الموصوفة أعلاه.
adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true
يُرسل هذا قيمة التنظيف المستخدمة في التقرير الأصلي. تحقق من أن البث وWi-Fi Direct قد عادا إلى الحالة المقصودة باستخدام عناصر التحكم في التلفاز. مجرد استلام الـ intent ليس دليلًا على نجاح التنظيف؛ أعد المستقبِل يدويًا إذا لزم الأمر.
التُقط مقتطف logcat التالي على التلفاز المُختبر في 10 مارس 2026. وهو دليل من البحث الأصلي، وليس اختبارًا جديدًا أُجري لهذا المنشور.
03-10 19:40:27.458 30288 30288 I MiracastService: Received screen_share tag: false
03-10 19:40:27.460 30288 30288 D MiracastService: Enter createGroup
03-10 19:40:27.530 30288 30288 D MiracastService: createGroup success
03-10 19:41:19.148 30288 30288 I MiracastService: Received screen_share tag: true
تُظهر الأسطر الثلاثة الأولى استلام المعامل، والدخول إلى مسار إنشاء المجموعة، واستدعاءً ناجحًا. ويُظهر السطر الأخير استلام true؛ لكنه لا يتضمن استدعاءً ناجحًا للإزالة. يظهر PID 30288، لكن UID العملية وهوية المُستدعي غير مُسجَّلين في هذا المقتطف.
يقتصر إعادة إنتاجي على تكوين PEAQ AI PONT أعلاه. تُدرج نشرة MediaTek شرائح متأثرة تتجاوز ذلك الجهاز؛ راجع مدخل CVE-2026-20516 لدى المورّد للنطاق المرجعي. لا يحدد إدراج الشريحة ما إذا كان تلفاز تجزئة معيّن قد تلقّى إصلاح البرنامج الثابت من الشركة المصنّعة.
أشارت تسمية الحزمة وAPK إلى مكوّن مشترك بين MediaTek وChanghong أثناء البحث الأصلي. لكن هذه الملاحظة وحدها لا تُثبت وجود هذه الخدمة المُصدَّرة على كل تلفاز قائم على MediaTek.
يجب على مالكي الأجهزة الحصول على برنامج ثابت يحتوي على الإصلاح ذي الصلة من الشركة المصنّعة للتلفاز. تُحدد MediaTek الإصلاحات بـ ALPS11060069 / DTV04881615؛ ولم يتم التحقق من أي إصدار برنامج ثابت مُصحَّح لـ PEAQ كجزء من هذا التقرير.