▲

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

 (sean.heelan.io)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • OpenAI o3 모델을 활용해 리눅스 커널의 SMB 구현에서 원격 0-day 취약점(CVE-2025-37899)을 발견한 경험을 공유함
  • ksmbd의 코드에 대해 LLM 분석 능력을 벤치마킹하는 과정에서, 기존에 수동으로 찾은 취약점을 기준으로 LLM의 성능을 비교 실험함
  • 취약점 탐지 과정에서 함수별로 컨텍스트를 구성하고 적절한 프롬프트를 제공하여 o3가 취약점을 인식할 수 있도록 설계함
  • 실험 결과 o3는 기존 LLM 대비 2~3배 높은 정확도로 취약점을 찾아내며, 새로운 형태의 use-after-free 버그도 동시에 자동 발견함
  • LLM, 특히 o3와 같은 최신 모델은 코드 감사와 취약점 연구에 있어 인간 접근 방식과 유사한 유연성·창의성을 보여주며, 실무 활용 가치가 높아짐

서론

이 글에서는 OpenAI의 o3 모델을 이용하여 리눅스 커널의 SMB 구현(ksmbd)에서 원격 0-day 취약점을 어떻게 발견했는지 소개함. 단순히 o3 API만 활용했으며 별도의 프레임워크나 도구 없이 실험을 진행함. ksmbd는 리눅스 커널 내에서 SMB3 프로토콜을 구현해 네트워크 파일 공유를 담당하는 서버임. LLM 관련 개발에서 잠시 쉬고자 시작한 취약점 감사를 계기로, o3가 실제 버그를 얼마나 잘 찾을 수 있는지 벤치마크를 실시함. 여기서는 특히, o3가 찾은 제로데이 취약점인 CVE-2025-37899에 초점을 맞춤.

이 취약점은 SMB ‘logoff’ 명령어의 처리과정에서 발생하는 use-after-free 문제임. 이는 서버에 대한 동시 연결 상황과 특정 오브젝트를 여러 스레드가 공유하는 방식에 대한 이해를 요구함. o3는 이러한 동시성 이슈와 객체 관리상의 오류를 맥락 속에서 파악해 취약점을 검출함. 이는 LLM이 이런 유형의 취약점을 발견한 최초의 공개 사례임.

주요 메시지는, o3를 통해 LLM의 코드 분석 및 논리 능력이 한 단계 도약했음을 보여주며, 취약점 연구자라면 반드시 이 흐름에 주목해야 함을 강조함. LLM이 전문가를 대체하지는 않으나, 이미 전문가의 생산성과 효율성을 획기적으로 높여주는 도구로 발전했음을 시사함. 1만 줄 이하의 코드라면 o3로 대부분의 문제 탐지 및 해결에 실질적인 도움을 받을 수 있음.

CVE-2025-37778을 활용한 o3 벤치마킹

벤치마크 배경과 취지

먼저, 직접 수동으로 발견한 취약점인 CVE-2025-37778(이하 kerberos 인증 취약점)을 기준점으로 삼아 o3의 취약점 감지 능력을 평가함. 이는 클라이언트 인증 과정에서 세션 상태가 특정 조건을 만족할 때 use-after-free가 발생하는 문제임.

  • 세션 상태가 SMB2_SESSION_VALID일 때 유저 객체를 메모리에서 해제
  • 이후 인증이 실패하면 유저 객체가 다시 초기화되지 않고, 그 상태로 접근이 가능해져 use-after-free 발생
  • 관련 경로 전체를 파악하려면 약 3,300줄의 코드를 따라가야 하므로 적당한 난이도를 가진 벤치마크 과제임

분석 컨텍스트 구성

실험에서는 실제 자동화된 취약점 탐지 시스템 관점에서, LLM에 주어질 컨텍스트(코드 영역)를 세심히 구성함. SMB 명령어 핸들러 단위로 주요 함수 및 하위 함수들을 3단계 콜 뎁스까지 포함시켜, 논리적 연관 코드를 모두 입력함(총 3.3k LoC, 약 27k 토큰). 데이터 파싱, 요청 분기, 접속 해제 등 관련 함수도 포함되어야 신뢰성 높은 결과를 얻을 수 있음.

구체적으로 사용한 프롬프트와 입력 자료는 관련 Github 저장소에서 확인 가능함. LLM에게는 아래와 같은 조건을 줌:

  • use-after-free 취약점을 탐지하도록 명확히 지시함
  • ksmbd의 기본 구조와 위협 모델 간략히 설명
  • 허위 양성(False Positive) 방지를 위한 유도 프롬프트 사용

실제 쿼리는 llm 커맨드라인 툴로 반복 실행해 실험 결과를 수집함(N=100).

