AWS-Tough-Library-Multiple-CVEs

이 변경으로 클라이언트는 루트 메타데이터를 순서대로 (N, N+1, N+2, ...) 건너뛰지 않고 다운로드하고 적용하게 됩니다. 루트 메타데이터 파일의 버전이 정확히 old_version+1이 아닌 경우 이제 Tough는 이를 잠재적 공격으로 간주하고 업데이트를 중단합니다.

• 근본 원인: 순차 버전 검사 누락 (CWE-1288: 무결성 검사 값의 부적절한 검증) 코드는 새 루트가 현재보다 오래된 경우만 방어했으며, 예상치 못한 점프는 방어하지 못했습니다.
• 해결 방안: 패치가 포함된 tough = 0.20.0로 업그레이드하세요. Tough를 기반으로 하는 모든 포크나 사용자 정의 업데이터가 동일한 엄격한 검사를 구현하도록 하세요. 또한 업데이트 기록에서 의심스러운 루트 버전 점프가 없는지 로그를 감사하는 것이 시도된 악용의 지표로서 현명합니다.

CVE-2025-2886: 종료 위임이 존중되지 않음

Tough는 TUF에서 정의한 “terminating” 위임 대상(targets) 역할을 잘못 처리했습니다. TUF 저장소에서 위임은 terminating으로 표시될 수 있습니다. 즉, 대상 조회가 해당 위임에 도달했을 때 그곳에서 대상을 찾지 못하면 검색이 중단되어야 합니다(다른 우선순위가 낮은 위임으로 계속 진행되지 않아야 합니다). (여기 참조) 논리 오류로 인해 Tough는 이 경우 검색을 종료하지 못했습니다 – 중단해야 했음에도 후속 위임을 계속 검색했습니다. 이로 인해 낮은 우선순위의 위임을 제어하는 공격자가 제어해서는 안 되는 대상에 대한 콘텐츠를 제공할 수 있으며, 의도된 신뢰 경계를 우회할 수 있습니다.

• 보안 권고: GitHub Security Advisory GHSA-v4wr-j3w6-mxqc (CVE-2025-2886)
• 영향받는 코드: tough/src/editor/targets.rs의 대상 조회 알고리즘(및 관련 위임 해석 코드). 취약한 코드는 위임의 terminating 플래그를 제대로 처리하지 못했습니다. 대상을 검색하기 위해 위임을 반복할 때 Tough는 현재 위임이 terminating으로 표시되고 일치 항목이 없더라도 TUF 사양과 달리 다음 위임으로 진행했습니다.

