중요한 MediaTek 루트킷은 수백만 대의 Android 기기에 영향을 미칩니다.

매월 첫 번째 월요일에 Google은 Android 보안 게시판, Google 자체 또는 기타 제3자가 제출한 모든 보안 취약점과 패치를 공개하는 페이지입니다. 오늘도 예외는 아니었습니다. Google은 2020년 3월 Android 보안 게시판을 공개했습니다. 최신 공지에 문서화된 취약점 중 하나는 CVE-2020-0069입니다. 이는 중요한 보안 악용, 특히 루트킷, 이는 대만의 대규모 칩 설계 회사인 MediaTek의 칩셋을 사용하는 수백만 대의 장치에 영향을 미칩니다. 2020년 3월 Android 보안 게시판에서 CVE-2020-0069가 공개된 것은 처음인 것처럼 보이지만, 익스플로잇에 대한 자세한 내용은 실제로 4월부터 인터넷, 특히 XDA-Developers 포럼에 공개적으로 게시되었습니다. 2019년. MediaTek이 발견 후 한 달 만에 패치를 제공했음에도 불구하고 이 취약점은 여전히 ​​수십 개의 장치 모델에서 악용될 수 있습니다. 더욱 심각한 것은 해커들이 이 취약점을 적극적으로 악용하고 있다는 것입니다. 이제 MediaTek은 이 패치 격차를 줄이고 이 중요한 보안 악용으로부터 수백만 대의 장치를 보호하기 위해 Google을 선택했습니다.

아직 익숙하지 않은 독자들을 위해 XDA 개발자, 우리는 Android 소프트웨어 수정을 위한 최대 규모의 포럼이 있는 사이트입니다. 일반적으로 이러한 수정은 블로트웨어 삭제, 맞춤형 소프트웨어 설치 또는 기본 시스템 매개변수 조정을 위해 장치에서 루트 액세스 권한을 얻는 데 중점을 둡니다. Amazon의 Fire 태블릿은 우리 포럼에서 취미 해커들의 인기 있는 표적입니다. 블로트웨어는 Google Play 스토어와 같은 기본 소프트웨어 애플리케이션에 대한 액세스가 부족하며, 가장 중요한 것은 값이 싼. Amazon Fire 태블릿을 루팅할 때 어려운 점은 사용자가 Amazon의 벽으로 둘러싸인 정원 밖으로 나가는 것을 방지하기 위해 강력하게 잠겨 있다는 것입니다. Amazon은 일반적으로 특정 Android 기기를 루팅하는 첫 번째 단계인 Fire 태블릿의 부트로더를 잠금 해제하는 공식적인 방법을 제공하지 않습니다. 따라서 (하드웨어 수정 없이) Amazon Fire 태블릿을 루팅하는 유일한 방법은 사용자가 Android의 보안 모델을 우회할 수 있도록 하는 소프트웨어에서 익스플로잇을 찾는 것입니다. 2019년 2월 말이에요.

XDA 고위 회원 외교관이 정확히 무엇을 했는지 그가 Amazon Fire 태블릿 포럼에 스레드를 게시했을 때. 그는 이 공격이 Amazon의 Fire 태블릿보다 범위가 훨씬 더 넓다는 것을 빨리 깨달았습니다.

