CVE-2026-20516: MiracastService كوسيط مُضلَّل على Android TV

البحث والإفصاح من قبل Davide Di Matteo (@Dingo97).

هذا أول CVE يُنسب إليّ. اكتشفت خدمة Miracast مُصدَّرة بشكل غير صحيح وذات صلاحيات نظام أثناء بحثي على جهاز PEAQ Android TV. يمكن للمُستدعي تمرير intent extra يجعل الخدمة تغيّر حالة Wi-Fi Direct باستخدام صلاحياتها الخاصة.

نشرت MediaTek المشكلة في نشرة الأمان لشهر سبتمبر 2026 وتنسب الفضل إلى Davide Di Matteo في شكر وتقدير الأمان. يُنشر هذا التقرير وإعادة الإنتاج الأصلية عبر ADB بعد الإفصاح المنسّق والحصول على إذن من المورّد.

اقرأ على موقعي · مستودع GitHub

ملخص الثغرة

التأثير ومعرّفات التصحيح ومتطلبات الهجوم المحلي موثّقة في سجل CVE. الدرجة الرقمية والمتجه أعلاه هما ما نشرته Tenable. وهما يحلّان محل التقييم الأولي 5.1 في تقريري الأصلي. يصف CWE-284 (ضبط وصول غير صحيح) وCWE-441 (كوسيط مُضلَّل) التحليل الأصلي؛ بينما تصنّف MediaTek المشكلة على أنها CWE-926.

البيئة المُختبرة

هذه تفاصيل الجهاز المستخدم في البحث الأصلي، وليست قائمة بجميع إصدارات البرامج الثابتة المصابة أو المُصحّحة.

السبب الجذري

يُظهر تحليل المانيفست المُسجَّل في التقرير الأصلي أن 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 النظام الخاص بالخدمة؛ بل يحمل الخدمة على التصرف نيابة عنه.

إثبات المفهوم

المتطلبات الأساسية

• البرنامج الثابت المصاب المُختبر، أو بناء مكافئ يُصدّر نفس المكوّن.
• ADB مثبّت على المضيف واتصال تصحيح مُصرَّح به بتلفاز تملكه أو مُصرَّح لك باختباره.
• Wi-Fi وWi-Fi Direct متاحان على التلفاز.
• طرفيتان. تستخدم أوامر المضيف أدناه صدفة POSIX، مثل Bash أو WSL مع إمكانية الوصول إلى ADB.

ما يلي هو إعادة الإنتاج اليدوية من التقرير الأصلي. تُغيّر حالة Miracast وتُوقف حزمة المستقبِل قسريًا. سجّل حالة البث الحالية قبل تشغيلها.

1. مراقبة الخدمة

في الطرفية الأولى:

adb logcat | grep -i -E 'screen_share|createGroup|removeGroup'

2. تحضير حالة المستقبِل

في الطرفية الثانية:

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 قد أزال مجموعة موجودة. إذا استمرت المجموعة، فأعد ضبط المستقبِل عبر عناصر التحكم في التلفاز وتحقق من حالته قبل إعادة المحاولة.

3. طلب إنشاء المجموعة

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share false

ابحث عن Enter createGroup متبوعة بـ createGroup success. إذا ظهر Received screen_share tag فقط، فقد تمت معالجة الـ intent، لكن إنشاء المجموعة لم يُثبَت: تحقق من الشروط المسبقة الموصوفة أعلاه.

4. طلب التنظيف والتحقق من التلفاز

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 كجزء من هذا التقرير.

بالنسبة للقائمين على صيانة المكوّن، أزل التعرّض الخارجي باستخدام android:exported="false" إذا لم تكن المُستدعيات الخارجية ضرورية. إذا كان الوصول الموثوق بين التطبيقات مطلوبًا، فاحمِ الخدمة بإذن مناسب على مستوى التوقيع وفرض التصريح قبل تغيير حالة المستقبِل. راجع جميع نقاط الدخول والآثار الجانبية لدورة الحياة، بما في ذلك كتابات الإعدادات المحمية.

هذه توصيات تقوية من التحليل، وليست وصفًا لتصحيح المورّد غير المنشور. تحقق من النتيجة باستخدام UID تطبيق عادي وكذلك عملاء البث الشرعيين.

الجدول الزمني للإفصاح والفضل

اكتشفه وأبلغ عنه Davide Di Matteo. شكرًا لـ MediaTek على تنسيق الإفصاح والإشارة إلى البحث في اعتمادات سبتمبر 2026.

المراجع

• MediaTek — نشرة أمان سبتمبر 2026
• MediaTek — شكر وتقدير الأمان
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516