취약한 구현: Tough <0.20.0에서 find_target() 로직은 대상을 찾거나 모든 가능한 위임 역할을 모두 소진할 때까지 단순히 재귀하거나 반복했습니다. terminating 역할을 만났을 때 어떤 플래그도 설정하지 않거나 루프를 중단하지 않았습니다. 이전 동작의 의사 코드:```rust for role in delegation_chain { if role.has_target(target) { return target_metadata; } // Missing: if role is terminating and target not found, should break. // Tough erroneously continues to next delegation. }

또한 재귀적인 find_target 호출은 이제 terminated 플래그를 전달하여 일단 종료가 신호되면 상위 루프에서는 다른 위임이 더 이상 고려되지 않도록 보장합니다. Tough의 RepositoryEditor::delegate_role 및 관련 구조체도 terminating 속성을 저장하고 이를 탐색 로직에 전달하도록 업데이트되었습니다.

• 근본 원인: 코드가 종결(terminating) 위임 의미론을 구현하지 않은 논리적 결함입니다 (CWE-284: 부적절한 접근 제어 – 낮은 우선순위의 역할이 의도된 제한을 재정의할 수 있음). 본질적으로 종결 위임에 대한 break가 없어서 권한 없는 대상 데이터가 고려될 수 있었습니다.
• 영향: 클라이언트가 잘못된 역할이 소유한 대상을 가져올 수 있었습니다. 구체적으로, 프로젝트가 대상의 하위 집합을 다른 당사자에게 위임하고(재정의 범위를 제한하기 위해 해당 위임을 종결로 표시한 경우), 그 당사자는 자신의 범위 밖의 대상에 대해 임의의 콘텐츠를 계속 제공할 수 있었습니다. 이는 TUF 저장소의 신뢰 계층 구조를 깨뜨립니다.
• 해결 방법: 종결 위임 처리를 올바르게 구현한 tough 0.20.0 이상으로 업데이트하십시오. 포크나 사용자 정의 클라이언트를 유지 관리하는 경우 대상 조회가 종결 위임에서 중단되도록 하십시오. 보안 테스터는 이전 버전에서만 위임 남용 시나리오를 시도해야 합니다. 패치된 버전은 악의적인 낮은 우선순위 응답을 올바르게 무시합니다.

CVE-2025-2887: 위임된 대상에 대한 불완전한 롤백 탐지

Tough가 스냅샷 메타데이터에서 롤백 공격을 탐지하는 로직은 불완전했습니다. 구체적으로, Snapshot 역할을 업데이트할 때 Tough는 이전에 본 모든 대상 메타데이터(위임된 대상 포함)가 여전히 존재하고 새 스냅샷에서 이전 버전으로 되돌아가지 않았는지 확인해야 합니다. (여기 참조). Tough는 최상위 targets.json에 대해서는 이를 적용했지만, 위임된 대상 메타데이터 파일에 대해서는 적용하지 못했습니다. 이 간격으로 인해 공격자는 탐지되지 않은 채 저장소의 스냅샷 메타데이터에서 위임된 대상 파일을 제거하거나 되돌릴 수 있었고, 클라이언트가 최신인 것처럼 오래된(또는 누락된) 위임 대상 파일을 수락하게 만들 수 있었습니다.

• 권고: GitHub Security Advisory GHSA-q6r9-r9pw-4cf7 (CVE-2025-2887)
• 영향받는 코드: tough/src/lib.rs의 스냅샷 업데이트 검증(새 Snapshot 메타데이터를 로드/적용하는 함수)입니다. 취약한 코드는 스냅샷에서 기본 targets.json 역할의 연속성만 확인했으며, 스냅샷 메타데이터에 나열된 위임 역할들을 반복하며 유사한 검사를 수행하지 않았습니다.

취약한 구현: Tough <0.20.0에서 클라이언트는 새 snapshot.json을 검색한 후 root 및 snapshot 역할이 롤백되지 않았는지 확인하고, 특히 targets.json이 여전히 존재하는지 확인했습니다. 또한 새 스냅샷의 targets.json 버전이 이전 버전보다 크거나 같은지(>=) 확인했습니다. 그러나 스냅샷에 위임된 대상(예: projects.json, user.json 위임 메타데이터)이 포함된 경우 클라이언트는 이를 확인하지 않았습니다. 예를 들어, 원래 코드는 대략 다음과 같이 동작했습니다:```rust // Pseudo-code of original snapshot rollback check (simplified) if let Some(old_targets_meta) = old_snapshot.meta.get("targets.json") { let new_targets_meta = new_snapshot.meta.get("targets.json").unwrap(); ensure!(new_targets_meta.version >= old_targets_meta.version, ...); } // (No checks for delegated target roles like "projects.json", "user.json", etc.)

모든 역할을 반복 처리함으로써(여기서 name은 targets.json, delegated-role.json 등 각 메타데이터 파일 이름을 나타냄) 클라이언트는 위임된 대상 메타데이터가 제거되거나 롤백되었는지 감지할 수 있습니다. SnapshotRoleMissing 및 SnapshotRoleRollback 오류는 역할이 사라지거나 해당 버전이 이전으로 되돌아간 경우 트리거됩니다. 특히, Tough는 이제 무결성 검사(sanity check) 차원에서 스냅샷에 최소한 targets.json 항목이 포함되어 있는지도 명시적으로 확인합니다(그렇지 않으면 SnapshotTargetsMetaMissing 오류가 발생합니다)​.