XDA 회원 외교관 및 기타 커뮤니티 회원들로부터 약간의 테스트를 거친 후, 이 익스플로잇이 다수의 MediaTek 칩에서 작동하는 것으로 확인되었습니다. 저자는 이 익스플로잇이 "거의 모든 MediaTek의 64비트 칩"에서 작동한다고 밝혔으며 특히 MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8173, MT8176, MT8183, MT6 580, 및 MT6595. 얼마나 많은 MediaTek 칩셋이 이 익스플로잇의 영향을 받았기 때문에 이 익스플로잇에는 "MediaTek-su" 또는 줄여서 "MTK-su"라는 이름이 붙었습니다. 2019년 4월 17일 디플로마는 "라는 제목의 두 번째 스레드를 게재했습니다.MediaTek ARMv8을 위한 놀라운 임시 루트"를 "기타 Android 개발" 포럼에서 확인해보세요. 이 스레드에서 그는 사용자가 셸에서 슈퍼유저 액세스 권한을 부여하기 위해 실행할 수 있는 스크립트를 공유했습니다. 매우 안전하지 않은 "허용" 프로세스에 대한 액세스 제어를 제공하는 Linux 커널 모듈인 SELinux 상태. 사용자가 루트 액세스 권한을 얻고 자신의 장치에서 SELinux를 허용하도록 설정하는 것은 놀라울 정도로 쉽습니다. 스크립트를 임시 폴더로 복사하고, 디렉토리를 스크립트가 저장된 위치로 변경하고, 스크립트에 실행 권한을 추가한 다음, 스크립트.

XDA 커뮤니티 회원은 이 익스플로잇이 최소한 다음 장치에서 작동했음을 확인했습니다.

1. 에이서 아이코니아 원 10 B3-A30
2. 에이서 아이코니아 원 10 B3-A40
3. 알바 태블릿 시리즈
4. 알카텔 1 5033 시리즈
5. 알카텔 1C
6. 알카텔 3L(2018) 5034 시리즈
7. 알카텔 3T 8
8. 알카텔 A5 LED 5085 시리즈
9. 알카텔 A30 5049 시리즈
10. 알카텔 아이돌 5
11. 알카텔/TCL A1 A501DL
12. 알카텔/TCL LX A502DL
13. 알카텔 테트라 5041C
14. Amazon Fire 7 2019 -- Fire OS 6.3.1.2 빌드 0002517050244까지만 해당
15. Amazon Fire HD 8 2016 -- Fire OS 5.3.6.4 빌드 626533320까지만 해당
16. Amazon Fire HD 8 2017 -- Fire OS 5.6.4.0 빌드 636558520까지만 해당
17. Amazon Fire HD 8 2018 -- Fire OS 6.3.0.1까지만 해당
18. Amazon Fire HD 10 2017 -- Fire OS 5.6.4.0 빌드 636558520까지만 해당
19. Amazon Fire HD 10 2019 -- Fire OS 7.3.1.0까지만 해당
20. Amazon Fire TV 2 -- Fire OS 5.2.6.9까지만 해당
21. ASUS ZenFone Max Plus X018D
22. ASUS 젠패드 3s 10 Z500M
23. ASUS ZenPad Z3xxM(F) MT8163 기반 시리즈
24. Barnes & Noble NOOK 태블릿 7인치 BNTV450 및 BNTV460
25. 반스앤노블 NOOK 태블릿 10.1인치 BNTV650
26. 블랙뷰 A8 맥스
27. 블랙뷰 BV9600 프로(헬리오 P60)
28. 블루 라이프 맥스
29. 블루 라이프 원 X
30. BLU R1 시리즈
31. 블루 R2 LTE
32. 블루 S1
33. BLU 탱크 익스트림 프로
34. 블루 비보 8L
35. 블루 비보 XI
36. 블루 비보 XL4
37. 블루부 S8
38. BQ 아쿠아리스 M8
39. 고양이 S41
40. Coolpad 쿨 플레이 8 Lite
41. 드래곤 터치 K10
42. 에코필링
43. 지오니 M7
44. HiSense 인피니티 H12 라이트
45. 화웨이 GR3 TAG-L21
46. 화웨이 Y5II
47. 화웨이 Y6II MT6735 시리즈
48. 라바 아이리스 88S
49. 레노버 C2 시리즈
50. 레노버 탭 E8
51. 레노버 탭2 A10-70F
52. LG K8+(2018) X210ULMA(MTK)
53. LG K10 (2017)
54. LG 추모 왕조
55. LG X power 2/M320 시리즈(MTK)
56. LG 익스프레스 플러스 2/K40 LMX420 시리즈
57. 루미곤 T3
58. 메이주 M5c
59. 메이주 M6
60. 메이주 프로 7 플러스
61. 노키아 1
62. 노키아 1 플러스
63. 노키아 3
64. 노키아 3.1
65. 노키아 3.1 플러스
66. 노키아 5.1
67. 노키아 5.1 플러스/X5
68. Onn 7인치 안드로이드 태블릿
69. Onn 8" 및 10" 태블릿 시리즈(MT8163)
70. OPPO A5s
71. OPPO F5 시리즈/A73 -- Android 8.x 전용
72. OPPO F7 시리즈 -- Android 8.x 전용
73. OPPO F9 시리즈 -- Android 8.x 전용
74. 오우키텔 K12
75. 프로투루 D7
76. 영역 1
77. 소니 엑스페리아 C4
78. 소니 엑스페리아 C5 시리즈
79. 소니 엑스페리아 L1
80. 소니 엑스페리아 L3
81. 소니 엑스페리아 XA 시리즈
82. 소니 엑스페리아 XA1 시리즈
83. Southern Telecom Smartab ST1009X (MT8167)
84. TECNO 스파크 3 시리즈
85. 우미디기 F1 시리즈
86. 우미디기 파워
87. 위코 라이드
88. 위코 써니
89. 위코뷰3
90. 샤오미 홍미 6/6A 시리즈
91. ZTE 블레이드 A530
92. ZTE 블레이드 D6/V6
93. ZTE 퀘스트 5 Z3351S

