안드로이드 보안 컨테이너 Kinibi 기반 TrustZone 취약점 분석

1. 서론

 

오늘날 스마트폰은 현대인에 있어 필수적인 장비가 되었고 그만큼 개인정보와 같이 민감한 정보를 담고 있습니다. 현재 안드로이드 시스템은 주로 크로스 사이트 공격(Cross-site scripting, XSS), 권한 상승 공격(Privilege Escalation), 이미지 변조 및 악성 애플리케이션, 리플레이 공격, 통신 공격, NFC 공격, 서비스 거부 공격 등과 같은 보안 위험에 직면해오고 있어서 높은 보안 표준을 유지하는 것이 중요하다고 봅니다. 특히 안드로이드는 10억 개 이상의 단말기를 보유한 가장 일반적으로 사용되는 운영 체제이나 오픈 소스 특성과 사용의 유연성은 해커들의 많은 관심을 끌고 있습니다[4]. 그러나 공격 보호를 위해 현재 연구의 대부분은 애플리케이션 계층에 있습니다. 이러한 솔루션은 현재 모바일 단말기가 직면한 보안 문제를 근본적으로 해결할 수 없으며, 단말기는 여전히로부터 위협을 받을 수 있음으로 모바일 단말기의 시스템 계층에서 시작하여 안전하고 신뢰 시스템(Trusted System)을 구축할 필요가 있습니다[2].

안드로이드 시스템 계층의 보안 연구에는 SEAndroid, 하드웨어 기반 가상화 기술(Virtualization Technology) 및 ARM 기반 TrustZone 기술의 3가지 주요 방법이 있고 이러한 기술의 도입은 악성 애플리케이션이 시스템을 공격하는 것을 대부분 대응할 수 있었지만, Trusty TEE에 의존해야 하며 공격자의 직접적인 공격에는 방어할 수 없습니다. 본 연구는 안드로이드 시스템의 아키텍처를 이해하고 2019년부터 2021년까지 안드로이드 모바일 플랫폼에서 발생한 취약점 중 Kinibi 기반 TrustZone 취약점 사례들을 분석하여 취약점 도출 낸 방법과 패치한 코드를 비교하여 살펴봅니다.

 

 

2. 배경 지식

2.1. 안드로이드 시스템 아키텍처

Fig. 1. Android System Architecture

Fig. 1.와 같이 안드로이드 시스템 아키텍처의 주요 기능으로 자세한 설명은 아래와 같습니다.

 

ㆍ애플리케이션 프레임워크 : 애플리케이션 개발자가 가장 자주 사용하며, 하드웨어 개발자는 개발자 API를 알고 있어야 합니다. 이는 다수의 API가 기본적인 HAL 인터페이스에 직접 매핑되고 구현 드라이버에 관한 유용한 정보를 제공할 수 있기 때문입니다.

 

ㆍ바인더 IPC(프로세스 간 통신) 메커니즘 : 애플리케이션 프레임워크에서 경계를 교차 처리하고 Android 시스템 서비스 코드를 호출할 수 있게 해줍니다. 그러면 상위 수준의 프레임워크 API가 Android 시스템 서비스와 상호작용할 수 있고 애플리케이션 프레임워크 수준에서는 이 통신이 개발자로부터 숨겨지며 상황은 '단순하게 돌아가는' 것처럼 보입니다.

 

ㆍ시스템 서비스 : 창 관리자, 검색 서비스 또는 알림 관리자와 같은 집중된 형식의 모듈식 구성요소입니다. 애플리케이션 프레임워크 API에 의해 노출된 기능은 시스템 서비스와 통신하여 기본 하드웨어에 액세스하며, Android에는 시스템(창 관리자 및 알림 관리자 등)과 미디어(미디어 재생 및 녹음/녹화 관련 서비스), 이렇게 두 가지 서비스 그룹이 포함됩니다.

 