벤치마크 실험 결과

  • o3 : 100번 중 8번 kerberos 인증 취약점 탐지, 66번 미탐지(누락), 28번 허위 양성 보고
  • Claude Sonnet 3.7 : 3번만 탐지
  • Claude Sonnet 3.5 : 100번 모두 탐지 실패

결국 o3는 기존 LLM 대비 2~3배 이상 높은 정확도를 기록함. 또한 실제 o3의 출력은 인간 보안연구자가 작성한 요약 리포트처럼 간결함. 반면 Sonnet 3.7 결과는 과정 중심의 작업로그에 가까운 인상을 주며, 장점도 단점도 공존함.

o3를 통한 실제 0-day (CVE-2025-37899) 발견

대규모 코드 입력 환경 실험

kerberos 취약점 외에도, SMB 명령 핸들러 전체(약 9,000줄)를 포함해 o3로 전체적인 취약점 탐지를 시도함. 각종 핸들러, 연결/해제 코드 등 전체를 합쳐 총 약 12k LoC(약 10만 토큰)를 한 번에 입력함. 100번 반복 실행 시, kerberos 인증 취약점은 오직 1회만 탐지되어 성능 저하가 명확하나, 주요 목적은 더 많은 코드 범위에서의 LLM 활용성 실험임.

이번 실험에서 발견된 새 취약점

그러던 중 o3가 kerberos 인증 이외에 신규로 발견한 use-after-free 버그가 발견됨. 바로 세션의 logoff 핸들러에서, 두 스레드가 동시 연결 상태에서 세션의 user 객체를 공유/접속하면서 한 스레드가 객체를 해제한 후 다른 스레드가 이를 계속 참조할 수 있는 동시성 문제임.

o3의 취약점 자동 리포트 요약
  • 두 개의 워커 스레드가 협동하여, 하나는 세션 해제(logoff) 수행 중 user 객체를 메모리에서 해제하고, 다른 하나는 기존 세션에서 그 user 객체를 계속 사용
  • 해제 직후(아직 NULL로 초기화되기 전)에 또 다른 경로에서 dereference가 발생하면 classic use-after-free
  • 타이밍에 따라 NULL dereference로 인한 DoS도 발생 가능
  • 커널 메모리 손상 및 임의 코드 실행로 이어질 수 있음

자동 보고서를 통해 얻은 인사이트

이 자동 리포트에서, 기존 kerberos 인증 취약점의 수정 방식이(해제 직후 NULL로 세팅) 로그오프 처리에서는 근본적 해결책이 아님을 깨달음. 즉, 세션 바인딩과 스레드간 공격 벡터를 고려해야 안전성이 보장됨. o3 역시 일부 보고서에서는 이 점을 간파하여 ‘더 강력한’ 수정책 제시가 가능함을 실증함.

결론

LLM, 특히 o3와 같은 최신 모델은 코드의 창의적·유연한 분석 면에서 기존 기법보다 인간 보안 연구자에 훨씬 가까운 성능을 보여줌. 최근까지는 이론적으로 가능성이 거론되어 왔으나, 실제 사례에서 현실적으로 ‘도움이 되는 수준’에 도달한 것은 o3가 처음임. 물론 o3 역시 여전히 오탐·누락 가능성이 존재하나, 실제로 쓸모 있는 결과를 내놓을 가능성이 높아져 실무 투입이 의미 있는 시점이 되었음. 이제 취약점 연구자나 개발자가 자신의 업무 플로우에 LLM을 효율적으로 결합하는 방법을 찾아야 할 타이밍임.