더 읽어보세요

Vivo, Huawei/Honor(Android 8.0+ 이후), OPPO(Android 8.0+ 이후)의 MediaTek 기반 휴대폰을 제외하고 Samsung, XDA 커뮤니티 회원들은 MediaTek-su가 영향을 받는 장치에서 시도했을 때보다 더 자주 작동한다는 것을 발견했습니다. 칩셋. XDA 회원 외교관에 따르면 Vivo, Huawei/Honor, OPPO 및 Samsung 장치는 "커널 수정을 사용하여 루트 액세스를 방지합니다. 이는 개발자가 해당 장치의 "맞춤형 버전"을 생성하기 위해 이러한 장치의 커널 소스 코드를 파헤쳐야 함을 의미합니다. 악용하다. 추가 노력을 기울일 가치가 없었기 때문에 개발자는 "이론적으로" 익스플로잇이 여전히 작동할 수 있음에도 불구하고 이러한 장치에 대한 지원을 추가하지 않기로 결정했습니다.

이제 이 익스플로잇이 시중에 나와 있는 수많은 장치에 영향을 미친다는 것이 분명해졌습니다. MediaTek 칩은 수백 가지의 저가 및 중급 스마트폰 모델, 저렴한 태블릿 및 브랜드 외 제품을 지원합니다. 셋톱박스는 대부분 제조업체의 적시 업데이트를 기대하지 않고 판매됩니다. 따라서 여전히 MediaTek-su의 영향을 받는 많은 장치는 오늘 공개 이후 몇 주 또는 몇 달 동안 수정을 받을 가능성이 거의 없습니다. 그렇다면 MediaTek-su가 "Critical" 심각도를 획득하는 이유는 무엇입니까? CVSS v3.0 점수는 9.3?

MTK-su가 심각한 보안 취약점인 이유

