리눅스 SMB 구현에서 o3를 활용해 원격 0-day를 발견함

• Linux 커널의 SMB3 서버 구현인 ksmbd 감사에서 OpenAI o3 API만으로 원격 use-after-free 취약점 CVE-2025-37899를 찾았고, 별도 에이전트 프레임워크나 도구 사용은 없었음
• 취약점은 SMB logoff 명령 처리 중 해제된 sess->user를 다른 스레드가 계속 접근할 수 있는 문제로, 동시 연결과 세션 공유 상태를 함께 봐야 드러남
• 수동으로 찾았던 CVE-2025-37778을 기준으로 삼은 벤치마크에서 o3는 100회 중 8회 취약점을 찾았고, Claude Sonnet 3.7은 3회, Claude Sonnet 3.5는 0회였음
• 입력을 모든 SMB 명령 핸들러와 연결 처리 코드까지 넓힌 12k LoC / 100k 입력 토큰 조건에서는 기존 취약점 발견률이 100회 중 1회로 떨어졌지만, 같은 결과에서 새 취약점 CVE-2025-37899가 나옴
• 오탐과 무의미한 출력은 여전히 많지만, 실제 취약점 연구에서 사람이 검토·검증할 가치가 있을 만큼 정답이 나올 확률이 높아졌음

---

o3로 ksmbd 취약점을 찾은 실험

• 감사 대상은 Linux 커널 공간에서 SMB3 프로토콜 파일 공유를 구현하는 ksmbd임
• OpenAI o3 모델을 o3 API로 호출했으며, 별도 스캐폴딩, 에이전트 프레임워크, 도구 사용은 없었음
• 발견된 취약점은 CVE-2025-37899이고, 수정 사항은 Linux 커널 커밋에 있음
• 핵심 문제는 SMB logoff 명령 핸들러의 use-after-free로, 참조 카운트가 없는 객체가 다른 스레드에서 접근 가능한 상태로 해제되는 구조임
• 이 취약점은 서버에 대한 동시 연결과 특정 상황에서 공유되는 객체를 함께 이해해야 찾을 수 있음
• 공개적으로 논의된 사례 중 이런 성격의 취약점을 LLM이 찾은 첫 사례로 보인다는 평가가 포함됨

기준 취약점 CVE-2025-37778

• 먼저 수동으로 찾은 CVE-2025-37778을 o3 성능 평가용 벤치마크로 사용함
• 이 취약점은 Kerberos 인증 경로에서 원격 클라이언트의 session setup 요청을 처리할 때 발생하는 use-after-free임
• krb5_authenticate는 sess->state == SMB2_SESSION_VALID이면 sess->user를 해제함
• 이후 코드는 ksmbd_krb5_authenticate가 새 유효 값으로 다시 초기화하거나, -EINVAL 반환 뒤에는 sess->user가 사용되지 않는다는 가정에 의존함
• 실제로는 ksmbd_krb5_authenticate가 sess->user를 다시 초기화하지 않도록 만들 수 있고, krb5_authenticate가 -EINVAL을 반환해도 sess->user 접근이 가능함

벤치마크 구성과 프롬프트

• CVE-2025-37778은 원격 공격 표면에 있고, sess->state == SMB2_SESSION_VALID 조건 유도와 재초기화되지 않는 경로, 해제 후 접근 경로를 모두 판단해야 해서 벤치마크로 사용됨
• 취약점 경로를 설명하는 데 필요한 최소 코드는 약 3.3k LoC로 계산됨
• 실험 입력에는 session setup 명령 핸들러와 이 핸들러가 호출하는 함수들을 호출 깊이 3까지 포함함
• 패킷 수신, 요청 파싱, 명령 핸들러 선택, 핸들러 완료 후 연결 정리 코드도 함께 넣어 데이터 구조 초기화 방식에 대한 추측을 줄임
• 최종 입력은 약 3.3k LoC / 27k 토큰이며, 분석 대상 파일은 session_setup_code.prompt로 공개됨
• 프롬프트에는 다음 조건이 들어감
  • use-after-free 취약점을 찾도록 지시함
  • ksmbd의 역할, 아키텍처, 위협 모델을 높은 수준에서 제공함
  • 오탐 보고보다 미보고를 선호하도록 강하게 유도함
• 전체 프롬프트 파일은 o3_finds_cve-2025-37899 저장소에 있음
• 실행에는 Simon Willison의 llm 도구를 사용함

CVE-2025-37778 벤치마크 결과

