sanan2004/cve-2022-37706PoC
CVE-2022-37706
안녕하세요, 이번에는 제가 Linux의 주요 창 관리자 중 하나인 Enlightenment (https://www.enlightenment.org/)에서 발견한 최근 0-day에 대해 이야기하려고 합니다.
이 0-day는 어떤 사용자든 매우 쉽고 즉시 root 권한으로 승격시킬 수 있습니다.
이 익스플로잇은 Ubuntu 22.04에서 테스트되었지만, 다른 어떤 배포판에서도 잘 작동할 것입니다.
우선 Enlightenment는 Linux(주요 플랫폼), BSD 및 기타 호환 UNIX 시스템을 위한 창 관리자, 컴포지터, 그리고 미니멀 데스크톱입니다.
저는 이 창 관리자를 약간 실험해보기 위해 설치했습니다. 도구가 많고 솔직히 꽤 깔끔해 보여서 흥미로웠습니다.
apt install enlightenment 명령으로 패키지를 설치한 후 시스템에 설치된 파일과 디렉터리를 살펴보았습니다. 많은 모듈과 많은 헬퍼 바이너리가 있었지만, 가장 흥미로운 것은 다음과 같습니다:
➜ enlightenment cd /usr/lib/x86_64-linux-gnu/enlightenment/
➜ enlightenment find . -perm -4000
./utils/enlightenment_ckpasswd
./utils/enlightenment_system
./utils/enlightenment_sys
일부 SUID 바이너리를 설치하는데, 그중 하나를 사용하여 root로 권한 상승을 할 수 있을지 생각해 보았습니다. 바이너리들은 모두 안전해 보이고 잘 작성되어 있었습니다.
우리가 이야기할 바이너리는 enlightenment_sys입니다.
다른 대상과 마찬가지로 사전 평가(pre-assessment)를 수행한 후 적용할 전략을 선택합니다.
아직 보지 못했다면 제 블로그를 참고하세요 (https://pwn-maher.blogspot.com/2020/10/vulnerability-assessment.html)
저는 하향식(Top-Down) 접근 방식으로 코드를 감사했습니다.
그리고 이 창 관리자는 오픈소스이므로 해당 바이너리와 모듈의 소스 코드를 모두 사용할 수 있습니다.
그래서 가장 먼저 apt source enlightenment를 실행하여 전체 소스 코드를 받았고,
약간의 파고들기만 하면 대상 바이너리 코드에 도달할 수 있었습니다.
하지만 바이너리를 디버깅하기 위해 분석 및 중단점 설정용 주소 확보를 위해 Ghidra에 로드했습니다.
첫 시도에서는 심볼이 발견되지 않았지만, 비교적 작은 바이너리라서 필요하지 않았습니다.
놀랍게도 소스 코드를 직접 보는 것보다 Ghidra의 디컴파일된 의사 코드를 보는 것이 훨씬 마음에 들었습니다 (매크로를 피하고, 특정 코드 블록을 컴파일하는 데 사용된 OS 검사들도 피할 수 있습니다).
그럼 분석을 시작해 보겠습니다.
1- 바이너리를 가지고 놀아보기.
파일 명령을 실행하여 대상에 대한 정보를 확인해 봅시다:
Screenshot
바이너리를 실행해도 아무 출력이 없습니다:
Screenshot
--help 인자를 주면 다음과 같은 출력이 나옵니다:
Screenshot
죄송합니다, 하지만 저는 이걸 root를 얻는 데 사용할 겁니다.
다음으로 strace를 실행하여 execve나 openat 같은 의심스러운 시스템 콜을 사용하는지 확인해 봅시다:
strace ./enlightenment_sys 2>&1 | grep open
Screenshot
우리가 건드릴 권한이 없는 위치의 알려진 라이브러리들만 엽니다.
strace ./enlightenment_sys 2>&1 | grep exec
Screenshot
2- 바이너리를 리버스 엔지니어링한 다음 익스플로잇하기.
새 Ghidra 프로젝트를 만들고 이 특정 바이너리를 로드했습니다.
심볼이 없었기 때문에 entry를 이용해 main 함수를 찾을 수 있습니다.
entry 함수의 첫 번째 인자는 main 자체입니다.
이후 참조를 위해 이름을 main으로 변경했습니다.
조금 아래로 스크롤하면 system() 함수가 사용되는 것을 바로 볼 수 있습니다.
포너(pwner)로서 저는 이 특정 함수를 실행시키기 위해 챌린지에서 며칠을 보내기도 합니다 x)
메모리 손상 버그나 힙 문제를 찾기 위해 바이너리를 리버스했지만, 실제로는 이상한 명령 삽입(Command Injection)이었습니다.
바이너리는 system()을 실행하기 전에 모든 보안 예방 조치를 취하지만, 안타깝게도 우리는 항상 거기에 입력을 주입할 수 있습니다.
Screenshot
좋습니다. 이제 바이너리를 위에서부터 system 함수까지 따라가면서 입력을 주입할 방법을 찾아봅시다.
먼저 바이너리는 첫 번째 인자가 --help 또는 -h인지 확인하고 아까 본 메시지를 표시합니다.
Screenshot
둘째, 권한을 root로 승격시킵니다.
Screenshot
다음으로, 의도하지 않은 다른 바이너리를 호출하지 않도록 거의 모든 환경 변수를 해제합니다(보안 예방 조치).
Screenshot
따라서 입력한 첫 번째 인자가 "mount"이면 이 분기로 들어가 주어진 일부 플래그를 확인하며, 그 플래그들은 스택에 설정됩니다.
다음으로 mount 뒤의 다음 인자가 UUID=로 시작하는지 확인합니다. 우리는 여기로 들어가고 싶지 않으므로 "/dev/../tmp/;/tmp/exploit"를 입력했습니다.
Screenshot
이렇게 하면 410행의 검사(즉 strncmp 검사)를 통과합니다.
왜냐하면 /dev/로 시작하지 않으면 바이너리가 종료되기 때문입니다.
그런 다음 우리가 제공한 파일에 대해 stat64를 호출합니다. ";"라는 폴더를 만들 수 있다는 점에 주목하세요. 이것이 명령 삽입을 유발하게 됩니다.
지금까지 익스플로잇은 /dev/../tmp/;/tmp/exploit 파일을 이미 생성했지만, 이것이 호출될 익스플로잇은 아닙니다.
Screenshot
Screenshot
이제 점점 system()에 가까워지고 있습니다.
이제 p(포인터)는 SUID 바이너리에 전달된 마지막 인자인 /tmp///net으로 갱신됩니다.
왜 /tmp/net을 전달할 수 있는데 /tmp///net을 제공하는 걸까요?
다음 검사를 우회하기 위해서입니다:
if (((next_next == (char *)0x0) || (next_next[1] == '\0')) || ((long)next_next - (long)p != 6))
/tmp/net이 존재해야 하고 /tmp///의 길이가 6이어야 했습니다.
이제 마지막 stat64가 "/dev/net"의 존재를 확인합니다.
__snprintf_chk(cmd,0x1000,1,0x1000,"/dev%s",next_next);
그리고 그것을 찾을 수 있으므로 마지막 검사도 통과합니다.
이제 일부 파일의 존재 여부를 확인하지만, 이 시점에서는 중요하지 않습니다. 우리는 모든 준비를 마쳤고 임의 명령 실행을 트리거하기에 매우 근접했기 때문입니다.
이제 eina_strbuf_new()는 system에 전달될 명령을 초기화할 뿐입니다. 문제는 우리가 다음과 같이 입력했다는 것입니다:
/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), "/dev/../tmp/;/tmp/exploit" /tmp///net
하지만 바이너리는 eina_strbuf_append_printf()를 여러 번 호출하고 다음과 같이 됩니다:
/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), /dev/../tmp/;/tmp/exploit /tmp///net
큰따옴표가 제거된 것을 확인할 수 있으며, 이로 인해 /tmp/exploit을 root 권한으로 호출할 수 있게 됩니다.
Screenshot
바이너리는 의도하지 않은 동작을 완화하기 위해 최선을 다했지만, 늘 그렇듯 무엇이든 뚫릴 수 있습니다. 저는 이런 논리적 버그를 이용해 익스플로잇할 것이라고는 예상하지 못했습니다.
다음 CVE는 LPE root로 이어지는 메모리 손상이었으면 좋겠습니다.