ㆍHAL : 하드웨어 공급업체에서 구현해야 하는 표준 인터페이스를 정의하며 Android에서 하위 수준의 드라이버 구현을 고려하지 않아도 되게 해주는 시스템입니다. HAL을 사용하면 상위 수준 시스템을 수정하거나 시스템에 영향을 주지 않고도 기능을 구현할 수 있고, HAL 구현은 모듈로 패키징되며 적절한 시점에 Android 시스템에 의해 로드됩니다.

 

ㆍ기기 드라이버 개발 : 일반적인 Linux 기기 개발과 유사하며, Android는 Linux 커널의 버전을 사용합니다. 여기에는 Low Memory Killer(메모리를 좀 더 적극적으로 보존하는 메모리 관리 시스템), wake lock(PowerManager 시스템 서비스), 바인더 IPC 드라이버 및 모바일 삽입 플랫폼에 중요한 기타 기능과 같은 몇 가지 특별한 추가 기능이 포함되어 있고 이러한 추가 기능은 주로 시스템 기능과 관련이 있으며 드라이버 개발에는 영향을 미치지 않습니다[3].

 

2.2. TrustZone 아키텍처

Fig. 2. TrustZone Architecture

Fig. 2.의 TrustZone 아키텍처에서 TEE는 보안 EL1 수준에서 실행됩니다. Trusty 애플리케이션을 그 위에 로드하고 보안 EL0 수준에서 실행할 수 있고, TrustZone을 사용하면 NS(Non-Secure Flag)로 메모리에 태그를 지정하여 Secure World 메모리를 Normal World에서 격리할 수 있습니다. Normal World에서 실행되는 코드는 NS로 태그가 지정된 메모리에만 액세스할 수 있습니다.

 

다음은 3가지 주요 제조사들의 TEE 명칭입니다[5].

ㆍQualcomm: QSEE/QTEE

ㆍHuawei: TrustedCore

ㆍTrustonic: Kinibi

 

2.3. Samsung TrustZone 아키텍처

Fig. 3. Samsung TrustZone Architecture

Samsung TrustZone 아키텍처는 Fig. 3.의 설명은 다음과 같습니다.

ㆍNormal World에서 Drivers, Daemons, Libraries 그리고 Interfaces는 Secure World와의 통신은 SMC 및 공유 메모리 버퍼를 통과합니다.

ㆍSecure Monitor : ARM Trusted 기반 오픈소스 펌웨어입니다. 모듈식 구현과 공급 업체로부터 요구 사항에 맞게 런타임 서비스를 사용자가 지정한 SMC 핸들러를 추가할 수 있고, 여기서 Samsung은 Kinibi에서 처리하는 SMC를 전달하기 위해 런타임 서비스를 사용합니다.

ㆍSecure World : Micro-Kernel 아키텍처 기반 중 Kinibi는 Trustonic에서 개발한 32bit OS이며, Mobicore 및 t-base라고 불립니다. MTK는 S-EL1에서 유일하게 실행할 수 있는 Micro-Kernel입니다. 여기서 syscalls(SVCs)이 제공되는데 메모리 매핑, 프로세스 생성, SMCs 등이 있으며, 사용 가능한 SVCs는 호출 프로세스의 권한에 따라 달라지고 내장 드라이버와 같은 다른 구성 요소에는 Run-Time Manager(RTM)을 로드합니다.

 

ㆍRTM는 리눅스의 init 프로세스와 동일한 Secure World를 신뢰 애플리케이션입니다. 주요 작업으로 프로세스 시작과 관리를 할 수 있고 Trustlet에 NWd의 수신되는 데이터를 알립니다.  또한, 프로세스 간 통신이 가능한 Mobicore Communication Interface(MCI)가 통신 채널로 구현되어 있습니다.

ㆍMCLIB는 Kinibi의 표준 라이브러리이며, 신뢰 애플리케이션, Secure 드라이버 및 RTM에 표준 기능을 제공합니다.

 

다음과 같이 2개의 API로 구분됩니다.

ㆍTIApi: 신뢰 애플리케이션에서 사용하는 함수 집합
ㆍDrApi: Secure Driver에서 사용하는 기능 집합

ㆍTrusted Applications는 일반 애플리케이션과 동등한 Secure World(S-EL0에서 실행)입니다..

