CVE-2026-20516: Android TV의 MiracastService confused deputy

Davide Di Matteo (@Dingo97)의 연구 및 공개.

이것은 제가 처음으로 이름을 올린 CVE입니다. PEAQ Android TV를 연구하던 중 부적절하게 export된 시스템 권한 Miracast 서비스를 발견했습니다. 호출자는 intent extra를 제공하여 서비스가 자체 권한을 사용해 Wi-Fi Direct 상태를 변경하도록 만들 수 있습니다.

MediaTek은 이 문제를 2026년 9월 보안 공지에 게재하고 보안 감사 인정에서 Davide Di Matteo를 크레딧했습니다. 이 글과 원본 ADB 재현은 조정된 공개와 벤더의 허가에 따라 게시됩니다.

제 웹사이트에서 읽기 · GitHub 저장소

취약점 요약

영향, 패치 식별자 및 로컬 공격 전제 조건은 CVE 레코드에 문서화되어 있습니다. 위의 숫자 점수와 벡터는 Tenable이 게시한 것입니다. 이는 제 원본 보고서의 예비 5.1 평가를 대체합니다. CWE-284(부적절한 접근 제어)와 CWE-441(confused deputy)은 원본 분석을 설명하며, MediaTek은 이 문제를 CWE-926으로 분류합니다.

테스트 환경

이는 원본 연구에 사용된 기기의 세부 정보이며, 모든 취약하거나 수정된 펌웨어 버전의 목록이 아닙니다.

근본 원인

원본 보고서에 기록된 manifest 분석에 따르면 MiracastService는 android:exported="true"로 export되어 있으며, 서비스 접근을 보호하는 permission이 없습니다. 애플리케이션은 android:sharedUserId="android.uid.system"을 선언합니다.

서비스의 onStartCommand()는 호출자가 Miracast를 제어할 권한이 있는지 확인하지 않고 boolean screen_share intent extra를 읽습니다. 그런 다음 서비스는 자체 권한 컨텍스트에서 작업을 수행합니다. 이것이 confused deputy입니다: 호출자가 요청을 제공하고, 시스템 서비스가 권한을 제공합니다.

분석된 구현에서 screen_share=false 경로는 WifiP2pManager.createGroup()을 호출할 수 있습니다. 이 호출은 조건부입니다: 서비스 상태에서 화면 공유가 비활성화되어 있어야 하고, Wi-Fi P2P가 활성화되어 있어야 하며, 그룹이 이미 존재하지 않아야 합니다. boolean의 이름은 그룹이 생성되거나 제거될지에 대한 직접적인 진술로 해석되어서는 안 됩니다.

보고서는 또한 onCreate()에서 Settings.Global.putInt(..., "miracast_enable", 1)에 대한 쓰기를 기록합니다. 따라서 서비스 라이프사이클을 트리거하면 서비스를 통해 보호된 설정 쓰기가 발생할 수 있습니다. 이는 구현 분석에서의 관찰이며, 아래 로그 발췌는 해당 쓰기를 독립적으로 입증하지 않습니다.

관련 permission 검사는 Android 프레임워크와 OEM 빌드에 따라 다릅니다. 핵심 문제는 모든 Android 버전이 Wi-Fi Direct에 대해 동일한 permission 집합을 강제한다는 주장이 아니라, export된 서비스 경계에서 누락된 인가입니다.

영향 및 증거 경계

MediaTek은 로컬 서비스 거부 위험을 설명합니다. 테스트된 TV에서 기록된 ADB 세션은 서비스가 screen_share=false를 수락하고 Wi-Fi Direct 그룹을 성공적으로 생성하는 것을 보여줍니다. 이 상태의 예상치 못한 변경은 정당한 Miracast 사용을 방해할 수 있으며 사용자가 요청하지 않은 수신기 상태를 노출할 수 있습니다.

export된 구성 요소와 누락된 접근 제어는 원본 분석에서 로컬 앱 공격 경로를 뒷받침합니다. ADB shell은 일반 애플리케이션 UID가 아니라 Android shell identity로 실행됩니다. 결과적으로 이 명령과 로그는 ADB에서의 서비스 동작을 보여주지만, 그 자체로 zero-permission 애플리케이션에서의 실행을 입증하지는 않습니다. 이 저장소에는 별도로 테스트된 애플리케이션 기반 재현이 포함되어 있지 않습니다.

