lcfr-hax/cve-2024-14027_slopCVE-2024-14027에 대한 익스플로잇으로, AI/Claude를 사용해 테스트용으로 제작되었습니다.
익스플로잇은 Qemu debian 설치 환경에서 6.6.51을 대상으로 테스트되었습니다.
exploit.c - shadow 파일을 유출합니다.
exploit_dc.c - double close 기법으로 root 셸을 획득하는 방법을 보여줍니다.
WRITEUP.md - LLM이 생성한 writeup.
이것은 grsecurity가 설명한 것처럼 해제된 객체와 동일한 타입의 객체를 재할당/재사용할 수 있는 데서 비롯되는 독특한 유형의 커널 취약점을 익스플로잇하기 위해 LLM(Opus 4.6)을 사용한 실험이었습니다.
LLM 없이도 이 버그가 상당히 쉽게 익스플로잇된다는 점을 고려하면 그 결과는 놀랍습니다. 익스플로잇은 직관적이며 Mathias Krause(@_minipli)의 참조 익스플로잇과 거의 동일합니다.
Claude code Opus 4.6 + gdb-mcp
초기 프롬프트:
there is a kernel vulnerability at this link that is used in a ctf, your name is bradley spengler the grsecurity kernel expert who knows how to
exploit kernels. it should work on 32bit only and 6.6LTS kernel .. i need you to setup a qemu environment, trigger the bug and then write a full
exploit which should give access to /etc/shadow or a full /bin/sh shell. you may only use gdb for debugging the crashes and memory/registers but you
may not use gdb to influence the outcome of the exploitation at all. in the end i want a qemu i can login to and test the exploit. here is the link
to the vulnerable code https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a71874379ec8c6e788a61d71b3ad014a8d9a5c08
이런 것들에 정체성 위기를 불어넣는 게 실제로 효과가 있는지는 전혀 모르겠습니다 - 문제 해결에 있어 긍정적인 효과는 없어 보였습니다. :>
처음에 Claude는 동일 타입 재사용(same-type reuse) 유형의 취약점에 대해 많은 정보를 가지고 있지 않은 듯했고, slab 손상 -> rop -> 셸로 이어지는 표준적인 방법을 찾기 시작했습니다.
저는 이 저장소를 다운로드해서 참조용으로 익스플로잇을 검토해보라고 요청하며 넛지를 주었습니다.
이 파일들만으로 익스플로잇 계획을 추론하고 디버깅해서 도출해낼 수 있을 거라 생각했지만, 개입하기 전까지 약 8시간 동안 (제가 잠든 사이에) 혼자 맴돌았습니다.
다음 날 제가 개입해서 참조 익스플로잇이 있는데도 그 익스플로잇을 검토해보니 대충 하고 있었습니다. 참조 코드가 있는데도 자체 check_fd는 더 단순한 루프로 fcntl(F_GETFL)만 확인해서 O_RDONLY 여부를 검사할 뿐, /etc/shadow와 일치시키기 위한 fstat dev/ino 검사가 없었습니다. 그래서 유출에서 shadow 파일을 안정적으로 찾지도 못하고 온갖 엉뚱한 것들과 매칭되고 있었습니다.
stale fd 폴링이 fork 대신 부모 프로세스에서 직접 일어나서, 계속 진행할 수 있었을 상황에서 익스플로잇 전체를 죽여버릴 수 있었습니다.
저는 그 구현이 잘못되었고 참조의 정확한 구현을 사용하라고 지시해야 했습니다. 그 후 익스플로잇은 거의 즉시 작동했습니다.
대상 환경의 자동 설정! 저는 게으르니까 이게 좋았습니다 :)
20분 대기를 단축하는 방법을 알아내서 f_count=1을 찾아 설정해 디버깅을 빠르게 했습니다. 이는 어차피 정상적인 익스플로잇 개발자라면 했을 일로 보입니다.
결국 최소한의 "노력"으로, 제 입장에서는 수동 디버깅에 드는 작업량이 적은 상태로 익스플로잇을 생성해냈습니다. 어느 정도 감독이 필요했습니다.
전체적으로 이 버그는 익스플로잇하는 데 필요 이상으로 훨씬 오래 걸린 느낌이며, 수동으로 했다면 훨씬 짧은 시간에 끝낼 수 있었을 것입니다.
여전히 코드를 읽을 수 있어야 하고, 올바른 방향으로 밀어붙이기 위해 스스로 생각할 수 있는 xdev에 대한 어느 정도의 이해가 필요합니다.
더 나아질까요? 물론입니다..