o3로 리눅스 커널 SMB 구현의 원격 제로데이(CVE-2025-37899)를 찾은 과정
이 글은 OpenAI의 o3 모델을 활용해 리눅스 커널의 SMB(ksmbd) 구현에서 제로데이 취약점(CVE-2025-37899)을 발견한 과정을 시간순으로 상세하게 설명합니다. 글쓴이는 복잡한 도구 없이 o3 API만을 사용해 취약점을 찾았고, 이 경험을 통해 LLM(대형 언어 모델)이 코드 분석 및 취약점 연구에 얼마나 큰 도약을 이뤘는지 강조합니다.
1. ksmbd와 o3의 만남: 배경과 동기
-
ksmbd란?
- 리눅스 커널 공간에서 SMB3 프로토콜을 구현한 파일 공유 서버입니다.
- 네트워크를 통한 파일 공유를 위해 사용됩니다.
-
글쓴이의 동기
- 원래는 LLM 관련 도구 개발에서 잠시 벗어나 ksmbd의 취약점을 수동으로 점검하려 했으나, o3가 출시되자 ksmbd에서 발견한 버그들을 o3의 벤치마크로 삼아보고 싶어졌습니다.
"o3 LLM은 코드에 대한 추론 능력에서 큰 도약을 이뤘습니다. 취약점 연구에 종사한다면 이제는 정말 주목해야 할 때입니다."
2. 벤치마크용 취약점: CVE-2025-37778 (Kerberos 인증 취약점)
-
CVE-2025-37778:
- use-after-free(이미 해제된 메모리를 사용하는) 취약점.
- Kerberos 인증 경로에서 원격 클라이언트의 "session setup" 요청을 처리할 때 발생.
-
취약점의 원인 코드:
if (sess->state == SMB2_SESSION_VALID) ksmbd_free_user(sess->user); retval = ksmbd_krb5_authenticate(sess, in_blob, in_len, out_blob, &out_len); if (retval) { ksmbd_debug(SMB, "krb5 authentication failed\n"); return -EINVAL; }sess->state가SMB2_SESSION_VALID이면sess->user를 해제.- 이후
ksmbd_krb5_authenticate가sess->user를 재초기화하지 않을 수 있고,
krb5_authenticate가-EINVAL을 반환해도 다른 곳에서sess->user를 사용할 수 있음.
"이 취약점은 리눅스 커널의 원격 공격 표면에 속해 있다는 점에서 흥미롭습니다."
-
LLM(특히 o3)에게 어려운 점
sess->state == SMB2_SESSION_VALID조건을 어떻게 만들지 추론해야 함.ksmbd_krb5_authenticate가sess->user를 재초기화하지 않는 경로를 찾아야 함.- 해제된
sess->user가 다른 코드에서 사용될 수 있음을 파악해야 함.
-
분석에 필요한 코드량: 약 3,300줄(3.3k LoC)
- 패킷 수신부터 취약점이 트리거되는 경로의 모든 함수 포함.
3. LLM(특히 o3)에게 코드 제공 방식
-
이상적: 전체 저장소 코드를 LLM에 입력 → 결과 도출
- 하지만 컨텍스트 윈도우 한계와 성능 저하로 현실적으로 불가능.
-
실험적 접근:
- 각 SMB 명령 핸들러별로 코드와 관련 함수(호출 깊이 3까지)를 LLM에 제공.
- 데이터 수신, 요청 파싱, 핸들러 선택, 연결 해제 코드까지 포함.
- 총 약 3.3k LoC, 27k 토큰.
-
프롬프트 설계
- use-after-free 취약점 탐지 지시
- ksmbd의 개요, 아키텍처, 위협 모델 간단 설명
- 거짓 양성(false positive) 최소화 강조
"거짓 양성은 최대한 피하고, 차라리 아무 버그도 보고하지 않는 쪽을 선호하라고 강하게 유도했습니다."
-
실험 방법
llm툴로 100회 반복 실행, 결과 저장
4. o3의 벤치마크 결과
- o3: 100회 중 8회 취약점 정확히 탐지, 66회는 버그 없음(거짓 음성), 28회는 거짓 양성
- Claude Sonnet 3.7: 3회 탐지
- Claude Sonnet 3.5: 0회 탐지
"o3의 결과는 마치 사람이 쓴 버그 리포트처럼 구조적이고 명확합니다. 반면 Sonnet 3.7은 생각의 흐름이나 작업 로그에 가깝죠."
- o3의 장점
- 결과가 간결하고 명확해 이해하기 쉽다.
- 단, 때로는 너무 간결해 오히려 명확성이 떨어질 수 있음.
5. o3가 찾은 제로데이: CVE-2025-37899 (세션 로그오프 취약점)
-
실험 확장:
- 모든 명령 핸들러 코드(약 9k LoC) + 연결 설정/해제 코드 포함 → 총 12k LoC, 100k 토큰
- 100회 실행
-
결과
- Kerberos 인증 취약점은 1회만 탐지(성능 저하)
- 새로운 취약점(제로데이, CVE-2025-37899) 발견!
- 세션 로그오프 핸들러에서
sess->user를 해제하는 과정에서 발생
- 세션 로그오프 핸들러에서
-
취약점 코드:
if (sess->user) { ksmbd_free_user(sess->user); sess->user = NULL; } -
o3의 설명
"한 ksmbd 워커 스레드가 sess->user를 사용하는 동안,
다른 스레드가 같은 세션에 대해 SMB2 LOGOFF를 처리하며 해당 구조체를 해제합니다.
포인터를 보호하는 동기화가 없어 첫 번째 스레드는 해제된 메모리를 참조하게 됩니다.
이는 커널 메모리 손상 및 임의 코드 실행로 이어질 수 있는 전형적인 use-after-free입니다." -
취약점 발생 경로 요약
- 두 번째 트랜스포트가 기존 세션에 바인딩됨
- 워커-A가 일반 요청 처리 중 sess->user를 참조(참조 카운트 없음)
- 워커-B가 같은 세션에 대해 LOGOFF 처리, sess->user 해제
- 워커-B는 자신의 연결에서만 대기, 다른 연결의 작업은 기다리지 않음
- 워커-A가 계속 sess->user를 참조 → 이미 해제된 메모리 접근
if (user_guest(sess->user)) // 해제 후 참조 ksmbd_compare_user(sess->user, …) sess->user->uid- 타이밍에 따라 use-after-free(슬랩 오브젝트 재사용) 또는 NULL 참조(DoS) 발생
6. o3의 발견이 준 교훈
- 기존 패치의 한계
- 글쓴이도 과거에
sess->user = NULL로 패치했으나,
o3의 리포트를 보고 세션 바인딩 상황에서 이 방법이 불충분함을 깨달음.
- 글쓴이도 과거에
"o3의 리포트를 읽고 나서야, SMB 프로토콜이 두 개의 연결이 같은 세션에 바인딩될 수 있음을 다시 떠올렸습니다.
이로 인해 해제 후 짧은 시간 동안 다른 스레드가 sess->user를 사용할 수 있습니다."
-
o3의 리포트 중 일부도 같은 실수를 했지만,
다른 리포트에서는 이 점을 정확히 지적"o3를 활용했다면, 이론적으로는 더 나은 패치를 할 수 있었을 겁니다."
-
신호 대 잡음비
- 현재는 약 1:50(참/거짓 양성) 수준이지만,
앞으로 개선될 여지가 크다고 전망
- 현재는 약 1:50(참/거짓 양성) 수준이지만,
7. 결론: LLM의 코드 분석 능력, 인간에 근접하다
- LLM(특히 o3)의 코드 분석 능력은
기존의 심볼릭 실행, 추상 해석, 퍼징 등과 비교해
창의성, 유연성, 범용성 면에서 인간 코드 감사자에 훨씬 가깝다.
"GPT-4 이후로 LLM의 취약점 연구 가능성에 대한 기대가 있었지만,
실제 문제에서 그 기대를 충족한 적은 거의 없었습니다.
o3는 그 기대를 현실로 바꿨습니다."
- 한계
- 여전히 엉뚱한 결과를 내놓을 수 있고, 실망스러울 때도 많음
- 하지만 정확한 결과를 얻을 확률이 충분히 높아져,
실제 문제에 적용할 가치가 생겼다는 점이 가장 큰 변화
⭐️ 요약 키워드
- o3 모델
- ksmbd (리눅스 커널 SMB 서버)
- use-after-free
- CVE-2025-37778 (Kerberos 인증 취약점)
- CVE-2025-37899 (세션 로그오프 제로데이)
- 세션 바인딩
- LLM의 코드 추론 능력
- 신호 대 잡음비
- 자동화된 취약점 탐지
- 인간-LLM 협업
📝 마무리
이 글은 o3와 같은 LLM이 실제 코드 취약점 연구에 어떻게 활용될 수 있는지,
그리고 그 과정에서 인간 연구자의 효율성과 정확성을 어떻게 높일 수 있는지
생생한 사례와 함께 보여줍니다.
아직 완벽하진 않지만, 이제는 LLM을 적극적으로 활용할 시점임을 강조합니다. 🚀