• 근본 원인: 불완전한 검증 – Tough는 위임된 대상 역할에 롤백 검사를 일관되게 적용하지 않았습니다. 이는 보안 통제의 부분적인 구현으로, 공격자가 악용할 수 있는 허점을 남겼습니다(CWE-352: 권한 부여의 핵심 단계 누락; 개념적으로는 무결성 검증 문제의 하위 집합). 코드는 최상위 대상만 보호하고 있었으며, 위임된 역할은 회귀하지 않을 것이라고 (잘못) 가정했습니다.
• 영향: 저장소를 조작할 수 있는 공격자는 클라이언트가 감지하지 못한 채 업데이트를 숨기거나 오래된 위임 대상 데이터를 다시 도입할 수 있습니다. 예를 들어, 현재 손상된 키로 서명된 이전 버전의 위임 대상 파일을 제시할 수 있으며, Tough가 해당 파일의 버전을 확인하지 않았기 때문에 수락되었을 것입니다. 실제로 이로 인해 클라이언트가 오래된 콘텐츠를 가져오거나 위임 대상에 대한 중요한 폐기(revocation) 정보를 놓칠 수 있습니다​. (여기 참조)
• 해결 방안: 전체 스냅샷 롤백 검사를 구현한 tough v0.20.0+를 사용하세요​. 사용자 정의 업데이터를 유지 관리하는 경우, 스냅샷에 나열된 모든 신뢰된 메타데이터 파일에 대해 새 스냅샷에도 이전 버전 이상(>=)의 버전 번호로 해당 파일이 나열되도록 하십시오. 또한 저장소 업데이트에서 위임 대상 제거에 대한 로깅 또는 감사(auditing)를 활성화하는 것이 좋습니다. 이러한 제거는 드물어야 하며, 예기치 않게 발생하는 경우 악의적인 활동을 나타낼 수 있기 때문입니다.

CVE-2025-2888: 롤백 시 부적절한 타임스탬프 메타데이터 캐싱

Tough는 타임스탬프(Timestamp) 역할에서 감지된 롤백을 잘못 처리했습니다. TUF에서 타임스탬프 역할은 최신 스냅샷 메타데이터 버전을 주기적으로 서명하여 클라이언트가 이전 스냅샷(롤백)을 보고 있는지 감지할 수 있도록 돕습니다. Tough는 타임스탬프에 포함된 스냅샷 버전에 대한 롤백 검사를 수행하기는 했지만, 새 타임스탬프 메타데이터를 로컬에 캐싱한 후에만 수행했습니다. 롤백이 감지되면 Tough는 업데이트를 거부하지만 이미 무효한 타임스탬프를 캐시의 “최신” 항목으로 저장한 상태였습니다. 즉, 악의적인 타임스탬프(오래된 스냅샷 버전 포함)가 클라이언트의 캐시를 오염(poison)시킬 수 있었습니다. 이후의 정당한 업데이트는 Tough에게 롤백으로 보일 수 있으며(캐시가 새 버전보다 높은 스냅샷 버전을 나타내는 타임스탬프를 보유하고 있었기 때문에), 유효한 업데이트를 차단할 수 있습니다.

• 보안 권고: GitHub 보안 권고 GHSA-76g3-38jv-wxh4 (CVE-2025-2888)
• 영향을 받는 코드: tough/src/lib.rs의 타임스탬프 업데이트 로직(새 timestamp.json을 로드하는 함수)입니다. 핵심 문제는 처리 순서 버그(order-of-operations bug)였습니다. Tough는 내부의 스냅샷 버전이 이전에 확인한 것보다 오래되지 않았는지 완전히 검증하기 전에 새 타임스탬프 메타데이터로 로컬 캐시/상태를 업데이트했습니다.