다시 말하면, Android 기기에서 루트 액세스를 얻는 일반적인 방법은 먼저 부트로더를 잠금 해제하여 부팅 파티션 확인을 비활성화하는 것입니다. 부트로더가 잠금 해제되면 사용자는 시스템에 슈퍼유저 바이너리를 도입할 수 있으며 루트에 액세스할 수 있는 프로세스를 제어하는 ​​슈퍼유저 관리 앱도 사용할 수 있습니다. 부트로더 잠금 해제는 기기의 주요 보안 기능 중 하나를 의도적으로 비활성화하는 것이므로 사용자는 일반적으로 개발자 옵션에서 토글을 활성화한 다음 잠금 해제 명령을 실행하여 명시적으로 이를 허용합니다. 부트로더. 그러나 MediaTek-su를 사용하면 사용자는 루트 액세스를 얻기 위해 부트로더를 잠금 해제할 필요가 없습니다. 대신, 그들이 해야 할 일은 스크립트를 장치에 복사하고 셸에서 실행하는 것뿐입니다. 하지만 사용자만이 이 작업을 수행할 수 있는 것은 아닙니다. 휴대폰의 모든 앱은 MediaTek-su 스크립트를 개인 디렉터리에 복사한 다음 이를 실행하여 셸에서 루트 액세스 권한을 얻을 수 있습니다. 실제로 XDA 회원 외교관 이 가능성을 강조 포럼 스레드에서 다음 중 하나를 사용하여 대체 지침 세트를 제안할 때 Android 앱용 터미널 에뮬레이터 또는 Termux ADB보다는

루트 액세스를 사용하면 Android의 보안 모델이 기본적으로 무너집니다. 예를 들어 루트 셸에 액세스할 수 있는 앱은 원하는 모든 권한을 자체적으로 부여할 수 있으므로 루트 컨텍스트에서는 권한이 의미가 없게 됩니다. 또한 루트 셸을 사용하면 일반적으로 액세스할 수 없는 애플리케이션의 개인 데이터 디렉터리에 저장된 파일을 포함하여 데이터 파티션 전체에 액세스할 수 있습니다. 루트가 있는 앱은 백그라운드에서 원하는 다른 앱을 자동으로 설치한 다음 개인 정보를 침해하는 데 필요한 모든 권한을 부여할 수도 있습니다. XDA 인정 개발자에 따르면 탑존우, 악성 앱은 "ptrace를 사용하여 Zygote에 직접 코드를 삽입"할 수도 있습니다. 이는 공격자의 명령을 수행하기 위해 기기의 일반 앱을 하이재킹할 수 있음을 의미합니다. 이 예에서는 앱이 사용자 모르게 백그라운드에서 신뢰를 위반할 수 있는 몇 가지 방법만 다룹니다. 그러나 악성 앱은 자신이 하는 일을 숨기지 않고도 기기에 큰 피해를 줄 수 있습니다. 예를 들어 랜섬웨어는 극도로 루트 액세스 권한이 강력합니다. 비용을 지불하지 않으면 가상의 랜섬웨어 앱이 나타날 수 있습니다. 완전히 그리고 불가역적으로 장치 전체를 깨끗하게 닦아 장치가 작동하지 않게 만드세요.

MediaTek-su의 유일한 "약점"은 응용 프로그램에 "임시" 루트 액세스 권한만 부여한다는 것입니다. 즉, 장치 재부팅 후 프로세스가 수퍼유저 액세스 권한을 잃게 됩니다. 또한 Android 6.0 Marshmallow 이상을 실행하는 기기에서는 자체 검사 부팅 및 dm-verity 시스템 및 공급업체와 같은 읽기 전용 파티션에 대한 수정을 차단합니다. 그러나 이 두 가지 요소는 대부분 악의적인 행위자보다는 포럼의 모더에게 방해가 될 뿐입니다. 임시 루트의 한계를 극복하기 위해 악성 앱은 부팅할 때마다 간단히 MediaTek-su 스크립트를 다시 실행할 수 있습니다. 반면에 시스템이나 공급업체 파티션을 영구적으로 수정하는 것은 대부분의 맬웨어 작성자의 관심을 끌 가능성이 낮기 때문에 dm-verity를 ​​극복할 필요가 거의 없습니다. 결국, 이미 있습니다 톤 악성 앱이 루트 셸을 사용하여 수행할 수 있는 작업 중 하나입니다.

