해시는 바이트만 증명한다, Collider 1.3.0의 패키지 보안 수리기

• Collider 글의 핵심은 제목 그대로임 — 해시는 “이 바이트가 lockfile에 적힌 바이트와 같다”만 증명함
  • 어떤 이름이 어떤 URL로 해석됐는지, 그 URL이 어디로 리다이렉트됐는지, 누가 게시했는지는 해시만으로 알 수 없음
  • Collider 1.3.0은 해시 검증 전에 벌어지는 두 군데 문제를 고쳤다고 설명함

저장소 인덱스도 입력값이다

• 첫 번째 문제는 WrapDB 호환 저장소의 releases.json 인덱스였음

  • 이 파일은 패키지 이름과 버전 목록을 제공함
  • 문제는 name/version이 단순 라벨이 아니라 실제 파일 경로 일부가 된다는 점임
  • 예를 들면 subprojects/<name>.wrap, ~/.config/collider/cache/wraps/<name>_<version>.wrap 같은 식임

• 악의적인 인덱스가 ../../../../etc/cron.d/x 같은 이름을 주면 경로 탐색(path traversal)이 됨

  • Collider가 그 값을 파일명으로 쓰면 캐시 디렉터리 바깥으로 빠져나갈 수 있음
  • version 문자열도 똑같은 공격면이 됨
  • 공개 미러나 동료가 띄운 저장소 URL을 쓴다면 Collider가 제어하지 않는 서버 입력을 그대로 믿는 셈임

• 그래서 Collider는 인덱스를 파싱하는 한 지점에서 name/version을 먼저 거르도록 바꿨음

  • packages_from_releases가 인덱스를 패키지 엔트리로 만드는 관문이라 여기에 검증을 넣음
  • is_safe_path_segment는 빈 문자열, ., .., 경로 구분자, null byte를 거부함
  • Path(value).name이 원래 값과 달라지는 경우도 거부함

• 읽기와 쓰기에서 실패 처리는 다르게 가져감

  • 캐시 생성이나 publish 같은 쓰기 경로에서는 traversal 이름을 발견하면 예외를 던짐
  • 검색처럼 외부 releases.json을 읽는 흐름에서는 잘못된 엔트리를 스킵하고 debug 로그만 남김
  • 경로를 만드는 각 sink에도 방어 검사를 남겨 defense in depth로 둠

• 아카이브 내부 파일명도 똑같이 untrusted input으로 봄

  • wrap이 가리키는 tar/zip 안에 ../../x 같은 멤버가 있으면 추출 디렉터리 밖으로 나갈 수 있음
  • Collider는 meson.build를 스캔하기 위해 임시 추출할 때 Python tar data filter와 zip 경로 정리를 사용함
  • 빌드 시점의 실제 추출은 Meson이 담당하고, archive hash로 보호된다고 설명함

토큰은 리다이렉트에 따라가면 안 된다

• 두 번째 문제는 collider publish와 collider unpublish의 bearer token 처리임

  • 이 명령들은 저장소의 _collider/v1/ 쓰기 API로 Authorization 헤더를 보냄
  • Python 기본 urllib opener는 리다이렉트가 발생해도 요청 헤더를 다시 보냄
  • 즉 저장소가 302 Location: https://another-host/...를 주면 토큰이 다른 호스트로 넘어갈 수 있었음

• Collider는 인증 호출을 safe_urlopen으로 보내고, 출처가 바뀌면 Authorization을 제거하게 바꿈

  • _origin은 scheme, host, port를 비교함
  • https://h와 https://h:443처럼 기본 포트는 같은 origin으로 정규화함
  • 같은 origin 리다이렉트면 토큰을 유지하고, 다른 origin이면 토큰을 빼서 보냄

• 이 수정은 토큰을 “안전하게” 만드는 게 아니라, 엉뚱한 호스트로 보내지 않게 하는 좁은 수리임

  • collider serve 자체에는 TLS가 없음
  • 정적 bearer token은 결국 전송 채널이 안전해야 의미가 있음
  • 프로덕션에서는 TLS 종료 reverse proxy를 앞에 둬야 한다고 명시함

sequenceDiagram
    participant 사용자
    participant 콜라이더
    participant 원본저장소
    participant 다른호스트
    사용자->>콜라이더: publish 요청
    콜라이더->>원본저장소: Authorization 포함 쓰기 API 호출
    원본저장소-->>콜라이더: 302 리다이렉트
    콜라이더->>콜라이더: 출처 변경 감지 후 Authorization 제거
    콜라이더->>다른호스트: 토큰 없는 요청
    다른호스트-->>콜라이더: 인증 실패

해시 다음은 서명이다

• Collider의 기존 hash와 origin pinning은 여전히 중요하지만 한계가 있음

  • hash는 lockfile에 기록된 바이트와 설치할 바이트가 같은지만 보장함
  • origin pinning은 lock 당시의 저장소 URL에서만 설치하게 해서 기본적인 dependency confusion을 막음
  • 하지만 저장소 자체가 뚫렸거나, 처음 lockfile을 만들 때 오염된 인덱스를 봤다면 해시는 그대로 맞아버림

• 오프라인 캐시 fallback에서도 출처 정보는 약해짐

  • 캐시는 wrap이 어떤 저장소에서 왔는지 알 수 없음
  • 그 상황에서는 content hash만 남음
  • 그래서 “어디서 왔는가”와 “누가 만들었는가”는 별개 문제로 남음

• 다음 로드맵은 signing임

  • 게시자가 wrap과 archive에 서명함
  • 소비자는 이미 신뢰하는 키로 서명을 검증함
  • 이렇게 해야 패키지가 특정 신뢰 키 보유자에게 묶이고, hash가 못 하는 provenance 검증을 할 수 있음

기술 맥락

• 이 글이 좋은 이유는 공급망 보안의 레이어를 분리해서 보여주기 때문이에요. hash는 다운로드한 바이트가 lockfile과 같은지만 확인해요. 그런데 어떤 URL을 고를지, 파일명을 어디에 쓸지, 인증 헤더를 어디까지 보낼지는 hash 전에 이미 결정돼요.

• 경로 탐색을 sink마다 막는 대신 인덱스를 파싱하는 관문에서 먼저 거른 선택도 실용적이에요. 패키지명과 버전이 여러 경로에서 재사용되기 때문에, 매번 파일을 만들기 직전에만 막으면 새 코드가 추가될 때 빠뜨리기 쉽거든요. 그래도 각 sink 검사는 남겨서 방어층을 하나 더 둔 구조예요.

• Authorization 헤더 제거는 HTTP 클라이언트 구현에서 자주 놓치는 부분이에요. 같은 출처 리다이렉트는 정상 배포 구성에서도 필요할 수 있지만, 출처가 바뀌는 순간 토큰을 따라 보내면 인증한 적 없는 서버에 권한을 넘기는 꼴이 돼요.

• 마지막으로 signing 로드맵이 중요한 건 hash와 서명이 푸는 문제가 다르기 때문이에요. hash는 무결성, origin pinning은 저장소 혼동 방지, signing은 게시자 신뢰를 담당해요. 패키지 매니저를 만들거나 사내 아티팩트 배포 시스템을 운영한다면 이 셋을 같은 기능으로 뭉개면 안 돼요.