▲

Claude Code가 23년간 숨겨져 있던 Linux 취약점을 발견

 (mtlynch.io)
4P by GN⁺ 14시간전 | ★ favorite | 댓글 1개
  • Anthropic의 Claude Code가 Linux 커널의 원격 악용 가능한 취약점을 자동 탐지해, 23년간 발견되지 않았던 NFS 드라이버의 힙 버퍼 오버플로우를 찾아냄
  • 단순히 “보안 취약점이 어디 있는가?”라는 프롬프트만으로 커널 전체를 분석해 거의 감독 없이 취약점을 식별함
  • 해당 버그는 2003년 커널 코드의 112바이트 고정 버퍼 설계에서 비롯되었으며, 이후 LOCK 연산 추가 시 owner ID 길이 제한 누락으로 발생함
  • Carlini는 이 외에도 수백 개의 잠재적 커널 취약점을 발견했으나, 인간 검증 병목으로 대부분 아직 보고되지 않음
  • 최신 Claude Opus 4.6 모델이 이전 버전보다 훨씬 높은 탐지 능력을 보여, AI 기반 보안 연구의 전환점으로 평가됨

Claude Code가 23년간 숨겨져 있던 Linux 취약점을 발견

  • Anthropic의 연구원 Nicholas Carlini가 Claude Code를 이용해 Linux 커널의 원격 악용 가능한 취약점 여러 개를 발견함
    • 그중 하나는 23년간 발견되지 않았던 NFS(Network File System) 드라이버의 버퍼 오버플로우 취약점
    • Carlini는 “이런 종류의 취약점을 직접 찾은 적이 없었다”며 Claude Code의 성능에 놀라움을 표현

  • Claude Code의 취약점 탐지 방식

    • Claude Code는 거의 감독 없이 Linux 커널의 보안 취약점을 탐지함
      • Carlini는 단순히 “보안 취약점이 어디 있는가?”라는 프롬프트를 주고 커널 전체 소스 파일을 순회하도록 설정
    • 사용된 스크립트는 각 파일을 대상으로 CTF(해킹 대회) 상황을 가정해 Claude Code가 가장 심각한 취약점을 /out/report.txt에 기록하도록 구성
      • find 명령으로 모든 파일을 탐색하고, 각 파일마다 Claude Code가 취약점을 찾도록 반복 실행
    • 동일한 취약점이 중복 보고되지 않도록 설계되어, 커널의 모든 파일을 개별적으로 분석함

  • NFS(Network File System) 취약점

    • Claude Code가 발견한 주요 취약점은 Linux NFS 드라이버의 힙 버퍼 오버플로우로, 공격자가 네트워크를 통해 커널 메모리를 읽을 수 있음
    • 공격 시나리오는 두 개의 협력하는 NFS 클라이언트(Client A, Client B) 가 하나의 NFS 서버를 대상으로 수행
      • Client A가 1024바이트의 긴 owner ID를 사용해 파일 잠금을 요청하고 승인받음
      • 이후 Client B가 동일 파일에 잠금을 요청하면 서버는 이를 거부하며 응답 메시지를 생성
    • 문제는 이 거부 응답 버퍼 크기가 112바이트에 불과한데, 실제 메시지는 owner ID 포함 시 총 1056바이트에 달함
      • 결과적으로 커널이 1056바이트를 112바이트 버퍼에 기록하면서 공격자가 제어하는 데이터로 커널 메모리를 덮어씀
    • Claude Code는 이 취약점을 보고할 때 ASCII 프로토콜 다이어그램까지 자동 생성해 포함함

  • 23년간 발견되지 않은 이유

    • 해당 버그는 2003년 3월 Linux 커널에 도입된 코드에서 비롯됨
      • 당시 커밋 메시지에는 NFSD4_REPLAY_ISIZE라는 112바이트 고정 버퍼가 OPEN, CLOSE 등 NFSv4 연산용으로 충분하다고 명시됨
      • 이후 LOCK 연산이 추가되면서 owner ID 길이 제한이 고려되지 않아 취약점이 발생
    • 이 코드는 Git 도입(2005년) 이전의 변경 사항으로, 현재는 직접 링크조차 불가능한 오래된 코드 기반임

  • 보고되지 못한 수백 개의 추가 취약점

    • Carlini는 수백 개의 잠재적 Linux 커널 취약점을 추가로 발견했으나, 인간 검증 과정의 병목으로 인해 대부분 아직 보고되지 않음
      • “검증되지 않은 결과를 커널 메인테이너에게 보낼 수 없기 때문에, 아직 확인하지 못한 수백 건의 크래시가 있다”고 언급
    • 현재까지 Carlini가 직접 수정하거나 보고한 취약점은 5건으로 확인됨
      • nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
      • io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
      • futex: Require sys_futex_requeue() to have identical flags
      • ksmbd: fix share_conf UAF in tree_conn disconnect
      • ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

  • AI 기반 취약점 탐지의 발전

    • Carlini는 Claude Opus 4.6(출시 2개월 전)을 사용해 이 취약점을 발견함
      • 이전 버전인 Opus 4.1(8개월 전), Sonnet 4.5(6개월 전) 에서는 동일한 결과를 재현하지 못함
      • 최신 모델이 훨씬 더 많은 취약점을 탐지할 수 있었음
    • 그는 “앞으로 몇 달 안에 연구자와 공격자 모두가 이러한 AI 모델의 강력함을 인식하면서, 대규모 보안 취약점 발견의 물결이 올 것”이라고 전망

  • 발표 및 기타 정보

    • 이 내용은 [un]prompted AI security conference 2026에서 발표됨
    • Claude Code의 발견 사례는 AI가 실제 보안 연구의 생산성을 극적으로 높일 수 있음을 보여주는 사례로 평가됨