MediaTek-su가 무엇을 활용하고 있는지 기술적인 수준에서 궁금하신 경우 MediaTek은 진입점을 요약한 아래 차트를 공유했습니다. 이 결함은 "CMDQ"라고 불리는 MediaTek의 Linux 커널 드라이버 중 하나에 존재하는 것으로 보입니다. 설명에는 "IOCTL을 실행하여 [the] CMDQ 장치 노드에서 명령을 실행하면 로컬 공격자는 "물리적 메모리를 임의로 읽고 쓸 수 있고 [the] 커널 심볼 테이블을 사전 할당된 DMA 버퍼 [및] DMA 버퍼를 조작하여 커널 설정을 수정하여 SELinux를 비활성화하고 '루트'로 에스컬레이션합니다. 특권."

MediaTek이 우리와 공유한 차트에 따르면, 이 취약점은 Android 버전 7 Nougat, 8 Oreo 또는 9 Pie를 실행하는 Linux 커널 버전 3.18, 4.4, 4.9 또는 4.14를 사용하는 MediaTek 장치에 영향을 미칩니다. 이 취약점은 "CMDQ의 액세스 권한이 허용되지 않기 때문에 Android 10을 실행하는 MediaTek 장치에서는 악용되지 않습니다. 장치 노드도 SELinux에 의해 시행됩니다." 이 완화는 Android가 아닌 MediaTek의 BSP에 대한 업데이트에서 발생할 가능성이 높습니다. 그 자체. 이 취약점에 대한 Android 10의 유일한 완화 방법은 홈 디렉터리에서 바이너리를 실행하는 앱에 대한 제한; 그러나 XDA Recognized Developer topjohnwu가 지적한 것처럼 악성 앱은 동적 라이브러리에서 MediaTek-su 코드를 실행할 수 있습니다.

MediaTek이 영향을 받는 모든 칩셋에서 이 문제를 패치했지만 장치 제조업체에 패치를 구현하도록 강요할 수는 없습니다. MediaTek은 2019년 5월에 이미 패치가 준비되어 있다고 말했습니다. 당연히 Amazon은 이 문제를 인지한 후 즉시 장치 전반에 걸쳐 패치를 적용했습니다. 그러나 MediaTek이 파트너에게 수정 사항을 제공한 지 10개월이 지났지만 아직까지 2020년 3월, 수십 개의 OEM이 장치를 수리하지 않았습니다.. 영향을 받는 장치의 대부분은 오래된 Android SPL(보안 패치 수준)이 포함된 이전 Android 릴리스에 있으며, 업데이트 상황은 다음을 고려하면 더욱 악화됩니다. 수백 이러한 MediaTek 칩을 사용하는 잘 알려지지 않은 장치 모델입니다. 미디어텍은 심각한 문제가 발생하여 Google에 도움을 요청했습니다.

MediaTek과 달리 Google은 ~할 수 있다 OEM이 다음을 통해 장치를 업데이트하도록 강제합니다. 라이센스 계약 또는 프로그램 약관(예: Android One) OEM이 장치가 2020-03-05 SPL(보안 패치 수준)을 준수한다고 선언하려면 장치에 모든 프레임워크가 포함되어야 합니다. CVE-2020-0069에 대한 수정 사항이 포함된 2020년 3월 Android 보안 게시판의 Linux 커널 및 해당 공급업체 드라이버 수정 사항 또는 MediaTek-su. (Google은 실제로 이를 시행하지 않는 것 같습니다. OEM은 실제로 모든 패치를 병합합니다. 하지만 특정 SPL을 선언할 때는 말이죠.) 이제 2020년 3월 공지가 나왔으니 이 이야기는 끝나야겠죠? 불행하게도 우리는 패치를 통합하는 데 발을 질질 끌던 Google의 발을 불에 붙잡아야 합니다.

보안 패치 프로세스의 결함