▲
GN⁺ 8시간전  [-]
Hacker News 의견

  • 저자는 시스템 프롬프트, 배경 정보, 보조 명령 등 각각을 별도로 .prompt 파일로 만들어 구성하고, 이를 llm을 통해 실행하는 방식으로 프로젝트를 관리함을 밝혔음
    이렇게 체계적으로 LLM을 활용하는 방식이 마치 다른 엔지니어링 도구처럼 꼼꼼한 설계적 사고와 세심한 사양 균형 조정이 필요함을 보여준다고 느낌
    관련 프로젝트는 여기에서 확인 가능

    • 흥미롭게도 저자가 해당 부분에 대해 "사실 내 시스템 프롬프트 전체가 추측에 기반하고, 과학이나 엔지니어링과는 거리가 멀다"고 솔직히 밝혔다는 점이 웃기게 느껴짐

    • 서로 다른 프롬프트 작성법들이 있지만 실제로 평가하거나 비교할 마땅한 기준이 없어 마치 즉흥적인 주문 외우기 같다는 생각임
      예를 들어 "너는 취약점 찾기 전문가야", "가짜가 아닌 진짜 취약점만 알려줘" 같은 지시나, 모델이 잘 반응한다고 추정되는 임의의 HTML 태그로 구분짓는 일 등
      엔지니어링적 요소가 실제로 어디에 들어가는지 의문

    • 본질적으로 불안정하고 예측 불가한 시스템을 제어하려는 마음에 엔지니어링 원칙을 들고 오는 게 재밌게 느껴짐
      이런 프롬프트는 차라리 ‘힌트’라는 이름이 더 적합함
      요즘의 모든 LLM은 설령 프롬프트가 모순되더라도, 답변을 (진짜인지 여부와 상관없이) 반드시 제공하려는 본질적 목표 하에 프롬프트를 무시하는 경우가 많음

  • 해당 글에서 신호 대 잡음 비율이 약 1:50이라고 언급됐는데, 저자가 코드베이스에 대해 잘 알고 있으므로 의미 있는 신호를 잘 골라낼 수 있었다고 생각
    이 부분, 즉 의미 있는 신호 판별의 자동화가 실제로 LLM을 활용해 얻을 대박 요소라고 봐서, 이후 동향을 관심 있게 지켜볼 예정임

    • 우리는 이 신호 대 잡음 비율 문제를 개선하는 시스템을 개발 중이고, 최근 인기 있는 소프트웨어 에이전트도 직접 벤치마킹 중임
      결과값 편차가 아주 크고, 조만간 있을 컨퍼런스에서 모든 실험 결과를 공개할 계획임
      업계 최신 동향을 한눈에 볼 수 있을 것임

    • 며칠 전 생각난 점인데, 모든 git 변경 사항, 메일링 리스트 등 Linux 커널에 있었던 역사를 활용해 fine-tune 모델로 발전시키는 게 가능하지 않을까 고민
      이런 LLM이라면 실제로 오랜 기간 코드를 다뤘던 개발자의 감각에 더 가까운 합성적 버전이 될 수 있을 것 같은 기대
      하이컨텍스트(문맥 길이)로만도 커버되는 게 많고, 몇몇 코드베이스는 코드 자체만 20만 토큰을 초과하기도 해 가능성 있다고 생각

    • 1:50이라는 비율은 ‘건초더미에서 바늘 찾기’ 같은 상황에서는 굉장히 훌륭한 검출률임

    • 만약 LLM이 각 취약점 추정치를 입증하는 하네스와 개념 증명 테스트까지 직접 작성한다면, 신호 대 잡음 비율이 대폭 개선될 것으로 예상
      하지만 지금 그런 자동화는 비용이 꽤 높아 아쉬움

  • 저자 본인이 여러 LLM 모델별로 취약점 검색을 100번이나 반복했다는 사실이 가장 인상 깊었음
    이 정도 자원 투입은 그동안 내가 LLM으로 다뤘던 대부분의 문제 대비 아주 높은 편인데, 이제 나도 모델에게 한 번 ‘무지성 반복’ 맡겨볼까 고민

    • 결국 돈이 많이 필요하다는 결론

    • 제로데이 취약점은 상당한 금액에 팔리고, 버그바운티로도 수익을 얻을 수 있음
      LLM 사용 비용은 이런 보상에 비하면 아주 미미
      추론비용이 거의 0에 가까워진 미래 보안 환경은 완전히 다른 모습일 것으로 예상

    • 모델당 100번씩 실행한다는 건 에너지 소모도 상당하다는 뜻
      C 기반 코드에서 흔히 나오는 취약점 하나를 찾는 것이 이렇게까지 자원을 쓰며 이뤄질 때 그 의미가 퇴색되고, 오히려 낭비와 사치의 증거만 부각되는 느낌
      지금은 전 지구적 기후위기 상황이라는 점을 생각할 때, 1950년대처럼 별 가치 없는 일에 자원을 계속 태우는 모습이 못내 걱정임

  • Claude에서 scratchpad(중간 생각 정리장)를 따로 안 줬기 때문에, 결과물에 사고 흐름과 보고서가 섞였던 것 같다고 봄
    공식적으로 생각을 정리할 공간을 허용해줬을 때 Claude가 얼마나 달라질지 실험해보고 싶음
    o3가 인간이 작성한 버그 리포트 느낌으로 핵심 내용만 정제해서 전달하는 반면, Sonnet 3.7 결과는 머릿속 생각이나 작업로그 같은 흐름이 남아 있는 것도 같은 맥락임

    • 직접 o3와 3.7, Gemini 2.5 pro를 다 써봤는데 o3는 비교 불가 레벨이라는 인상
      벤치마크 점수는 아주 커 보이지 않을 수 있지만 복잡한 작업일수록 이 차이의 의미가 커짐
      작년 11월에 발표만 해놓고 막 한 달 전에 출시된 이유가 궁금(아마도 안전성 확보 때문이 아닐까 생각), o4도 빨리 기다리고 있음

    • "scratchpad"를 연구에 활용한 사례나 논문, 관련 링크를 추천해줄 수 있는지 궁금

  • prompt engineering 과정의 본질을 너무 잘 함축한 부분이 마음에 듦
    특히 "가짜 양성으로 잘못된 취약점이 표시되지 않도록 최선을 다해 가이드했지만, 실제로 이게 도움이 되는지 내가 알 도리가 없고 그냥 도움 됐으면 하는 바람뿐이다, 아직 이게 효과가 있는지 충분히 평가 못 했으니 과학도 공학도 아님, 평가는 추후에 공유하겠다"라는 부분이 내 프롬프트 개발 흐름과 너무 비슷함

  • LLM에게 가장 적합한 활용 사례가 이런 (자동 취약점 탐지) 분야가 아닐까 하는 생각
    이론적으로 전체 프로세스를 자동화하고, LLM을 아주 진화된 퍼저(fuzzer)처럼 다뤄 타겟을 VM에 계속 돌려보며 이상 현상이 감지되면 진짜 취약점 가능성을 탐지할 수 있음
    (대부분의 초기 익스플로잇은 기계를 다운시키거나 크래시 유발 후 개선된다는 점을 상기)
    이런 LLM 활용은 한편으론 굉장히 유효해 보이나, 반대로 "우리가 이런 테스트를 할 수 있다고 해서 대단히 새롭거나 결정적인 무언가가 밝혀진 것은 아니다"라는 시사점도 동반

  • zk 버그(영지식 증명 관련) 자동화 타겟팅 주제로 본인이 발표한 자료 유튜브 링크 남김

    • 위 유튜브 영상의 추적 파라미터를 삭제한 클린 링크를 한 번 더 공유
      추가 파라미터는 링크 추적용 정도로 이해

  • curl에 계속 터지는 이슈처럼 안 되길 진심 바람
    관련된 맥락은 Daniel Stenberg의 글 참고

  • 내가 알기로 ksmbd는 전통적인 Samba 서버보다 가볍고 고성능을 지향하는 커널 공간 SMB 서버로 알려져 있음
    Q1: 실제로 ksmbd를 프로덕션 환경에서 누가 쓰는지 궁금
    Q2: 쓰는 이유는 뭔지 궁금

      1. Solaris나 Windows에서 커널 내장 SMB 서버를 쓰던 사람들이 대표적인 사용자라고 생각
  1. Samba 성능이 그에 비해 한참 떨어져서, 2025년에도 많은 사람들이 파일 공유용 서버로 Windows를 운영함
    혹시 이게 Windows에서처럼 ACL을 네이티브로 지원하는지 아는 사람 있나?
    (이것이 Solaris를 계속 운영하는 마지막 이유였는데, ZFS를 통해 지원되는 걸로 알고 있음)
    Samba는 여전히 Unix의 UID/GID와 보안 모델 동기화에 머물러 있는 등 시대착오적 구조임
    커널 내 SMB 서버는 Windows에서 심각한 원격 루트 취약점이 실제로 터진 적도 있어 트레이드오프를 분명히 해야 함

  • 라이선스 이슈가 원인임
    Samba는 GPLv3인데, Linux는 GPLv2만 사용할 수 있음

  • 단순히 가볍고 고성능이라 쓰는 거라고 추정

  • relayd 대신 kmod-trelay 쓰는 것과 비슷한 이유라고 생각

  • LLM의 단기적 최대 난제(Alignment Problem)는 오히려 이런 식의 취약점 자동화에서 드러난다고 생각
    최근 내가 가끔 사용하는 틈새 서버에서 정말 심각한 보안 취약점을 LLM으로 거의 노력 없이 발견했음
    이 시장이 자동화되면, 과거에는 수작업으로 뚫기엔 가치가 없던 온갖 긴 꼬리의 소프트웨어에서 심각한 문제가 대량으로 터질 수 있다는 걱정

    • 반대로, 이러한 기술 발전 덕분에 우리 역시 우리 코드베이스를 스스로 ‘적대적 관점’에서 자동화로 분석할 수 있게 됨
      원래라면 연구자가 찾아내서 공격 당할 취약점도 미리 선제적으로 패치할 기회
      그래서 alignment 문제라 부르는 건 적절하지 않은 듯함

    • 공격자도 자동화로 취약점 탐지 가능하지만, 방어자 역시 이 능력을 갖출 수 있음
      커밋 승인 과정이나 빌드마다 디펜스 자동화 구성도 가능함

답변달기