tokio-tar의 파서 논리 결함으로 중첩 TAR를 이용한 엔트리 밀수와 파일 덮어쓰기, 공급망 공격이 가능해졌습니다. 가장 널리 쓰이는 포크가 방치(abandonware) 상태여서 분산된 책임 공개와 광범위한 포크·다운스트림 조율이 필요했고, 패치, 권고 마이그레이션, 완화책을 제시합니다.
이 취약점은 uv(Astral의 초고속 Python 패키지 매니저), testcontainers, wasmCloud를 포함한 주요 널리 사용되는 프로젝트에 영향을 미칩니다. 다양한 형태로 생태계 전반에서 tokio-tar가 광범위하게 쓰이기 때문에, 이 버그의 폭발 반경을 사전에 정확히 계량하기는 어렵습니다.
활성 포크들은 이미 성공적으로 패치되었으며(참고: Astral 보안 권고), 이번 공개는 한 가지 중대한 시스템적 과제를 부각합니다. 바로 다운로드 수가 매우 많은 tokio-tar는 여전히 패치되지 않았다는 점입니다.
권장 대응은 즉시 패치된 버전으로 업그레이드하거나 해당 종속성을 제거하는 것입니다. tokio-tar에 의존한다면, astral-tokio-tar처럼 적극적으로 관리되는 포크로 마이그레이션을 고려하십시오. 추가로, 에데라(Edera)의 포크인 krata-tokio-tar는 에코시스템 혼선을 줄이고 Astral 포크에 노력을 결집하기 위해 보관(archive) 상태로 전환됩니다.
이번 취약점 공개는 특히 까다로웠습니다. 가장 인기 있는 포크(tokio-tar, crates.io 다운로드 500만 회 이상)가 더 이상 적극적으로 유지·관리되지 않는 방치 소프트웨어(abandonware)로 보였기 때문입니다.
일반적인 공개 절차에서는 단일 패치가 상류(upstream) 저장소에 적용되고, 모든 하류(downstream) 사용자가 그 수정을 상속받습니다. 그러나 원 프로젝트 관리자가 수정을 적용해 줄 것이라 기대할 수 없었기에, 깊고 복잡한 포크 계보 전반에 걸친 분산 공개를 조율해야 했습니다.
async-tar(루트) ➡️ tokio-tar(가장 인기 있는 포크, 방치됨) ➡️ krata-tokio-tar(원래 Edera가 유지, 현재 보관) ➡️ astral-tokio-tar(Astral이 적극 유지)
단일 연락 지점(one point of contact)이 없는 상황에서 우리는 다음을 수행해야 했습니다.
tokio-tar, async-tar)의 관리자를 확인하고 연락. 두 프로젝트 모두 SECURITY.md나 공개 연락 수단이 없어, 적절한 관리자를 찾기 위해 커뮤니티 기반의 탐색과 소셜 엔지니어링이 필요했음astral-tokio-tar, krata-tokio-tar)의 관리자에게 개별적으로 연락하여 엄격한 60일 엠바고 하에 동시 패치 조율testcontainers, binstalk-downloader, liboxen, opa-wasm 등)에 선제적으로 연락해 공개 즉시 업그레이드 준비를 갖추도록 지원이 과정은 일반적인 공개보다 훨씬 많은 노력과 시간이 들었습니다. 이는 인기 있지만 방치된 오픈 소스 의존성에서 심각한 취약점이 발견될 때 광범위한 패치를 보장하는 데 따르는 큰 어려움과 비효율을 여실히 보여줍니다.
astral-tokio-tar로 전환 계획이 취약점은 공격자가 TAR 추출 과정에 추가 아카이브 엔트리를 "밀수(smuggle)"할 수 있게 하는 비동기화(desynchronization) 결함입니다. 이는 PAX 확장 헤더와 ustar 헤더 간에 특정한 불일치를 보이는 중첩 TAR 파일을 처리할 때 발생합니다.
결함은 파일 데이터 경계를 결정하는 파서 로직의 불일치에서 비롯됩니다.
size=X, 예: 1MB)를 올바르게 지정함size=0)으로 잘못 지정함tokio-tar 파서는 PAX 크기(X 바이트)가 아니라 ustar 크기(0 바이트)를 기준으로 스트림 위치를 잘못 전진시킴0바이트만 전진함으로써, 파서는 실제 파일 데이터(이는 중첩된 TAR 아카이브)를 건너뛰지 못하고 즉시 중첩 아카이브의 시작부에 있는 다음 유효 TAR 헤더를 마주합니다. 그리고 내부 아카이브의 헤더를 외부 아카이브에 속한 합법적 엔트리로 잘못 해석합니다.
그 결과 다음과 같은 일이 발생합니다.
정상적인 TAR 처리:
취약한 처리(PAX size=X, ustar size=0):
파서가 보게 되는 결과:
스캐너/검증기가 기대한 것:
엔트리 1: "outer-file.txt"
엔트리 2: "inner-tar-file.tar" (ustar 상 0바이트이지만, PAX 상 N바이트)
엔트리 3: "next-file.txt"
실제로 tokio-tar가 추출한 것:
엔트리 1: "outer-file.txt"
엔트리 2: "inner-tar-file.tar" (ustar 상 0바이트)
엔트리 3: "inner-file1.txt" (내부 TAR에서)
엔트리 4: "inner-file2.txt" (내부 TAR에서)
엔트리 5: "next-file.txt" (정상 진행)
핵심 통찰은 파서의 내부 스트림 위치가 어긋나(hidden된 중첩 아카이브의) 헤더와 데이터를 1차 아카이브의 엔트리 목록 일부로 취급하게 된다는 점입니다.
대상: tokio-tar를 사용하는 Python 패키지 매니저(예: uv). 공격자가 악성 패키지를 PyPI에 업로드합니다. 패키지의 외부 TAR에는 정상 pyproject.toml이 담겨 있지만, 숨겨진 내부 TAR에는 빌드 백엔드를 탈취하는 악성 파일이 들어 있습니다. 패키지 설치 중 악성 구성 파일이 정상 파일을 덮어써 개발자 PC와 CI 시스템에서 RCE가 발생합니다.
대상: 컨테이너 테스트 프레임워크(예: testcontainers). 이미지 레이어를 분석하기 위해 추출하는 테스트 프레임워크는 이 중첩 TAR 구조로 만든 레이어에 속아 넘어갈 수 있습니다. 숨겨진 내부 TAR가 예상치 못한 파일 추가 또는 덮어쓰기를 유발해 테스트 환경을 손상시키고 공급망을 오염시킬 수 있습니다.
대상: "스캔/승인" 단계와 "추출/배포" 단계가 분리된 시스템. 보안 스캐너는 외부의 깨끗한 TAR를 분석하고 제한된 파일 집합을 승인합니다. 그러나 취약한 라이브러리를 사용하는 추출 과정에서 내부 TAR의 추가 파일(승인 및 스캔되지 않음)이 함께 풀려나오며, 보안 통제 우회와 정책 위반이 발생합니다.
Edera 팀은 astral-tokio-tar(uv에서 사용)와 krata-tokio-tar에 대한 패치를 제공했습니다. 취약점은 CVE-2025-62518로 추적됩니다. 이 취약점 패치와 책임 공개를 위해 성실히 협업해 주신 Astral 보안 팀에 큰 감사를 전합니다.
패치는 TAR 파서를 다음과 같이 수정합니다.
패치는 여기에서 확인할 수 있습니다: https://github.com/edera-dev/cve-tarmageddon/tree/main/patches
아키텍처 차이로 인해 async-tar에 대한 직접 패치는 제공하지 않았지만, 유지관리자가 패치를 작성했습니다.
즉시 패치 적용이나 유지되는 포크로의 전환이 불가능하다면 다음 우회책을 고려하십시오.
대체 라이브러리: 표준 tar 크레이트(비동기 아님)는 본 시나리오를 올바르게 처리하며 임시 대체재로 사용할 수 있습니다.
런타임 완화:
TARmageddon의 발견은 Rust가 만능열쇠가 아니라는 점을 상기시킵니다. Rust의 보장은 버퍼 오버플로우나 use-after-free 같은 메모리 안전 버그 도입을 현저히 어렵게 만들지만, 논리 버그까지 제거하진 못합니다. 이번 파싱 불일치는 본질적으로 논리 결함입니다. 개발자는 사용 언어와 무관하게 모든 범주의 취약점에 경계를 늦추지 말아야 합니다.
이 취약한 라이브러리 계보(async-tar ➡️ tokio-tar ➡️ 포크)는 흔한 오픈 소스의 이야기를 들려줍니다. 현대의 안전한 언어로 작성된 인기 코드조차도 관리 부재 상태가 될 수 있으며, 수백만 하류 사용자에게 위험을 노출할 수 있습니다.
이번 경험은 심층 방어의 중요성을 재확인시켰습니다. Edera는 설계 단계의 선제적 조치 덕분에, 취약한 krata-tokio-tar를 내장하고 있었음에도 우리 제품이 이번 버그에 취약하지 않았습니다. 강력한 보안 경계를 구현하고 취약할 수 있는 연산을 핵심 경로에서 사용하지 않도록 함으로써, Edera는 패치가 배포되기 전부터 문제를 완화했습니다.
마지막으로, 이번 취약점을 책임감 있게 공개하고 패치하는 과정에서 함께해 주신 에코시스템 전반의 연구자와 유지관리자 여러분께 감사드립니다.
8/21: 버그 발견
8/21: krata-tokio-tar, astral-tokio-tar와 상류 tokio-tar, async-tar에서 취약점 최초 확인
8/21: 최소 재현(minimal reproduction) 생성
8/22: 모든 라이브러리에 대한 패치 작성
8/22: 모든 라이브러리의 유지관리자, 러스트 재단, 일부 하류 프로젝트(다운로드 수 기준 선정)에 취약점 비공개 공유. 엠바고 날짜를 10월 21일로 설정
8/22: astral-tokio-tar와 tokio-tar로부터 회신 수신, 패치 공유
9/2: async-tar로부터 수신 확인(acknowledgment)
10/21: astral-tokio-tar와 krata-tokio-tar에 대한 GHSA 및 패치 공개