함께 보면 좋은 글 β

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

  • 놀랍지 않음. 다만 기사에서 언급되지 않은 점은 Claude Code가 1,000개의 오탐 버그도 찾아냈고, 개발자들이 이를 걸러내는 데 3개월이 걸렸다는 부분임

    • 지금은 그런 식으로 작동하지 않음. LLM이 자체적으로 2차 파이프라인에서 재현 불가능한 버그를 걸러냄. 실제로 트리거 가능한 취약점인지 확인하는 건 찾는 것보다 훨씬 쉬운 작업이라 거의 100% 정확하게 진짜 버그만 남음. LLM의 발전을 부정하는 사람들은 여전히 많지만, 유용성을 부정하기는 어려움
    • 출처가 궁금함. 그런 내용은 본 적이 없음. 내 경험상 Claude Opus 4.6의 취약점 탐지 오탐률은 20% 이하였음
    • 정적/동적 분석 도구도 항상 취약점을 찾아냄. 대부분의 대형 프로젝트는 이미 스캐너가 쏟아낸 이슈 백로그를 갖고 있음. 문제는 그중 실제로 위험한 걸 선별하는 일임. Claude가 오래된 버그를 찾은 건 흥미롭지만, 새로운 스캐너가 나오면 항상 이런 일이 생김
    • 기사에는 오탐이 많다고 쓰여 있지 않음. 오히려 “아직 검증하지 못한 버그가 너무 많다”고 언급되어 있음
    • 교훈은 Claude Code가 쓸모없다가 아니라, 올바른 사람 손에 들어가면 강력한 도구가 된다는 점임

  • 새로운 코드를 한꺼번에 붙여넣고 Claude에게 “뭘 빠뜨렸지? 어디에 버그가 있지?”라고 묻는 건 AI에 처음 입문하는 개발자에게 매우 설득력 있는 접근임. 특히 스레딩이나 분산 시스템 버그를 빠르게 찾아줌. 지금쯤 암호화폐 코드들이 대거 분석되고 있을 듯함

    • 나는 Claude가 “버그가 있다”고 전제하도록 프롬프트를 편향시키는 걸 좋아함. “이 코드에 버그가 있어. 찾을 수 있겠어?”라고 묻거나 “버그는 눈에 띄지 않아”라고 덧붙이면 성공률이 높았음
    • 나도 CC/codex를 거의 이런 식으로 사용함
    • “Codex가 작성한 코드인데, 이상한 점이 있나?”라고 묻는 식으로 활용함

  • “숨겨진” 버그라기보다 “아무도 들여다보지 않았다”는 표현이 더 맞음. 코드가 112바이트 버퍼에 1056바이트를 써버리는 구조였음. 정적 분석기로도 쉽게 잡을 수 있는 문제지만, LLM에게 “고정 크기 버퍼를 모두 검사하라”고 하면 환각 결과도 섞일 수 있음. 그래도 좋은 출발점임

    • 대부분의 취약점은 “아무도 들여다보지 않았다”는 이유로 남아 있음. 시스템 복잡도가 누적되면서 사람이 따라가기 어려워짐. 이런 문제를 해결할 수 있다면 큰 뉴스임. 정적 분석기는 가능한 모든 버퍼 복사 경로를 보고하지만, 실제로 입력이 제한되는 경우도 많아 리눅스 커널에서는 잘 맞지 않음
    • 사실 “아무도 들여다보지 않았다”는 건 인력 부족 때문임. 오픈소스 취약점을 찾을 수 있는 사람과 시간이 한정되어 있었음. 하지만 이제 모델이 충분히 유능해지면서 그 한계가 깨지고 있음. 올해는 매우 흥미로운 해가 될 것 같음
    • 정적 분석기가 쉽게 찾을 수 있었다고 하지만, 실제로는 20년 넘게 아무도 못 찾았음. LLM이 뭔가 멋진 걸 해내면 항상 “그건 별거 아냐”라는 반응이 나오는 게 웃김

  • 흥미롭게도, 발견된 5개의 버그 중 3~4개는 linux-hardened 패치로 완화되었을 것임. 예를 들어 io_uring 비활성화, UAF 시 커널 크래시, 힙 오버플로우 악용 방지 등

  • “위험한 무기를 공개하니 세상을 안전하게 만드는 데 도와달라. 단, 구독료를 내라”는 식의 발표가 웃김. 마치 생화학자가 화학 폭탄을 풀어놓고 “이걸 막으려면 돈을 내라”고 말하는 것 같음. 요즘 소프트웨어 업계는 정말 아이러니함

    • 그건 말이 안 됨. 취약점을 찾아서 보고하는 걸 생화학 무기 살포에 비유하다니, 너무 과함

  • 여러 프로덕션 코드베이스에서 실험을 재현해봤는데, 중복·오탐·비악용 버그가 많았음. 그래도 실제 치명적 취약점(crit) 도 꽤 있었음

  • 발표 Q&A 중 배경에 재생된 영상이 궁금했음. NFS 버그를 USB 네트워크로 악용하는 익스플로잇 데모였던 걸까?

  • 우리 보안 연구실의 관련 작업임. AI 보안 에이전트로 올해만 23개의 취약점을 발견했음

  • 3글자 기관들(정보기관) 의 0-day 비축분이 급격히 줄어들 것 같음

  • 앞으로 더 많은 취약점 보고서가 나올 거라 기대하지 말고, 더 많은 공격 시도를 예상해야 함

답변달기