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 रिपॉजिटरी

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

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

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

ये मूल शोध के लिए उपयोग किए गए डिवाइस के विवरण हैं, न कि सभी भेद्य या ठीक किए गए 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

पहली तीन पंक्तियाँ parameter प्राप्ति, group-creation पथ में प्रवेश, और एक सफल callback दर्शाती हैं। अंतिम पंक्ति true की प्राप्ति दर्शाती है; इसमें removal-success callback शामिल नहीं है। PID 30288 दिखाई देता है, लेकिन इस अंश में process UID और caller पहचान दर्ज नहीं हैं।

प्रभावित दायरा

मेरा पुनरुत्पादन ऊपर दिए गए PEAQ AI PONT कॉन्फ़िगरेशन तक सीमित है। MediaTek का बुलेटिन उस डिवाइस से परे प्रभावित chipsets को सूचीबद्ध करता है; आधिकारिक दायरे के लिए विक्रेता की CVE-2026-20516 प्रविष्टि देखें। Chipset का शामिल होना यह नहीं बताता कि किसी विशेष retail TV को उसका OEM firmware fix प्राप्त हुआ है या नहीं।

मूल शोध के दौरान package और APK नामकरण ने एक साझा MediaTek/Changhong component का संकेत दिया। केवल वह अवलोकन प्रत्येक MediaTek-आधारित TV पर इस exported सेवा की उपस्थिति स्थापित नहीं करता है।

उपचार

डिवाइस स्वामियों को अपने TV निर्माता से प्रासंगिक fix वाला firmware प्राप्त करना चाहिए। MediaTek fixes को ALPS11060069 / DTV04881615 के रूप में पहचानता है; इस लेख के भाग के रूप में कोई भी ठीक किया गया PEAQ firmware संस्करण सत्यापित नहीं किया गया है।

Component के maintainers के लिए, यदि बाहरी callers अनावश्यक हैं तो android:exported="false" के साथ बाहरी exposure हटाएँ। यदि विश्वसनीय cross-application पहुँच आवश्यक है, तो सेवा को उपयुक्त signature-level permission से सुरक्षित करें और receiver स्थिति बदलने से पहले प्राधिकरण लागू करें। सभी entry points और lifecycle side effects की समीक्षा करें, जिसमें संरक्षित settings writes भी शामिल हैं।

ये विश्लेषण से hardening सिफारिशें हैं, अप्रकाशित विक्रेता patch का विवरण नहीं। परिणाम को एक सामान्य एप्लिकेशन UID के साथ-साथ वैध casting clients का उपयोग करके भी सत्यापित करें।

प्रकटीकरण समयरेखा और श्रेय

Davide Di Matteo द्वारा खोजा और रिपोर्ट किया गया। प्रकटीकरण के समन्वय और अपने सितंबर 2026 श्रेय में शोध को स्वीकार करने के लिए MediaTek को धन्यवाद।

संदर्भ

• MediaTek — September 2026 Security Bulletin
• MediaTek — Security Acknowledgements
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516