Reddit

10.0 critical CVE (RCE): update zip crate to 9.0.5

CVSS 10.0 치명적 취약점(RCE): Rust zip 크레이트를 9.0.5로 업데이트하세요

Rust용 zip 크레이트에서 ZIP 파일의 중앙 디렉터리와 로컬 파일 헤더에 적힌 파일명이 다를 때 검사와 추출 결과가 달라지는 취약점이 보고됐습니다. 조작된 아카이브가 추출 경로의 파일을 덮어쓸 수 있다는 설명이지만, Reddit 댓글에서는 RCE와 CVSS 10.0 평가가 실제 공격 조건을 과장한다는 반론이 나왔습니다.

에디터 노트

평가의 쟁점은 헤더 불일치 자체보다 그 결과를 RCE와 CVSS 10.0으로 부를 근거가 있는지입니다. CVE 설명은 검사와 스트리밍 추출이 서로 다른 파일명을 사용해 경로와 내용을 바꿔 쓸 수 있다고 밝힙니다. 댓글에서는 실행 증거가 없고, PoC가 보여준 것은 사용자 콘텐츠용 디렉터리에 파일을 쓴 상황뿐이라는 반론이 나왔습니다. 제공된 설명만으로는 임의 코드 실행이나 임의 경로 덮어쓰기가 확인되지 않습니다. 반면 하위 서비스가 같은 위치의 파일을 신뢰해 사용한다면 파일 덮어쓰기가 더 큰 영향으로 이어질 가능성은 설명에 포함돼 있습니다. 실제 악용 가능성은 추출 방식과 대상 디렉터리, 후속 서비스의 처리에 달려 있습니다. 수정 버전도 CVE 설명은 9.0.5로 적었지만 댓글은 릴리스 노트를 근거로 9.1.0이라고 반박합니다. 이 자료만으로는 버전 차이를 해소할 수 없으며, 업데이트 안내의 버전 표기에도 불일치가 있습니다.

AI 요약

Rust용 ZIP 라이브러리 zip에서 중앙 디렉터리 파일 헤더(Central Directory File Header)와 로컬 파일 헤더(Local File Header)의 파일명이 서로 다를 때 생기는 파서 불일치 취약점 CVE-2026-115905가 보고됐습니다. CVE 설명에 따르면 9.0.4 이하에서 ZipArchive는 중앙 디렉터리의 파일명을 기준으로 삼지만 ZipStreamReader는 중복 메타데이터를 대조하지 않고 로컬 헤더의 파일명으로 추출합니다. 따라서 중앙 디렉터리를 검사하는 구성 요소에는 정상 파일처럼 보이는 아카이브가 스트리밍 추출 단계에서는 공격자가 지정한 다른 경로와 내용으로 파일을 쓸 수 있습니다. 그 파일이 후속 서비스에서 사용하는 파일이라면 덮어쓰기로 이어질 수 있다는 설명입니다. CVE 설명은 수정 버전으로 9.0.5를 제시합니다.

Reddit 반응

  • @annodomini — 실제 문제이긴 하지만, 한 구성 요소는 한 종류의 헤더만 검사하고 다른 구성 요소는 다른 헤더에 따라 코드를 실행한다는 가정으로 10.0을 매긴 것은 CVSS 악용이라고 봅니다. 정규식 서비스 거부 때문에 백신 검사가 멈추고 누군가 악성코드를 실행할 수도 있다는 이유로 정규식 DoS를 10.0으로 부르는 것과 같습니다. 릴리스 노트를 보면 수정 사항은 9.0.5가 아니라 9.1.0에서 나온 것 같습니다. 업데이트는 좋은 일이지만 10.0으로 보지는 않습니다.
  • @Ununoctium117 — 이건 RCE가 아닙니다. PoC의 "RCE confirmed"는 사용자 업로드 파일을 저장하도록 이미 마련된 하위 디렉터리에 파일이 쓰였다는 증거일 뿐입니다. 파일이나 스크립트가 실행됐다는 증거는 없습니다.
  • @afdbcreid — Rust가 RCE를 막지 못한 이유를 궁금해하는 사람에게 말하자면, Rust는 RCE를 막아줍니다. 이 사례는 로직 버그로 파일 혼동을 일으키며, zip 크레이트를 사용하는 매우 특수하고 의심스러운 애플리케이션에서는 RCE로 이어질 수도 있습니다. RCE라고 부르는 건 기껏해야 의심스럽습니다.
  • @vivaaprimavera — 설정 파일이나 라이브러리, 바이너리를 덮어쓸 수 있습니다. 네트워크 접근이 필요하지 않을 수도 있고, 격리된 시스템에 겉보기엔 무해한 파일을 보내는 방식으로 에어갭 시스템에도 영향을 줄 수 있습니다.
  • @Ununoctium117 — 경로 순회 취약점이 있었다면 제보자가 보여줬을 것이라고 생각합니다. 그런 취약점이 입증됐다면 높은 CVE 점수가 나올 만했을 것입니다.
  • @bakaspore — ZipFile 항목에서 읽은 이름으로 대상 파일을 직접 만든다면 영향이 없는지 질문합니다. 이해한 바로는 항목 이름으로 검사한 다음 일괄 추출 메서드에 맡기고, 검사를 보안 경계로 삼는 경우에 문제가 됩니다. 추출 직전에 경로 검사를 하므로 대상 디렉터리 밖의 임의 파일을 덮어쓰지는 못할 것 같다고 덧붙입니다.
  • @minno — 추출 프로세스가 접근할 수 있는 파일을 덮어쓰는 버그와 결합될 수도 있습니다.
  • @CAD1997 — 라이브러리에 CVSS를 적용하는 방식은 문제가 있다고 봅니다. 누군가 잘못 사용할 수 있다는 사실만으로 치명적 취약점이라고 할 수는 없습니다. 먼저 패치하고 이론적 취약점에 노출됐는지 확인하는 편이 낫지만, 패치 전에는 무조건 취약하다고 단정하면 도움이 되지 않습니다.
원문 보기 ↗토론 보기 ↗