Claude가 FreeBSD 원격 커널 RCE → root 쉘 익스플로잇 전체를 작성했다

Who Should Read

보안 연구자 및 시스템 개발자 중 LLM이 취약점 발견 및 익스플로잇 자동화에 실제로 어느 수준까지 활용될 수 있는지 파악하고 싶은 사람. 또한 AI 기반 코드 생성이 보안에 미치는 양면적 영향을 이해하려는 보안팀 담당자.

Core Mechanics

• 이번 취약점(CVE-2026-4747)은 FreeBSD의 kgssapi.ko 커널 모듈 내 RPCSEC_GSS 구현에 있는 스택 버퍼 오버플로우다. `svc_rpc_gss_validate()` 함수가 128바이트 스택 버퍼(rpchdr[])에 RPC 헤더를 재구성할 때, 크리덴셜 바디 길이(oa_length)에 대한 경계 검사를 전혀 하지 않아 공격자가 원하는 데이터를 커널 스택에 쓸 수 있다.
• 취약한 버전은 FreeBSD 13.5(p11 미만), 14.3(p10 미만), 14.4(p1 미만), 15.0(p5 미만)이며, NFS 서버에 kgssapi.ko가 로드된 환경(포트 2049/TCP)이 공격 대상이다. 테스트는 FreeBSD 14.4-RELEASE amd64 GENERIC 커널(KASLR 없음)에서 진행됐다.
• FreeBSD 14.x는 KASLR(커널 주소 공간 배치 무작위화)이 없고, 오버플로우된 버퍼가 int32_t 배열이라 스택 카나리(스택 오버플로우 탐지 장치)도 적용되지 않아 익스플로잇이 훨씬 쉬웠다. 이 점이 완전한 RCE → uid 0(root) 리버스 쉘 달성을 가능하게 한 핵심 조건이다.
• Claude는 버그를 직접 발견한 것이 아니라, CVE 어드바이저리와 write-up을 제공받은 상태에서 그 취약점을 실제로 익스플로잇하는 코드를 처음부터 끝까지 작성했다. 즉, '취약점 발견'이 아닌 '익스플로잇 구현 자동화' 단계에서 활용됐다.
• 버그 자체는 Nicholas Carlini(Anthropic 소속)가 Claude를 활용해 발견했고, Thai Duong의 보안 회사 Califio가 전체 익스플로잇 개발 과정과 사용한 프롬프트까지 포함한 상세 write-up을 공개했다. 실제 사용한 프롬프트 히스토리가 GitHub에 공개되어 있어 재현 가능하다.
• 이 write-up은 'MADBugs' 시리즈의 일부로, LLM이 커널 수준의 복잡한 익스플로잇(스택 제어, 리턴 주소 덮어쓰기, 리버스 쉘 연결)을 완성도 있게 작성할 수 있음을 실증한 사례다.
• 커뮤니티에서 지적된 더 큰 위험은 '익스플로잇 작성' 자체보다, LLM이 생성하는 프로덕션 코드 속에 조용히 새로운 취약점을 심을 수 있다는 점이다. 익스플로잇 작성은 눈에 보이지만, PR마다 누적되는 코드 생성 리스크는 잘 보이지 않는다는 우려가 제기됐다.

Evidence

• Claude가 버그를 '발견'한 게 아니라 이미 공개된 CVE write-up을 주고 익스플로잇을 작성하게 했다는 점을 명확히 구분해야 한다는 댓글이 있었다. 다만, 향후에는 커널 소스코드와 VM 환경만 주면 Claude 같은 모델이 스스로 CVE를 발굴해낼 날이 멀지 않았을 것이라는 의견도 함께 달렸다.
• 취약점 발견과 익스플로잇 작성의 차이가 중요하다는 논점이 있었다. 문서화된 CVE에 대한 익스플로잇 작성은 범위가 명확히 정해진 작업이지만, 반대 방향—즉, LLM이 작성한 프로덕션 코드에 새로운 취약점이 조용히 섞여 들어가는 것—이 오히려 더 큰 위협이라는 지적이 있었다. 익스플로잇 능력은 눈에 보이지만, 코드 생성 리스크는 매 PR마다 분산되어 잘 드러나지 않는다는 것이다.
• FreeBSD 14.x에 KASLR이 없다는 점에 대해 FreeBSD 15.x 상황을 묻는 댓글이 있었다. 릴리즈 노트나 mitigations(7) man page에서 관련 언급을 찾지 못했다며, NetBSD는 이미 KASLR을 구현했다는 링크를 함께 공유했다.
• 'Black-Hat LLMs'라는 제목의 발표가 며칠 전 공개됐다는 댓글과 함께 YouTube 링크가 공유됐다. LLM이 취약점 발견과 익스플로잇에 점점 능숙해지고 있다는 흐름을 보여주는 또 다른 사례로 언급됐다.
• 취약점을 자동으로 발견하는 것의 긍정적 측면을 강조하는 시각도 있었다. 가장 어려운 부분은 항상 수정이 아니라 취약점을 찾는 것이고, 현재 이 일을 하는 전문가들은 공개하지 않을 강한 인센티브를 갖고 있다며, 자동화된 발견은 전환기가 무섭더라도 결국 큰 이점이 될 수 있다는 의견이었다.