취약한 구현(Vulnerable Implementation): Tough <0.20.0에서는 새 timestamp.json을 가져오면 클라이언트가 이를 파싱하여 캐시에 기록하고(현재 신뢰된 타임스탬프로 표시) 그런 다음 스냅샷 버전에 대한 롤백 검사를 수행했습니다. 새 타임스탬프의 스냅샷 버전이 이전에 기록된 스냅샷 버전보다 낮은 경우(롤백 시도를 나타냄) Tough는 오류를 기록하고 해당 업데이트 주기를 거부했습니다 – 그러나 캐시에는 이미 “나쁜” 타임스탬프가 저장되어 있었습니다. 해당 오류 경로에는 캐시 항목을 제거하는 처리가 없었습니다. 따라서 클라이언트가 기록한 “신뢰된” 타임스탬프가 이 오래된 것으로 바뀔 수 있었습니다.

예를 들어, 마지막으로 알려진 스냅샷 버전이 5였다고 가정해 보겠습니다. 공격자는 스냅샷 버전 4에 서명하는 타임스탬프 메타데이터(더 높은 타임스탬프 버전 번호 포함)를 제공할 수 있습니다. Tough는 타임스탬프 파일을 수락하고(캐싱) 그런 다음 스냅샷 4 < 5임을 발견하고 업데이트에서 오류를 발생시킵니다 – 그러나 이제 캐시는 “최신 타임스탬프가 스냅샷 4를 나타냄”이라고 말합니다. 다음에 올바른 타임스탬프(스냅샷 5 또는 6)가 오면 Tough는 스냅샷 5와 캐시된 스냅샷 4를 또 다른 롤백으로 간주하고(캐시의 스냅샷 버전 4를 기준선으로 잘못 신뢰하기 때문에) 유효한 업데이트조차 거부합니다. AWS 보안 게시판은 이 주기를 다음과 같이 설명합니다: “클라이언트는 롤백이 감지되었을 때 올바르게 거부되었음에도 불구하고 타임스탬프 메타데이터를 캐시하여… 이후 tough가 유효한 업데이트를 소비하지 못하게 됩니다.”​

수정된 구현(Fixed Implementation): 이 수정은 새 타임스탬프를 캐싱하기 전에 롤백 검사가 수행되도록 보장하고 타임스탬프 내용에 대한 더 엄격한 검증을 추가합니다. Tough 0.20.0에서는 load_timestamp() 함수가 수정되어, 업데이트를 마무리하기 전에 타임스탬프 메타데이터가 올바른 형식(well-formed)이며 해당 스냅샷 버전이 이전에 신뢰되었던 스냅샷 버전보다 낮지 않은지를 강제합니다. 구체적으로, 코드는 이제 다음을 확인합니다: (a) 타임스탬프 메타데이터에 정확히 하나의 항목만 있어야 하며(snapshot.json 항목만 허용), (b) 해당 항목이 존재하고 파싱되며, (c) 내부 스냅샷 버전이 이전 스냅샷 버전 이상(>=)이어야 합니다. (여기 참조) 이러한 검증이 모두 통과된 후에만 새 타임스탬프가 신뢰된 것으로 간주됩니다. 핵심적으로 추가된 로직은 아래에 설명되어 있습니다:```rust // Ensure the timestamp meta contains exactly one entry (the snapshot) ensure!(timestamp.signed.meta.len() == 1, error::TimestampMetaLengthSnafu { … }); let snapshot_meta = timestamp.signed.meta.get("snapshot.json"); ensure!(snapshot_meta.is_some(), error::MissingSnapshotMetaSnafu { … });

// If we have a previously trusted timestamp (old_timestamp): if let Some(old_timestamp) = old_timestamp_opt { // Check that the snapshot version in the new timestamp >= old snapshot version let old_snapshot_meta = old_timestamp.signed.meta.get("snapshot.json").unwrap(); ensure!( old_snapshot_meta.version <= snapshot_meta.unwrap().version, error::OlderSnapshotInTimestampSnafu { // details: new snapshot vs old snapshot versions snapshot_new: snapshot_meta.unwrap().version, snapshot_old: old_snapshot_meta.version, timestamp_new: timestamp.signed.version, timestamp_old: old_timestamp.signed.version } ); }