CVE-2026-20516: Android TV पर MiracastService confused deputy

Davide Di Matteo (@Dingo97) द्वारा शोध और प्रकटीकरण।

यह मेरा पहला श्रेय प्राप्त CVE है। PEAQ Android TV पर शोध करते समय मुझे एक अनुचित रूप से exported, system-privileged Miracast सेवा मिली। एक caller एक intent extra प्रदान कर सकता है जो सेवा को उसके स्वयं के privileges का उपयोग करके Wi-Fi Direct स्थिति बदलने के लिए प्रेरित करता है।

MediaTek ने इस समस्या को अपने सितंबर 2026 सुरक्षा बुलेटिन में प्रकाशित किया और अपने सुरक्षा आभार में Davide Di Matteo को श्रेय दिया। यह लेख और मूल ADB पुनरुत्पादन समन्वित प्रकटीकरण और विक्रेता की अनुमति के बाद प्रकाशित किए गए हैं।

मेरी वेबसाइट पर पढ़ें · GitHub रिपॉजिटरी

भेद्यता सारांश

Field	Value
CVE	CVE-2026-20516
Component	com.mediatek.androidbox.MiracastService
Vendor severity	Medium
Published 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)
Official weakness	CWE-926: Improper Export of Android Application Components
Mechanism	Confused deputy / missing access control
Vendor-described impact	Local denial of service through a possible escalation of privilege
Attack prerequisites	Local code execution with user privileges; no user interaction required
Patch identifiers	ALPS11060069 / DTV04881615
MediaTek issue	MSV-7882
Vendor publication	7 September 2026
Write-up publication	11 September 2026

प्रभाव, patch identifiers और स्थानीय हमले की पूर्वापेक्षाएँ CVE रिकॉर्ड में प्रलेखित हैं। ऊपर दिया गया संख्यात्मक स्कोर और वेक्टर Tenable द्वारा प्रकाशित हैं। वे मेरी मूल रिपोर्ट में प्रारंभिक 5.1 मूल्यांकन को प्रतिस्थापित करते हैं। CWE-284 (improper access control) और CWE-441 (confused deputy) मूल विश्लेषण का वर्णन करते हैं; MediaTek इस समस्या को CWE-926 के रूप में वर्गीकृत करता है।

परीक्षण किया गया वातावरण