How to Apply

• 현재 NFS 서버에 kgssapi.ko를 로드한 상태로 FreeBSD 13.5, 14.3, 14.4, 15.0을 운영 중이라면 즉시 각 버전의 패치(13.5-p11, 14.3-p10, 14.4-p1, 15.0-p5 이상)를 적용해야 한다. 패치 적용 전까지는 포트 2049/TCP를 신뢰할 수 없는 네트워크에서 차단하는 것이 최소한의 완화 조치다.
• 보안 연구나 레드팀 활동에서 LLM을 활용하려는 경우, Califio의 write-up에 공개된 프롬프트 히스토리(GitHub 링크)를 참고해 'CVE 어드바이저리 → 익스플로잇 코드 생성' 워크플로우를 구성할 수 있다. 다만 이는 이미 공개된 취약점에 대한 PoC 검증 용도로만 사용해야 한다.
• AI 코드 리뷰 도구를 도입하거나 LLM으로 코드를 생성하는 팀이라면, '익스플로잇 가능성'보다 오히려 LLM이 생성한 코드 속에 경계 검사 누락(bounds check missing) 같은 패턴이 없는지 정기적으로 정적 분석(static analysis) 도구와 병행해 검토하는 프로세스를 갖춰야 한다. 이번 사례의 근본 원인도 단순한 경계 검사 누락이었다.

Code Example

// 취약한 코드 (sys/rpc/rpcsec_gss/svc_rpcsec_gss.c)
static bool_t
svc_rpc_gss_validate(struct svc_rpc_gss_client *client, struct rpc_msg *msg,
                     gss_qop_t *qop, rpc_gss_proc_t gcproc)
{
    int32_t rpchdr[128 / sizeof(int32_t)]; // 스택에 128바이트만 할당
    int32_t *buf;

    memset(rpchdr, 0, sizeof(rpchdr));

    // 고정 크기 RPC 헤더 필드 32바이트 기록
    buf = rpchdr;
    IXDR_PUT_LONG(buf, msg->rm_xid);
    IXDR_PUT_ENUM(buf, msg->rm_direction);
    IXDR_PUT_LONG(buf, msg->rm_call.cb_rpcvers);
    IXDR_PUT_LONG(buf, msg->rm_call.cb_prog);
    IXDR_PUT_LONG(buf, msg->rm_call.cb_vers);
    IXDR_PUT_LONG(buf, msg->rm_call.cb_proc);

    oa = &msg->rm_call.cb_cred;
    IXDR_PUT_ENUM(buf, oa->oa_flavor);
    IXDR_PUT_LONG(buf, oa->oa_length);

    if (oa->oa_length) {
        // 버그: oa_length에 대한 경계 검사 없음!
        // 32바이트 이후 남은 공간은 96바이트뿐.
        // oa_length > 96이면 rpchdr 밖으로 오버플로우 →
        // 지역 변수 → 저장된 레지스터 → 리턴 주소 덮어씀
        memcpy((caddr_t)buf, oa->oa_base, oa->oa_length);
        buf += RNDUP(oa->oa_length) / sizeof(int32_t);
    }
    // gss_verify_mic() 호출 — 그러나 오버플로우는 이미 발생함
}

Terminology

관련 논문

• Mindwalk – 코딩 에이전트 세션을 코드베이스 3D 맵 위에서 재생하는 시각화 도구

  Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.

• Ghost Font: 사람은 읽을 수 있지만 AI는 읽기 어려운 안티-AI 폰트 실험

  움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.

• GPT-5.6, Grok 4.5, Claude, Muse Spark 등 12개 모델이 동일한 앱 4개를 빌드한 결과 비교

  12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.

• Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과

  Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.

• Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구

  LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.

• LLM-as-a-Verifier: 범용 Verification 프레임워크

  LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.

Related Resources

• CVE-2026-4747 Write-up (Califio GitHub)
• Califio Blog: MADBugs - Claude wrote a full FreeBSD RCE
• FreeBSD Security Advisory FreeBSD-SA-26:08.rpcsec_gss
• MADBugs CVE-2026-4747 전체 파일 트리 (프롬프트 히스토리 포함)
• YouTube: Black-Hat LLMs 발표
• NetBSD KASLR 구현 문서