아직 명확하지 않은 경우 모든 보안 취약점이 Android 보안 게시판에 게시될 필요는 없습니다. 월간 게시판에 전혀 표시되지 않은 채 공급업체에서 많은 취약점을 발견하고 패치했습니다. MediaTek-su는 그 중 하나였어야 했지만 여러 가지 이유로 여러 OEM이 MediaTek에서 제공하는 패치를 통합하지 못했습니다. (자원 부족, 비즈니스 결정, 의사소통 실패 등 잠재적인 이유는 많습니다.) MediaTek이 도움을 받기 위해 "Google에 의지했다"고 밝혔는데, 이는 MediaTek이 OEM이 최종적으로 문제를 해결할 수 있도록 Google에 적극적으로 도움을 구했음을 암시합니다. 장치. 그러나 실제로는 그렇지 않았을 수도 있습니다. Google은 MediaTek-su의 보안 보고서에서 우연히 언급되기 전까지 MediaTek-su에 대해 알지 못했다는 것을 알고 있습니다. 트렌드마이크로 2020년 1월 6일에 게시되었습니다. 보고서에는 트렌드마이크로 문서화하고 있었다 또 다른 '라고 불리는 보안 취약점바인더 드라이버에서 사용 후 사용"라는 취약점이 활발하게 악용되고 있었습니다. 트렌드마이크로 세 가지 악성 앱이 "바인더 드라이버의 use-after-free" 취약점 또는 MediaTek-su라는 두 가지 방법 중 하나를 사용하여 루트 액세스를 획득한 방법을 언급했습니다.

그 코드에서는 트렌드마이크로 공유된 내용을 보면 악성 앱이 특정 기기 모델(예: Nokia 3, OPPO F9 및 Redmi 6A) 및 MediaTek-su를 사용합니다.

나는 말할 수 없다 트렌드마이크로, 그러나 그들은 MediaTek-su가 아직 패치되지 않은 익스플로잇이라는 사실을 인식하지 못한 것 같습니다. 결국 그들의 초점은 "바인더 드라이버의 use-after-free" 익스플로잇에 있었고 MediaTek-su의 사용 발견은 나중에 고려된 것 같습니다. (확실히 그렇다면 트렌드마이크로 MediaTek-su를 둘러싼 상황을 알고 있었다면 Google과 공개 노력을 조율했을 것입니다.) 우리는 단지 이 악용은 2020년 2월 5일에 발생했으며, 그것이 얼마나 심각한지 스스로 조사한 후 2월 7일에 Google에 문의했습니다. 2020. Google은 MediaTek-su 홍보가 미칠 영향을 너무 우려하여 오늘까지 이 기사 게시를 보류해 달라고 요청했습니다. 악성코드의 표적이 된 사용자에게 미칠 수 있는 회복 불가능한 피해를 고려한 후 MediaTek-su는 2020년 3월 Android 출시 전까지 이 이야기를 보류하기로 합의했습니다. 보안 게시판. 그래도 최신 보안 업데이트를 받는 데 많은 장치가 얼마나 오래 걸릴지 고려하면 어쨌든, 몇 달이 지나도 여전히 MediaTek-su에 취약한 장치가 엄청나게 많이 있을 것입니다. 지금. 취약한 장치를 가진 사람에게는 끔찍한 일이 될 것입니다.