• 실험 하네스는 같은 질의를 100회 실행하고 결과를 저장함
• o3는 CVE-2025-37778을 100회 중 8회 찾음
• 100회 중 66회는 버그가 없다고 판단해 false negative가 됨
• 나머지 28회는 false positive였음
• 비교 결과는 다음과 같음
  • Claude Sonnet 3.7: 100회 중 3회 발견
  • Claude Sonnet 3.5: 100회 중 0회 발견
• 이 벤치마크에서는 o3가 Claude Sonnet 3.7보다 2~3배 개선된 결과를 보임
• 샘플 보고서는 o3 결과와 Sonnet 3.7 결과로 공개됨
• o3 출력은 구조와 초점 때문에 사람이 쓴 축약 버그 리포트처럼 읽히지만, 때로 너무 짧아 명확성이 떨어질 수 있음
• Sonnet 3.7 출력은 사고 흐름이나 작업 로그에 가까운 형태로 나타남

모든 명령 핸들러로 확대한 실험

• 다음 실험에서는 session setup 핸들러뿐 아니라 모든 SMB 명령 핸들러 코드를 o3에 제공함
• 명령 핸들러들은 smb2pdu.c에 있으며, 파일 크기는 약 9k LoC임
• 모든 핸들러, 연결 설정과 정리 코드, 명령 핸들러 디스패치 루틴을 합치면 약 12k LoC / 100k 입력 토큰이 됨
• 이 조건에서도 실험은 100회 실행됨
• o3는 기존 Kerberos 인증 취약점 CVE-2025-37778을 100회 중 1회만 찾았고, 입력 토큰 수 증가에 따라 성능 저하가 뚜렷했음
• 같은 결과 묶음에서 기존에 알지 못했던 새로운 취약점인 CVE-2025-37899 보고서가 발견됨

CVE-2025-37899의 취약 경로

• 새 취약점도 sess->user 해제와 관련되어 있지만, 이번에는 session logoff 핸들러에서 발생함
• smb2_session_logoff는 다음 순서로 동작함
  • ksmbd_close_session_fds(work) 호출
  • ksmbd_conn_wait_idle(conn) 호출
  • 세션 상태를 SMB2_SESSION_EXPIRED로 설정
  • sess->user가 있으면 ksmbd_free_user(sess->user)로 해제하고 sess->user = NULL로 설정
• o3 보고서의 취약 시나리오는 다음과 같음
  • SMB 3.0 이상에서 두 번째 전송이 기존 세션에 바인딩되고 conn->binding == true가 됨
  • Worker-A가 다른 연결 C2에서 WRITE 같은 일반 요청을 처리함
  • smb2_check_user_session()은 work->sess에 기존 struct ksmbd_session 포인터를 저장하고 세션 참조 카운트를 증가시키지만, sess->user에는 별도 참조를 잡지 않음
  • Worker-B가 첫 번째 연결 C1에서 같은 세션에 대한 SMB2 LOGOFF를 처리하고 smb2_session_logoff()를 실행함
  • ksmbd_conn_wait_idle(conn)은 해당 연결의 실행 중 요청만 기다리며, 같은 세션을 쓰는 다른 연결의 요청까지 기다리지 않음
  • Worker-A가 계속 실행되며 user_guest(sess->user), ksmbd_compare_user(sess->user, …), sess->user->uid 같은 접근을 수행할 수 있음
• 타이밍에 따라 해제된 slab 객체를 가리키는 use-after-free가 되거나, sess->user = NULL 이후 읽으면 NULL 역참조로 DoS가 될 수 있음

잘못된 수정안과 o3 결과의 가치

• CVE-2025-37778에 대해 처음 제안한 수정은 ksmbd_free_user(sess->user) 뒤에 sess->user = NULL을 추가하는 방식이었음
• CVE-2025-37899 보고서를 읽은 뒤 이 수정이 불충분하다는 점이 드러남
• logoff 핸들러는 이미 sess->user = NULL을 수행하지만, SMB 프로토콜이 서로 다른 두 연결을 같은 세션에 바인딩할 수 있어 여전히 취약함
• Kerberos 인증 경로에서도 sess->user가 해제된 직후 NULL로 설정되기 전의 짧은 창에 다른 스레드가 접근할 수 있음
• o3의 일부 보고서는 동일한 오류를 냈지만, 일부는 세션 바인딩 가능성 때문에 sess->user = NULL만으로는 충분하지 않다는 점을 잡아냄
• false positive 대비 true positive 비율이 높아 모든 보고서를 충분히 꼼꼼히 검토했을지 확실하지 않다는 한계가 있음

취약점 연구에서의 실무적 위치

