0xbinder/cve_2019_2215Android Binder UAF(use-after-free)를 악용하는 개념 증명(PoC) LPE 익스플로잇으로, iovec 스프레이와 addr_limit 덮어쓰기를 사용해 임의 커널 읽기/쓰기를 달성합니다.
Android Binder 드라이버의 Use-After-Free 취약점인 CVE-2019-2215를 대상으로 하는 재작성된 Proof-of-Concept / 로컬 권한 상승(LPE) 익스플로잇입니다.
취약한 커널 빌드를 vulnerable_kernel_builds 폴더에 제공했습니다. Android 10 에뮬레이터 AOSP를 만들고 그 커널로 실행하세요
emulator -show-kernel -no-window -no-snapshot -wipe-data -avd research -kernel bzImage
버그의 기술적 세부 사항에 대해서는 이 훌륭한 블로그에서 배울 수 있습니다: https://projectzero.google/2019/11/bad-binder-android-in-wild-exploit.html
task_struct 구조체에는 mm_segment_t 타입의 중요한 멤버인 addr_limit이 있습니다. addr_limit은 유효한 사용자 공간 주소 중 가장 높은 주소를 저장합니다. addr_limit은 대상 아키텍처에 따라 struct thread_info 또는 struct thread_struct의 일부입니다. 지금 우리는 x86_64 비트 시스템을 다루고 있으므로 addr_limit은 struct thread_struct에 정의됩니다.
이 addr_limit을 0xFFFFFFFFFFFFFFFF로 덮어쓸 수 있다면 커널 공간 메모리의 어느 부분이든 읽고 쓸 수 있게 됩니다. x86_64와 arm64에서 익스플로잇의 호환성을 높이려면 addr_limit을 0xFFFFFFFFFFFFFFFE로 설정하는 것이 좋습니다.
struct iovec는 Scatter/Gather I/O라고도 알려진 Vectored I/O에 사용됩니다. struct iovec의 주요 문제 중 하나는 수명이 매우 짧다는 것입니다. 시스템 콜이 버퍼로 작업할 때 할당되고 사용자 모드로 돌아오면 즉시 해제됩니다.
우리는 unlink 연산을 트리거하고 iov_base 포인터를 binder_thread->wait.head의 주소로 덮어써서 범위가 제한된 읽기/쓰기를 얻을 때 iovec 구조체가 커널에 남아 있기를 원합니다. 한 가지 방법은 pipe 파일 디스크립터에서 readv, writev 같은 시스템 콜을 사용하는 것입니다. pipe가 가득 차거나 비어 있으면 블록될 수 있기 때문입니다. pipe는 프로세스 간 통신에 사용할 수 있는 단방향 데이터 채널입니다. pipe의 블로킹 기능은 커널 공간에서 iovec 구조체를 변조할 수 있는 충분한 시간 창을 제공합니다.
같은 방식으로 recvmsg 시스템 콜에 플래그 매개변수로 MSG_WAITALL을 전달하여 블록시킬 수 있습니다.
binder_thread 구조체의 크기가 408 바이트이므로 kmalloc-512 캐시에 들어가게 됩니다.
댕글링 청크를 재할당하려면 25 iovec 구조체를 쌓아야 합니다. 408 / 16 = 25.5
위 이미지에서 볼 수 있듯이 iovecStack[10].iov_len과 iovecStack[11].iov_base가 덮어써집니다.
따라서 iovecStack[10]을 처리하고, writev 시스템 콜을 블록시킨 다음 unlink 연산을 트리거해야 합니다. 이렇게 하면 iovecStack[11].iov_base가 덮어써질 때 writev 시스템 콜을 재개할 수 있습니다. 마지막으로 binder_thread 청크의 내용을 사용자 공간으로 유출하여 그로부터 task_struct 포인터를 읽어냅니다.
범위가 제한된 write를 달성하기 위해 recvmsg 시스템 콜에 플래그 매개변수로 MSG_WAITALL을 전달하여 블록시킬 것입니다. recvmsg 시스템 콜은 writev 시스템 콜처럼 블록될 수 있습니다.
mm_segment_t의 크기가 0x8 바이트이므로 0xFFFFFFFFFFFFFFFE로 덮어쓰는 것이 좋습니다. 이 값은 유효한 커널 공간 주소 중 가장 높은 주소이며 arm64 시스템에서 페이지 폴트가 발생해도 프로세스를 크래시시키지 않습니다.