ㆍSecure Drivers는 Trusted 애플리케이션의 특수한 유형으로 S-EL0에서 실행되지만, 소프트웨어 정의 권한이 더 높아 더 많은 API와 syscall에 액세스할 수 있습니다. IPC 및 공유 메모리를 통해 TA와 통신합니다.

 

2.4. Trusty 애플리케이션

Fig. 4. TA Memory mapping

Fig. 4.는 TA 메모리 매핑으로 Trusty 애플리케이션에서 임의 코드 실행의 과정으로 다음과 같습니다.

대부분 Trusty 애플리케이션과 드라이버는 서명된 바이너리이지만 암호화되어 있지 않는다면 쉽게 분석할 수 있다. Samsung 단말기에서 이러한 바이너리는 /vendor/app/mcRegistry 및 /system/app/mcRegistry 디렉터리에 저장됩니다.

Trusty 애플리케이션 및 드라이버 바이너리에서 사용되는 MCLF 형식입니다. 이 형식은 trustonic-tee-user-space에서 사용할 수 있는 헤더 파일에 문서화되어 있습니다. mclf-ida-loader는 IDA에서 이 형식을 로드하는 데 도움을 줄 수 있습니다.

TA가 로드되면 Kinibi에서 MCLF 헤더를 사용하여 TA 메모리 공간의 코드, 데이터 및 bss 영역을 매핑합니다. mcLib 라이브러리는 고정 주소(0x07d00000 - Galaxy S8, S9)에 매핑됩니다. 또한, 세션이 열리면 공유 버퍼(tci)도 MCLF 헤더에 지정된 버전에 따라 고정 주소(0x00100000, 0x00300000)에서 매핑됩니다.

REE의 TA Client는 새로운 공유 메모리 영역을 매핑할 수 있으며 이러한 영역은 0x00200000 + map_id*0x00100000입니다.

 

tci는 입력 및 출력 버퍼에 공유 메모리를 사용하며 처음 32비트는 명령 ID로 사용됩니다. 일반적으로 초기화는 진입점(암호화 초기화, 스택 쿠키 랜덤화 등)에서 수행된 다음 main 함수가 호출됩니다. main 함수는 공유 버퍼 크기를 확인한 다음 main Loop를 시작한다. TA는 tlApiWaitNotification API로 새 메시지를 기다리고 공유 버퍼의 내용을 처리합니다. 응답 데이터는 공유 버퍼에 기록되고 TA는 tlApinotify API로 REE에 알리고 새 메시지를 기다립니다.

 

 

3. 취약점 분석

3.1. SVE-2019-16665

해당 취약점은 Android 7.0버전인 Samsung Galaxy S7의 단말기에서 EL3에서 코드 실행이 가능하도록 Kinibi에서 임의 메모리를 매핑한 것입니다. 취약점을 도출하기 위해 Trustlet에서 사용하는 MCLF 형식의 Ghidra 로더, tlApi 함수의 이름을 자동으로 바꾸는 IDA Pro/Ghidra 로더, Trustlet과 통신하기 위한 Python 프레임워크, AFL 및 Unicorn 엔진에 기반한 에뮬레이터/Fuuzer, 기호 실행을 수행하는 Manticore 스크립트, S-Boot 바이너리 IDA Pro/Ghidra 로더로 도구 개발되었습니다.

Trusty 애플리케이션을 공격한 방법은 SEM Trustlet에서 Stack Buffer Overflow가 발생하여 memcpy 호출 전 Fig. 5.와 같이 레지스터가 설정됩니다.

ㆍR0 = SP+0x4F8-0xF0 (destination buffer)
ㆍR1 = tci_buffer + 0x8 (source buffer)
ㆍR2 = *(tci_buffer + 0x16808) (length of the buffer)

이를 통해서 S-EL0에서 코드 실행이 가능하여 보안 드라이버 통신과 syscalls(print characters, system information 등)을 할 수 있고, 그다음 MMAP의 보안 및 비보안 물리 메모리 매핑하기 위해 syscalls 작업으로 MMAP을 사용하여 Monitor의 0x2022000 주소에 SMC을 수정함으로써 S-EL3에서 임의 코드 실행이 가능합니다.

 

