lcfr-eth/cve-2024-14027_slopAI/Claude를 사용하여 테스트로 생성된 CVE-2024-14027용 익스플로잇
이 익스플로잇은 6.6.51 커널에서 Qemu debian 설치를 사용하여 테스트되었습니다.
exploit.c - shadow 파일을 유출합니다.
exploit_dc.c - 더블 클로즈(double close) 방식을 시연하여 루트 셸을 획득합니다.
WRITEUP.md - LLM이 생성한 분석 보고서입니다.
이 프로젝트는 LLM(Opus 4.6)을 사용하여 grsecurity에서 설명한 동일 유형 객체 재사용(same-type object reuse) 취약점을 악용하는 실험이었습니다.
결과는 버그 자체가 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는 동일 유형 재사용 취약점에 대한 정보가 많지 않았고, 표준적인 slab 손상 -> rop -> 셸 획득 방식을 찾기 시작했습니다.
이 저장소를 다운로드하여 참조 익스플로잇으로 검토하도록 요청했습니다.
이 파일들만으로 추론하고 디버깅하여 익스플로잇 계획을 세울 수 있을 거라고 생각했지만, 제가 개입하기 전까지 약 8시간 동안 혼자서 빙빙 돌기만 했습니다(제가 잠든 사이).
다음 날 제가 개입하여 익스플로잇을 검토했을 때, 참조 익스플로잇이 있었음에도 불구하고 절반만 수행하고 있었습니다. 참조 코드가 있었음에도 check_fd 함수는 /etc/shadow와 일치시키기 위한 fstat dev/ino 검사 없이 단순히 fcntl(F_GETFL)로 O_RDONLY를 확인하는 더 간단한 루프를 사용하고 있었습니다. 따라서 유출 과정에서 shadow 파일을 안정적으로 찾지 못하고 온갖 엉뚱한 파일을 매칭했습니다.
stale fd 폴링이 자식 프로세스를 포크하지 않고 부모 프로세스에서 직접 이루어져 익스플로잇 전체가 중단될 수 있었습니다. 원래는 계속 진행될 수 있었어야 했습니다.
구현이 잘못되었음을 지시하고 참조의 정확한 구현을 사용하도록 해야 했습니다. 그 후 익스플로잇은 거의 즉시 작동했습니다.
대상 환경의 자동 설정! 게으른 저에게는 아주 좋았습니다 :)
20분 대기 시간을 단축하기 위해 f_count=1을 찾아 설정하여 디버깅 속도를 높이는 방법을 알아냈습니다. 이는 정상적인 익스플로잇 개발자라면 당연히 했을 일입니다.
결국 수동 디버깅에 대한 최소한의 "노력"으로 익스플로잇을 생성했습니다. 약간의 감독이 필요했습니다.
종합적으로 보면, 이 버그를 익스플로잇하는 데 예상보다 훨씬 오래 걸렸으며 수동으로 수행했다면 훨씬 적은 시간이 걸렸을 것 같습니다.
여전히 코드를 읽을 수 있어야 하고, xdev에 대한 어느 정도의 이해가 있어야 올바른 방향으로 유도할 수 있습니다.
더 나아질까요? 물론 그렇겠죠.