이 매우 심각하고 "치명적인" 심각도 취약점이 실제로 활발하게 악용되고 있음에도 불구하고 Google은 이 문제에 대한 수정 사항은 2020년 3월 공지에 게재되었으며, 이는 해당 문제를 인지한 지 약 2개월 후입니다. 문제. Google은 최신 Android 보안 게시판이 공개되기 30일 전에 Android 파트너에게 공지합니다(예: OEM은 2020년 2월 초에 2020년 3월 게시판의 내용을 알게 되었습니다. Google은 변경사항이나 새로운 수정사항으로 게시판을 업데이트할 수 있으며 종종 업데이트합니다. Google이 이렇게 심각한 문제에 대한 패치를 신속히 포함하지 않기로 결정한 이유는 저로서는 알 수 없습니다. 특히 MediaTek이 10개월 전에 해당 문제를 수정했을 때 더욱 그렇습니다. Apple의 기기에서 그러한 버그가 발견되었다면 그들이 수정 사항을 발표했을 것이라는 데에는 의심의 여지가 없습니다. 훨씬, 훨씬 더 빠르게. Google은 본질적으로 MediaTek-su가 2020년 3월 게시판까지 이미 그랬던 것처럼 겉보기에 눈에 띄지 않는 상태를 유지할 것이라는 위험한 내기를 걸었습니다. 그 점에서 Google은 운이 좋았던 것 같지만, 이미 이 공격에 대해 알고 있는 악성 코드 작성자가 얼마나 되는지는 알 수 없습니다. 결국, 그것은 임의의 XDA 포럼 스레드에 앉아 있었습니다. 거의 일년 내내.

이 사태에는 내가 많이 언급하지 않은 또 다른 당사자가 있는데, 그것은 익스플로잇의 작성자인 XDA Member 외교관입니다. 그의 신용에 따르면, 나는 그가 MediaTek-su를 출판하는데 어떠한 악의적인 의도도 갖고 있지 않다고 생각합니다. 우리는 Amazon Fire 태블릿을 개조하려는 외교적 욕구에서 익스플로잇의 근원을 명확하게 추적할 수 있습니다. Diplomatic은 이 루트 방법을 개발하는 그의 주요 목표가 지역 사회를 돕는 것이라고 말했습니다. 장치를 사용자 정의하는 것은 XDA의 핵심이며 커뮤니티에서의 외교적 노력은 사람들이 포럼에서 즐기는 것입니다. Diplomatic의 프로젝트 오픈 소스 거부로 인해 일부 우려가 제기되고 있지만 그는 커뮤니티가 루트 액세스 권한을 최대한 오랫동안 누릴 수 있기를 원했다고 설명합니다. 내가 외교관에게 처음 연락했을 때 그는 또한 자신이 프로젝트의 소스 코드와 연구를 공유하는 것을 방해하는 일부 파트너와 협력하고 있다고 말했습니다. 이 협력에 대해 더 자세한 내용을 얻을 수는 없었지만 MediaTek이 버그 포상금 프로그램을 제공했다면 외교관이 이 공격을 공개하기로 선택했을지 궁금합니다. MediaTek에 실제로 그런 프로그램이 있었다면 이 정도 규모의 취약점이 있어도 막대한 비용을 지불하지 못할 것이라고는 상상할 수 없습니다. 외교부는 이 악용이 2015년 후반 MediaTek MT6580 칩셋부터 가능했다고 주장하므로 외교관이 이 악용을 처음으로 발견한 사람인지 궁금합니다. 그는 이 기사가 게시되기 전까지 MediaTek-su가 적극적으로 악용되고 있다는 사실을 전혀 몰랐다고 말했습니다.

귀하의 장치가 MediaTek-su에 취약한지 확인하려면 XDA 회원 외교관이 게시한 스크립트를 수동으로 실행하십시오. 이 XDA 포럼 스레드에서. 루트 셸에 들어가면(기호가 $에서 #으로 변경되는 시기를 알 수 있음) 익스플로잇이 작동한다는 것을 알 수 있습니다. 작동한다면 장치 제조업체가 MediaTek-su를 패치하는 업데이트를 출시할 때까지 기다려야 합니다. 장치가 최신 2020년 3월 SPL인 2020-03-05의 보안 패치 수준을 보고하는 경우 해당 장치는 MediaTek-su로부터 거의 확실하게 보호됩니다. 그렇지 않으면 장치가 취약한지 확인하면 됩니다.

---

업데이트 1(2020년 3월 2일 @ 오후 9시 45분(EST)): 이 기사는 XDA 회원 외교관이 실제로 이 취약점의 범위를 인식하자마자 업데이트되었습니다. 2019년 2월에 이 사실을 발견했지만 이 글이 게시될 때까지 이 익스플로잇이 실제적으로 사용되는 것을 알지 못했다고 합니다. 기사. 또한 외교부가 프로젝트 소스 코드 공유를 거부한 한 가지 이유에 대한 문구를 수정했습니다.