Fig. 5. Register Area

3.2. SVE-2019-15230

해당 취약점은 Normal World인 EL0의 User Mode에서 EL1(Kinibi)의 SVE/Sys/Abort Mode에 접근하는 것으로 먼저, Odin을 통해 Odin Mode initial 및 settings와 Flash PIT, Flag image의 opCode 값을 가져옵니다. 다음 Fig. 6.와 같이 Integer overflow 발생하는 원인으로 0x1e00000 보다 낮으면 0xC0000000을 사용하고 그렇지 않다면, 0xB0000000을 사용합니다. 참고로 Galaxy S8 이전 단말기는 0xC0000000이며, Galaxy S9 이후 단말기는 0x880000000의 버퍼를 복사합니다.

Fig. 6. Odin Flash Image

따라서 Fig. 7.와 같이 버퍼 뒤에 저장되는 데이터는 Secure Boot의 Code Segment로 크기 검증 코드가 없어 Buffer Overflow 취약점 인한 임의 데이터를 덮어쓸 수 있습니다. 취약점 패치는 Fig. 8.와 같이 데이터 패킷의 크기를 검증하는 코드가 추가되었습니다.

Fig. 7. Overflow the physical memory

Fig. 8. SVE-2019-15230 Patch

3.3. SVE-2019-15872

해당 취약점은 Fig. 9.와 같이 S-Boot에서 USB 기능의 일부 코드입니다. 이때 qword_C91494B0의 값이 반복적으로 사용하고 있음을 알 수 있습니다. 이를 통해서 opCode 0x64와 subOp 0x05로 패킷 데이터 크기를 지정할 수 있어 USB 수신되는 크기를 0x1200000보다 큰 값을 사용 가능하여 SVE-2019-15230와 같은 방식으로 임의 코드 실행이 가능합니다. 취약점 패치는 Fig. 10.와 같이 데이터 패킷의 크기를 검증하는 코드가 추가되었습니다.

Fig. 9. SVE-2019-15872 Attack Vector

Fig. 10. SVE-2019-15872 Patch

 

 

4. 결 론

 

본 연구는 최근 발견된 안드로이드 보안 컨테이너인 Kinibi 기반 TrustZone 취약점 분석한 연구를 제시해보았습니다. TEE는 하드웨어 기반의 가상화된 보안 격리와 TCB로 인해 안전하다는 믿음에도 불구하고 취약점이 보고되고 있습니다. 특히, 현재 TEE 시스템은 구현, 아키텍처 및 하드웨어 수준에서 심각한 한계를 가지고 있으며 이로 인해 수백 만 개의 단말기에 영향을 미치는 잠재적인 취약점이 발생할 수 있지만, 분석에 기초하여 오늘날까지 보안 연구진들은 User Mode(EL0)에서 Kernel Mode(EL1)와 User Mode(S-EL0), Monitor Mode(S-EL3)까지 취약점을 도출하고 있고 그중 Monitor Mode(S-EL3) 영역에서 임의 코드를 실행하기 위해 Fuzzing 연구가 활발히 진행되고 있기에 상업용 TEE 시스템을 훨씬 더 안전하게 구현될 것이라 전망합니다.

 

 

References

[1] Liu, Yue, et al. “Deep Learning for Android Malware Defenses: a Systematic Literature Review.” arXiv preprint arXiv:2103.05292 (2021).

[2] Farhang, Sadegh, et al. “An empirical study of Android security bulletins in different vendors.” Proceedings of The Web Conference 2020. 2020.

[3] Tang, Junwei, et al. “A novel hybrid method to analyze security vulnerabilities in android applications.” Tsinghua Science and Technology 25.5 (2020): 589-603.

[4] Jones, Kailani R., et al. “Deploying Android Security Updates: an Extensive Study Involving Manufacturers, Carriers, and End Users.” Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security. 2020.

[5] Hei, Xinhong, et al. “From Hardware to Operating System: A Static Measurement Method of Android System Based on TrustZone.” Wireless Communications and Mobile Computing 2020 (2020).