Field	Value
Device	PEAQ Smart TV, model AI PONT
OEM / platform	Changhong / MediaTek
Operating system	Android TV 11
Android security patch level	June 2025
Build	RTMA.250416.192
Kernel	4.19.116++ (#1 Sat Aug 23 09:58:11 CST 2025)
Software	V03.06037
Package	com.mediatek.androidbox
APK	WFDSinkTest_CH.apk
Application version	1.0.0.16
Declared shared UID	android.uid.system

ये मूल शोध के लिए उपयोग किए गए डिवाइस के विवरण हैं, न कि सभी भेद्य या ठीक किए गए firmware संस्करणों की सूची।

मूल कारण

मूल रिपोर्ट में दर्ज manifest विश्लेषण दर्शाता है कि MiracastService को android:exported="true" के साथ exported किया गया है, बिना सेवा तक पहुँच की सुरक्षा करने वाली किसी permission के। एप्लिकेशन android:sharedUserId="android.uid.system" घोषित करता है।

सेवा का onStartCommand() boolean screen_share intent extra को पढ़ता है, बिना यह जाँचे कि caller Miracast को नियंत्रित करने के लिए अधिकृत है या नहीं। सेवा तब अपने स्वयं के privileged संदर्भ में संचालन करती है। यही confused deputy है: caller अनुरोध प्रदान करता है, जबकि system सेवा अधिकार प्रदान करती है।

विश्लेषित कार्यान्वयन में, screen_share=false पथ WifiP2pManager.createGroup() को कॉल कर सकता है। यह कॉल सशर्त है: सेवा की स्थिति में screen sharing अक्षम होना चाहिए, Wi-Fi P2P सक्षम होना चाहिए, और कोई group पहले से मौजूद नहीं होना चाहिए। boolean के नाम की व्याख्या इस बात के प्रत्यक्ष कथन के रूप में नहीं की जानी चाहिए कि कोई group बनाया या हटाया जाएगा या नहीं।

रिपोर्ट onCreate() में Settings.Global.putInt(..., "miracast_enable", 1) में एक write भी दर्ज करती है। इसलिए सेवा lifecycle को ट्रिगर करने से सेवा के माध्यम से एक संरक्षित settings write हो सकता है। यह कार्यान्वयन विश्लेषण से एक अवलोकन है; नीचे दिया गया log अंश उस write को स्वतंत्र रूप से प्रदर्शित नहीं करता है।

प्रासंगिक permission जाँचें Android framework और OEM build पर निर्भर करती हैं। मुख्य समस्या exported सेवा सीमा पर अनुपस्थित प्राधिकरण है, न कि यह दावा कि प्रत्येक Android संस्करण Wi-Fi Direct के लिए एक समान permission सेट लागू करता है।

प्रभाव और साक्ष्य की सीमाएँ

MediaTek स्थानीय denial-of-service जोखिम का वर्णन करता है। परीक्षण किए गए TV पर, दर्ज ADB सत्र दर्शाता है कि सेवा screen_share=false स्वीकार करती है और सफलतापूर्वक एक Wi-Fi Direct group बनाती है। इस स्थिति में अप्रत्याशित परिवर्तन वैध Miracast उपयोग में बाधा डाल सकते हैं और एक receiver स्थिति को उजागर कर सकते हैं जिसका उपयोगकर्ता ने अनुरोध नहीं किया था।

मूल विश्लेषण में exported component और अनुपस्थित access control एक स्थानीय-ऐप हमले के पथ का समर्थन करते हैं। ADB shell एक सामान्य एप्लिकेशन UID के रूप में नहीं, बल्कि Android shell पहचान के रूप में चलता है। परिणामस्वरूप, ये कमांड और log ADB से सेवा के व्यवहार को प्रदर्शित करते हैं; वे स्वयं, शून्य-permission एप्लिकेशन से निष्पादन सिद्ध नहीं करते हैं। इस रिपॉजिटरी में एक अलग से परीक्षण किया गया एप्लिकेशन-आधारित पुनरुत्पादन शामिल नहीं है।

यह अंश मनमाना code execution, एक root shell, किसी निकटवर्ती डिवाइस से पूर्ण कनेक्शन, या सफल group हटाने को स्थापित नहीं करता है। Caller सेवा का system UID प्राप्त नहीं करता है; यह सेवा को अपनी ओर से कार्य करने के लिए प्रेरित करता है।

Proof of concept

पूर्वापेक्षाएँ

• परीक्षण किया गया भेद्य firmware, या समान component को उजागर करने वाला समतुल्य build।
• होस्ट पर ADB स्थापित और आपके स्वामित्व वाले या परीक्षण के लिए अधिकृत TV से एक अधिकृत debugging कनेक्शन।
• TV पर Wi-Fi और Wi-Fi Direct उपलब्ध।
• दो टर्मिनल। नीचे दिए गए होस्ट कमांड एक POSIX shell का उपयोग करते हैं, उदाहरण के लिए Bash या ADB तक पहुँच वाला WSL।

निम्नलिखित मूल रिपोर्ट से मैनुअल पुनरुत्पादन है। यह Miracast स्थिति बदलता है और receiver package को force-stop करता है। इसे चलाने से पहले वर्तमान casting स्थिति रिकॉर्ड करें।

1. सेवा की निगरानी करें

पहले टर्मिनल में:

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

2. Receiver स्थिति तैयार करें

दूसरे टर्मिनल में:

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

यह मूल पुनरुत्पादन में उपयोग किया गया reset अनुक्रम है। एक package force-stop यह गारंटी नहीं देता कि Android Wi-Fi subsystem ने किसी मौजूदा group को हटा दिया है। यदि कोई group बना रहता है, तो TV के नियंत्रणों के माध्यम से receiver को reset करें और पुनः प्रयास करने से पहले उसकी स्थिति सत्यापित करें।

3. Group निर्माण का अनुरोध करें

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

Enter createGroup के बाद createGroup success देखें। यदि केवल Received screen_share tag दिखाई देता है, तो intent संसाधित किया गया था, लेकिन group निर्माण प्रदर्शित नहीं हुआ है: ऊपर वर्णित पूर्वापेक्षाओं की जाँच करें।

4. Cleanup का अनुरोध करें और TV सत्यापित करें

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

यह मूल रिपोर्ट में उपयोग किया गया cleanup मान भेजता है। TV के नियंत्रणों का उपयोग करके सत्यापित करें कि casting और Wi-Fi Direct इच्छित स्थिति में लौट आए हैं। केवल intent प्राप्त होना cleanup सफल होने का प्रमाण नहीं है; यदि आवश्यक हो तो receiver को मैन्युअल रूप से पुनर्स्थापित करें।

कैप्चर किया गया साक्ष्य

निम्नलिखित logcat अंश 10 मार्च 2026 को परीक्षण किए गए TV पर कैप्चर किया गया था। यह मूल शोध से साक्ष्य है, इस प्रकाशन के लिए किया गया नया परीक्षण नहीं।

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