• LLM은 창의성, 유연성, 일반성 측면에서 기존 프로그램 분석 기법보다 사람 코드 감사자에 더 가까운 위치에 있음
• 비교 대상으로는 symbolic execution, abstract interpretation, fuzzing이 언급됨
• GPT-4 이후 LLM의 취약점 연구 가능성은 있었지만, 실제 문제에서는 기대만큼의 결과가 부족했음
• o3는 코드 추론, 질의응답, 프로그래밍, 문제 해결에서 실제 취약점 연구자의 성능을 높일 수 있을 만큼 동작함
• 여전히 완전하지 않고, 무의미한 결과를 생성해 사용자를 좌절시킬 가능성이 큼
• 달라진 점은 실제 문제에 적용해볼 만큼 정답이 나올 확률이 처음으로 충분히 높아졌다는 판단임

[GN⁺]

Hacker News 의견들

• 작은 부분이지만, 작성자의 프로젝트 구성 방식이 유용해 보임. 시스템 프롬프트, 배경 정보, 보조 지시사항을 각각 .prompt 파일로 만들고 [1], llm으로 실행하는 방식임
  좋은 LLM 활용도 다른 엔지니어링 도구처럼 체계적이고, 설계 제약을 균형 있게 반영한 사려 깊은 명세 중심의 엔지니어링 사고가 필요하다는 걸 보여줌
  [1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899

  • 그렇게 받아들이는 게 재미있는 게, 글쓴이가 바로 그 부분만은 그냥 감으로 했다고 인정했기 때문임

    In fact my entire system prompt is speculative so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering

  • 이런 서로 다른 방법론은 어떻게 벤치마크해야 하는지 모르겠음
    전부 감에 의존한 주문처럼 보임. “당신은 취약점 발견 전문가입니다”, “오탐 없이 실제 취약점만 보고하세요” 같은 문구나, 모델이 왠지 좋아하는 것 같아서 가짜 HTML 태그로 정리하는 방식들임. 여기서 어디가 엔지니어링인지 모르겠음
  • 본질적으로 불안정하고 예측 불가능한 시스템에 엔지니어링 원칙을 적용해서 통제감을 얻으려는 모습이 흥미로움
    저런 프롬프트는 지시가 아니라 힌트라고 불러야 함. 지금의 모든 LLM은 프롬프트가 자기의 단 하나의 상위 목표, 즉 참이든 아니든 답을 내놓는 것과 충돌하면 프롬프트를 무시함
  • 재미있는 사실은, LLM에게 프롬프트 구성 모범 사례를 물어보면 이런 방향으로 힌트를 준다는 것임
    LLM에게 프롬프트 작성을 도와달라고 하는 것도 놀랄 만큼 효과적임. 내 프롬프트 조각들도 전부 LLM 도움으로 설계했음
    개인적으로는 전부 org-mode 파일에 넣어두고 필요할 때 ChatGPT 대화에 복사해 붙여넣음. 더 “토론형” 상호작용을 선호하지만 접근 방식은 같음
  • 결국 핵심은 정리 정돈임: https://taoofmac.com/space/blog/2025/05/13/2230

• 글에서는 신호 대 잡음비가 대략 1:50이라고 함. 작성자는 이 코드베이스를 아주 잘 알고 있어서 잡음 속 신호를 선별하기 좋은 위치에 있음
  이 부분을 자동화하는 데서 진짜 성과가 나올 테니 계속 지켜볼 생각임

  • 몇 년 동안 테이크홈 면접 문제를 몇 개 만들었는데, 숙련 개발자에게는 짧고 쉽지만 언어를 모르면 어려운 문제로 설계했음. 전부 실제 업무에서 풀었던 문제를 최소 형태로 줄인 것임
    새로운 최전선 LLM이 나올 때마다, 입력을 학습 데이터로 쓰는 모델은 제외하고, 그 면접 문제들을 돌려봄. 첫 시도에서 동작하는 답변 비율이 꾸준히 1:10 정도에 머무르고, 자기 실수를 찾게 하려면 10라운드 이상 찔러봐야 하는 경우도 많아서 놀랐음
    그래서 더 난해한 주제에서 이 정도 신호 대 잡음비는 납득됨
  • 버그 탐지에서 신호 대 잡음비를 크게 높이는 시스템을 만들고 있고, 동시에 유명한 소프트웨어 에이전트 전반을 철저히 벤치마크해 왔음
    결과 폭이 꽤 넓었고, 곧 있을 컨퍼런스 발표에서 전부 공개할 예정이라 기대해도 좋음. 이 분야의 현재 상태를 꽤 잘 보여줄 것임
    수정: 표현이 혼란스러웠음
  • 얼마 전에 생각했는데, Linux 커널의 모든 git 변경, 메일링 리스트 등을 대상으로 미세 조정 같은 걸 하는 게 가능하지 않을까 싶었음
    그런 LLM은 수년 동안 코드베이스에서 일하며 온갖 특성을 익힌 사람에 가까운 합성 버전이 되지 않을까 함
    긴 문맥에 정말 많은 걸 넣을 수 있지만, 어떤 코드베이스는 코드만으로도 이미 20만 토큰이라 잘 모르겠음
  • 이 부분의 자동화는 간단할 것 같음. 일반적으로 어떤 작업을 수행하는 의미적 능력 X가 있는 LLM은, 같은 작업에 대한 N개의 답변 중 어느 답이 가장 나은지 확인하는 능력이 X보다 큼
    특히 몇 주 전 여기 올라왔던 RAInk처럼 이진 토너먼트 방식이면 더 그렇고, 서로 다른 LLM 간 합의를 쓰는 방법도 있음. 여기서 Gemini 2.5 PRO를 쓰지 않은 게 놀라운데, 내 경험상 이런 종류의 작업에는 가장 강력한 LLM임
  • 1:50은 건초더미에서 바늘 찾기에는 훌륭한 탐지 비율임

• 이 글에서 가장 흥미롭고 중요한 부분은 작성자가 각 모델마다 취약점 검색을 100번 돌렸다는 점이었음
  내가 지금까지 대형 언어 모델로 시도한 대부분의 문제에 쓰려던 계산량보다 훨씬 많지만, 어쩌면 모델을 그냥 계속 돌려야 할지도 모르겠음

  • 글에 쓰지 않았다는 걸 깨달았는데, 궁금하다면 10만 토큰 버전을 100번 실행하는 데 약 116달러가 들었음
  • 제로데이는 큰돈에 팔릴 수 있고, 버그 바운티로 가도 돈이 됨. LLM 비용은 그에 비하면 양동이 속 한 방울일 것임
    추론 비용이 거의 0에 가까워지면 사이버 보안 세계가 어떻게 될지 모르겠지만, 오늘날과는 아주 다른 공간이 될 것임
  • 돈만 많으면 충분함~
  • “모델마다 100번”은 상당한 양의 에너지 소모를 뜻함. C 기반 코드베이스에서 가장 흔한 취약점을 찾았다는 성과도 덜 대단해 보임
    오히려 사치와 낭비를 축하하는 일에 가까워짐. 전 지구적 기후변화에 직면해 있는데도, 1950년대처럼 사소한 일에 자원을 계속 태우고 있음

• 운이 아주 좋았거나, 짐작대로 Gemini 2.5 PRO가 이 취약점을 더 쉽게 찾아내는 듯함. 성공률이 높아서 다음 프롬프트를 몇 번 돌리는 것만으로 충분했음: https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd...

• 최근 이런 패턴이 반복되고 있음
  명확한 정의와 평가 함수가 있는 문제가 있으면, LLM이 해 공간을 줄이게 함. LLM은 패턴 재구성에 매우 강하고, 해답이 기존에 알려진 것과 비슷한 패턴이면 잘 작동할 수 있음
  이 경우 문제는 특정 유형의 보안 취약점이고, 평가자는 전문가임. 규모는 다르지만 LLM을 유전적 최적화에 사용하는 최근 시도들과 정신적으로 비슷함
  “Mathematical discoveries from program search with large language models”도 흥미로운 읽을거리이고, 예전에 HN에도 올라왔던 것으로 기억함
  https://www.nature.com/articles/s41586-023-06924-6
  다만 이 실험만 근거로 LLM이 코드에 대해 추론한다고 결론 내리는 건 개인적으로는 조금 무리라고 봄

• 이게 진짜이길 바라고, curl에서 계속 벌어지는 일과 같은 게 아니길 바람
  [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

• 이게 LLM으로 발견한 첫 취약점이라는 주장에는 확신이 안 감. 예를 들어 OSS-Fuzz [0]는 퍼징으로 몇 건을 찾았고, Big Sleep도 에이전트 방식으로 찾았음 [1]
  [0] https://security.googleblog.com/2024/11/leveling-up-fuzzing-...
  [1] https://googleprojectzero.blogspot.com/2024/10/from-naptime-...

  • LLM으로 발견한 첫 취약점은 확실히 아님 =) 좀 더 명확히 썼어야 했을 수도 있음
    글에서 말한 건 “취약점을 이해하려면 서버에 대한 동시 연결과, 특정 상황에서 여러 객체를 어떻게 공유하는지 추론해야 한다. o3는 이를 이해하고, 참조 카운트되지 않은 특정 객체가 다른 스레드에서 여전히 접근 가능한 상태로 해제되는 위치를 찾아냈다. 내가 아는 한, 이런 성격의 취약점을 LLM이 찾은 것에 대한 첫 공개 논의다”였음
    말하고 싶었던 건, 내가 아는 한 LLM이 그런 종류의 버그, 즉 사소하지 않은 양의 코드와 공유 자원 동시 접근에서 비롯되는 버그를 찾아낸 공개 문서화로는 처음이라는 점임. 적어도 나에게는 LLM 발전의 흥미로운 표식임

• 제로데이 발견의 가치를 생각하면, 몇백 번의 API 호출만으로 안정적으로 찾을 수 있다면 전 세계 거의 모든 정보기관이 여기에 돈을 쏟아부을 것임
  특히 많은 예제로 모델을 미세 조정할 수 있다면 더 그렇고, OpenAI 같은 곳은 공개 API로 그런 걸 해주지는 않을 것 같음

  • 맞음. 출력 통제, 즉 검열을 둘러싼 엔지니어링과 이용약관 때문에, 가능한 버그를 찾도록 유도하되 결과로는 허용하지 않는 동기가 생김
    정부기관이나 다른 조직에는 당연히 이런 제약이 문제가 되지 않음. 그 외 모두에게만 적용될 뿐임. 그래서 사람들은 이런 제한이 없는 다른 모델과 에이전트를 쓰게 될 것임
    중요한 소프트웨어 곳곳에 많은 취약점이 존재한다고 봐도 안전함. 이제 그것들을 찾을 수 있게 됐음. 컴퓨터 보안과 해킹에 군비 경쟁 게임이론이 적용되는 상황이 시작될 것임. 아마 예상보다 더 빨리 올 가능성이 큼

• 커널 개발자 몇 명이 이 버그를 “검증”한 건 알겠지만, 실제로 개념 증명을 만들고 테스트한 사람이 있었는지 궁금함
  절차에서 이렇게 핵심적인 부분인데 개념 증명이 완전히 빠져 있음. 개념 증명이 없으면 중간에 어떤 문제가 생길지 알 수 없고, 따라서 악용 가능성이나 영향을 판단할 수 없음. 적어도 작성자가 검증 없이 원격 코드 실행이라고 부르지는 않았음
  하지만 작성자와 개발자들이 놓쳤거나 o3가 다뤘다고 가정했지만 실제로는 o3의 문맥 밖에 있던 퍼즐 조각 하나가 있어서, 이 취약점 자체를 무효화한다면 어떻게 되나?
  그런 게 있다고 말하는 것도 아니고, 작성자의 일을 대신 해줄 시간을 쓰겠다는 것도 아님. 다만 이 보고서는 완전히 검증된 게 아니며, 앞으로 LLM 취약점 연구 분야에 영향력 있는 블로그 글이 될 가능성을 생각하면 위험한 선례처럼 느껴짐
  개인적으로는 모델이 생성한 어떤 취약점 보고서에도 PoC || GTFO를 그 어느 때보다 엄격하게 적용해야 한다고 봄
  o3가 이전 모델이나 다른 현행 모델보다 훨씬 낫다는 관점은 여전히 남고, 방법론도 흥미로움. 사람들이 특정한 것에 주목하게 만들기 위해 문구를 그렇게 쓰고 싶은 욕구와 필요는 이해함. 이게 클릭베이트 문제임. 하지만 제발 더 잘해야 함. 개념 증명을 만들고 주장을 검증해야지, 게으르면 안 됨. 취약점 연구자들의 연구 방식에 영향을 줄 수 있는 블로그 글을 쓴다면, 이론적 가정이 아니라 검증을 장려해야 함. 그렇지 않으면 검증 가능하고 입증된 보고서로 시스템 이해를 깊게 하는 대신, 거짓이지만 그럴듯한 보고가 무지를 퍼뜨리게 됨

  • 작성자임. 예, 개념 증명을 만들었음. 예, KASAN 보고와 크래시를 유발했음
  • use-after-free로 크래시를 유발하는 개념 증명을 원하는 건지, 아니면 완전한 원격 코드 실행 개념 증명만 만족하겠다는 건지 묻고 싶음

• 대부분의 내 프롬프트 개발 세션이 어떻게 흘러가는지 완벽하게 포착한 아름다운 작은 대목이 있음

  I tried to strongly guide it to not report false positives, and to favour not reporting any bugs over reporting false positives. I have no idea if this helps, but I’d like it to help, so here we are. In fact my entire system prompt is speculative in that I haven’t ran a sufficient number of evaluations to determine if it helps or hinders, so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering. Once I have ran those evaluations I’ll let you know.