이 발췌는 임의 코드 실행, root shell, 근처 기기로부터의 완료된 연결 또는 성공적인 그룹 제거를 입증하지 않습니다. 호출자는 서비스의 시스템 UID를 획득하지 않으며, 서비스가 자신을 대신해 행동하도록 유도할 뿐입니다.

개념 증명

전제 조건

• 테스트된 취약한 펌웨어 또는 동일한 구성 요소를 노출하는 동등한 빌드.
• 호스트에 설치된 ADB 및 소유하거나 테스트 권한이 있는 TV에 대한 인가된 디버깅 연결.
• TV에서 사용 가능한 Wi-Fi 및 Wi-Fi Direct.
• 두 개의 터미널. 아래 호스트 명령은 POSIX shell, 예를 들어 Bash 또는 ADB에 접근할 수 있는 WSL을 사용합니다.

다음은 원본 보고서의 수동 재현입니다. 이는 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

이것은 원본 재현에서 사용된 리셋 시퀀스입니다. 패키지 강제 중지는 Android Wi-Fi 하위 시스템이 기존 그룹을 제거했음을 보장하지 않습니다. 그룹이 지속되면 TV의 컨트롤을 통해 수신기를 리셋하고 재시도하기 전에 상태를 확인하십시오.

3. 그룹 생성 요청

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

Enter createGroup 다음에 createGroup success가 나타나는지 확인하십시오. Received screen_share tag만 나타나면 intent는 처리되었지만 그룹 생성은 입증되지 않은 것입니다: 위에서 설명한 전제 조건을 확인하십시오.

4. 정리 요청 및 TV 확인

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

이것은 원본 보고서에서 사용된 정리 값을 전송합니다. TV의 컨트롤을 사용하여 캐스팅과 Wi-Fi Direct가 의도한 상태로 돌아왔는지 확인하십시오. intent 수신만으로는 정리가 성공했다는 증거가 되지 않습니다; 필요한 경우 수신기를 수동으로 복원하십시오.

캡처된 증거

다음 logcat 발췌는 2026년 3월 10일 테스트된 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

처음 세 줄은 파라미터 수신, 그룹 생성 경로 진입 및 성공적인 콜백을 보여줍니다. 마지막 줄은 true의 수신을 보여줍니다; 제거 성공 콜백은 포함하지 않습니다. PID 30288이 보이지만, 프로세스 UID와 호출자 신원은 이 발췌에 기록되어 있지 않습니다.

영향 범위

제 재현은 위의 PEAQ AI PONT 구성으로 제한됩니다. MediaTek의 공지는 해당 기기 외의 영향을 받는 칩셋을 나열합니다; 권위 있는 범위는 벤더의 CVE-2026-20516 항목을 참조하십시오. 칩셋 포함은 특정 소매 TV가 OEM 펌웨어 수정을 받았는지 여부를 식별하지 않습니다.

패키지와 APK 이름은 원본 연구 중에 공유 MediaTek/Changhong 구성 요소를 시사했습니다. 그 관찰만으로는 모든 MediaTek 기반 TV에 이 export된 서비스가 존재한다는 것을 입증하지 않습니다.

완화

기기 소유자는 TV 제조사로부터 관련 수정이 포함된 펌웨어를 받아야 합니다. MediaTek은 수정을 ALPS11060069 / DTV04881615로 식별합니다; 이 글의 일부로 검증된 수정된 PEAQ 펌웨어 버전은 없습니다.

구성 요소 유지 관리자의 경우 외부 호출자가 불필요하면 android:exported="false"로 외부 노출을 제거하십시오. 신뢰할 수 있는 교차 애플리케이션 접근이 필요한 경우 적절한 signature-level permission으로 서비스를 보호하고 수신기 상태를 변경하기 전에 인가를 강제하십시오. 보호된 설정 쓰기를 포함한 모든 진입점과 라이프사이클 부작용을 검토하십시오.

이는 분석에서 나온 강화 권장 사항이며, 게시되지 않은 벤더 패치에 대한 설명이 아닙니다. 일반 애플리케이션 UID와 정당한 캐스팅 클라이언트 모두를 사용하여 결과를 검증하십시오.

공개 타임라인 및 크레딧

Davide Di Matteo가 발견하고 보고했습니다. 공개를 조정하고 2026년 9월 크레딧에서 연구를 인정해 준 MediaTek에 감사드립니다.

참고 자료

• MediaTek — 2026년 9월 보안 공지
• MediaTek — 보안 감사 인정
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516