AWS-Tough-Library-Multiple-CVEs

• Aviso: GitHub Security Advisory GHSA-5vmp-m5v2-hx47 (CVE-2025-2885)
• Código Afetado: a lógica de atualização do Tough para metadados root em tough/src/lib.rs. A implementação vulnerável apenas verificava se a versão do novo root não era menor que a anterior, em vez de exigir que fosse a próxima versão sequencial. Essa omissão viola a regra da especificação do TUF de que os clientes devem baixar as versões intermediárias do root em ordem (sem pular versões).

Implementação Vulnerável: Na versão 0.19.x e anteriores, após baixar um novo root.json, o Tough verificava as assinaturas, mas não aplicava estritamente a continuidade da versão. Ele permitia que a versão do novo root fosse qualquer valor >= à versão confiável. Por exemplo, se o root confiável atual fosse a versão N, o Tough aceitaria um novo root com versão N+2 ou superior (desde que as assinaturas fossem válidas), pulando a N+1. O trecho de código abaixo ilustra a verificação anterior à correção:```rust // (Prior to fix) Allow new root version to be >= old version – too permissive ensure!(root.signed.version <= new_root.signed.version, error::OlderMetadataSnafu { role: RoleType::Root, current_version: root.signed.version, new_version: new_root.signed.version });

Esta alteração garante que o cliente baixe e aplique os metadados raiz em ordem (N, N+1, N+2, ...) sem pular. Se um arquivo de metadados raiz for encontrado com uma versão que não seja exatamente old_version+1, o Tough agora trata isso como um possível ataque e aborta a atualização.

• Causa raiz: Verificação sequencial de versão ausente (CWE-1288: Improper Validation of Integrity Check Value). O código apenas protegia contra uma raiz nova mais antiga que a atual, mas não contra saltos inesperados.
• Remediação: Atualize para tough = 0.20.0, que inclui o patch. Garanta que quaisquer forks ou atualizadores personalizados baseados no Tough implementem a mesma verificação rigorosa. Também é prudente auditar os logs em busca de saltos suspeitos de versão raiz no histórico de atualizações como um indicador de tentativa de exploração.

CVE-2025-2886: Delegação Terminante Não Respeitada

O Tough tratou incorretamente os papéis de alvos delegados “terminantes” conforme definidos pelo TUF. Em um repositório TUF, uma delegação pode ser marcada como terminante, o que significa que, se uma busca por alvo alcançar essa delegação e o alvo não for encontrado nela, a busca deve parar (e não continuar para outras delegações de prioridade mais baixa)​. (veja aqui) Devido a um erro de lógica, o Tough falhou em encerrar a busca nesse caso – ele continuava buscando em delegações subsequentes mesmo quando deveria ter parado. Isso poderia permitir que um invasor que controla uma delegação de prioridade mais baixa servisse conteúdo para alvos que não deveria controlar, contornando os limites de confiança pretendidos.​

• Aviso: GitHub Security Advisory GHSA-v4wr-j3w6-mxqc (CVE-2025-2886)​
• Código afetado: O algoritmo de busca de alvos em tough/src/editor/targets.rs (e o código relacionado de resolução de delegações). O código vulnerável não tratava corretamente a flag terminating nas delegações. Ao iterar pelas delegações em busca de um alvo, o Tough prosseguia para a próxima delegação mesmo se a atual estivesse marcada como terminante e não tivesse correspondência, contrariando a especificação do TUF.

Implementação vulnerável: No Tough <0.20.0, a lógica de find_target() simplesmente fazia recursão ou percorria todos os papéis delegados possíveis até que um alvo fosse encontrado ou todos fossem esgotados. Ela não definia nenhuma flag nem interrompia o loop ao encontrar um papel terminante. Pseudocódigo do comportamento antigo:```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. }

Além disso, as chamadas recursivas a find_target agora carregam um sinalizador terminated para garantir que, uma vez que a terminação seja sinalizada, nenhuma outra delegação seja considerada nos loops de nível superior​. O RepositoryEditor::delegate_role do Tough e as estruturas relacionadas também foram atualizados para armazenar o atributo terminating e passá-lo pela lógica de busca.

• Causa raiz: Uma falha lógica onde o código não implementava a semântica de delegação terminante (CWE-284: Controle de Acesso Impróprio – papéis de prioridade mais baixa poderiam sobrepor restrições pretendidas)​. Essencialmente, a ausência de um break em uma delegação terminante permitia que dados de alvos não autorizados fossem considerados.
• Impacto: Clientes podiam buscar alvos pertencentes ao papel errado – especificamente, se um projeto delegasse um subconjunto de alvos a outra parte (e marcasse essa delegação como terminante para limitar o escopo de sobreposição), essa parte ainda poderia servir conteúdo arbitrário para alvos fora do seu escopo. Isso quebra hierarquias de confiança em um repositório TUF.
• Remediação: Atualize para tough 0.20.0+, que implementa corretamente o tratamento de delegações terminantes. Se você mantém um fork ou cliente personalizado, garanta que sua busca de alvos pare em delegações terminantes. Testadores de segurança devem tentar cenários de abuso de delegação apenas em versões mais antigas; a versão corrigida ignorará corretamente respostas maliciosas de prioridade mais baixa.

CVE-2025-2887: Detecção Incompleta de Rollback para Alvos Delegados

A lógica do Tough para detectar ataques de rollback em metadados de snapshot estava incompleta. Especificamente, ao atualizar o papel de Snapshot, o Tough deve verificar que todos os metadados de alvos vistos anteriormente (incluindo alvos delegados) ainda estão presentes e não foram revertidos para versões anteriores no novo snapshot. (ver aqui) O Tough realmente aplicava isso para o targets.json de nível superior, mas falhava ao fazer o mesmo para arquivos de metadados de alvos delegados. Essa lacuna poderia permitir que um atacante removesse ou revertesse um arquivo de alvo delegado nos metadados de snapshot do repositório sem detecção, fazendo o cliente aceitar um arquivo de alvo delegado desatualizado (ou ausente) como se estivesse atualizado​.

• Aviso: GitHub Security Advisory GHSA-q6r9-r9pw-4cf7 (CVE-2025-2887)
• Código Afetado: A verificação de atualização de snapshot em tough/src/lib.rs (função que carrega/aplica novos metadados de Snapshot). O código vulnerável apenas verificava a continuidade do papel principal targets.json no snapshot, mas não iterava sobre os papéis delegados listados nos metadados de snapshot para realizar verificações semelhantes.

Implementação Vulnerável: No Tough <0.20.0, após recuperar um novo snapshot.json, o cliente garantia que os papéis root e snapshot não sofreram rollback, e especificamente garantia que targets.json ainda estava presente. Também verificava que a versão de targets.json no novo snapshot era >= à versão anterior. No entanto, se o snapshot contivesse alvos delegados (por exemplo, metadados delegados projects.json, user.json), o cliente não os verificava. Por exemplo, originalmente o código fazia algo como:```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.)

By looping through all roles (name representa cada nome de arquivo de metadados como targets.json, delegated-role.json, etc.), o cliente detectará se algum metadado de alvo delegado foi removido ou revertido. Os erros SnapshotRoleMissing e SnapshotRoleRollback serão acionados se um papel desaparecer ou sua versão retroceder. Notavelmente, o Tough agora também garante explicitamente que o snapshot contenha pelo menos a entrada targets.json (caso contrário, ele gera erro com SnapshotTargetsMetaMissing) como uma verificação de sanidade.

• Causa raiz: Verificação incompleta – o Tough não aplicava verificações de rollback de forma uniforme aos papéis de alvos delegados. Isso é uma implementação parcial de um controle de segurança, deixando uma lacuna que invasores poderiam explorar (CWE-352: Etapa Crucial Ausente na Autorização; conceitualmente um subconjunto de problemas de verificação de integridade). O código protegia apenas os alvos de nível superior, presumindo (incorretamente) que os papéis delegados não regrediriam.
• Impacto: Um invasor capaz de manipular o repositório poderia ocultar atualizações ou reintroduzir dados antigos de alvos delegados sem que o cliente detectasse. Por exemplo, ele poderia apresentar um arquivo de alvos delegados mais antigo, assinado com uma chave agora comprometida, e como o Tough não verificava a versão desse arquivo, ele seria aceito. Na prática, isso poderia fazer com que os clientes buscassem conteúdo desatualizado ou perdessem revogações críticas de alvos delegados. (veja aqui)
• Correção: Use tough v0.20.0+, que implementa verificação completa de rollback de snapshot. Se você mantém um atualizador personalizado, garanta que, para cada arquivo de metadados confiável listado em um snapshot, o novo snapshot também o liste com um número de versão >= à versão anterior. Também é recomendável habilitar registro de logs ou auditoria para quaisquer remoções de alvos delegados nas atualizações do repositório, pois essas remoções devem ser raras e podem indicar atividade maliciosa se ocorrerem inesperadamente.

CVE-2025-2888: Cacheamento Incorreto de Metadados de Timestamp em Rollback

O Tough tratou incorretamente um rollback detectado no papel Timestamp. O papel Timestamp no TUF assina periodicamente a versão mais recente dos metadados de snapshot para ajudar os clientes a detectar se estão vendo um snapshot antigo (um rollback). O Tough de fato realizava a verificação de rollback na versão do snapshot contida no timestamp, mas somente após armazenar em cache os novos metadados do timestamp localmente. Se um rollback fosse detectado, o Tough rejeitaria a atualização, mas já teria persistido o timestamp inválido como o "mais recente" em seu cache. Isso significava que um timestamp malicioso (com uma versão de snapshot desatualizada) poderia envenenar o cache do cliente. Atualizações legítimas subsequentes poderiam então parecer rollbacks para o Tough (já que o cache continha um timestamp indicando uma versão de snapshot mais alta do que a nova), bloqueando atualizações válidas.

• Aviso: GitHub Security Advisory GHSA-76g3-38jv-wxh4 (CVE-2025-2888)
• Código afetado: A lógica de atualização do timestamp em tough/src/lib.rs (função que carrega o novo timestamp.json). O problema central era um bug de ordem de operações: o Tough atualizava seu cache/estado local com os novos metadados do Timestamp antes de validar completamente que a versão do snapshot contida neles não era mais antiga do que a que ele já havia visto.

Implementação vulnerável: No Tough <0.20.0, quando um novo timestamp.json era buscado, o cliente fazia o parse e o gravava no cache (marcando-o como o timestamp confiável atual) e então realizava a verificação de rollback na versão do snapshot. Se a versão do snapshot no novo timestamp fosse menor do que a versão de snapshot registrada anteriormente (indicando uma tentativa de rollback), o Tough registraria um erro e rejeitaria aquele ciclo de atualização – mas o cache já continha o timestamp "inválido". Não havia remoção da entrada em cache nesse caminho de erro. Assim, o registro do cliente do timestamp "confiável" poderia se tornar esse desatualizado.

Por exemplo, suponha que a última versão conhecida do snapshot fosse 5. Um invasor poderia fornecer metadados de Timestamp (com um número de versão de timestamp mais alto) que assinam a versão 4 do snapshot. O Tough aceitaria o arquivo de timestamp (armazenando-o em cache) e então notaria que snapshot 4 < 5 e abortaria a atualização com erro – mas agora seu cache diz "o timestamp mais recente indica snapshot 4". Quando um timestamp correto (snapshot 5 ou 6) chegar em seguida, o Tough enxerga snapshot 5 versus snapshot 4 no cache como outro rollback (já que erroneamente confia na versão de snapshot 4 do cache como referência) e, portanto, rejeita até a atualização válida. O boletim da AWS descreve esse ciclo: "o cliente armazena em cache os metadados de timestamp apesar de eles serem rejeitados corretamente quando um rollback era detectado... fazendo com que o tough subsequentemente falhe ao consumir atualizações válidas."

Implementação corrigida: A correção garante que as verificações de rollback ocorram antes do cacheamento do novo timestamp e adiciona validação mais rigorosa do conteúdo do timestamp. No Tough 0.20.0, a função load_timestamp() foi modificada para garantir que os metadados do Timestamp sejam bem formados e que sua versão de snapshot não seja menor do que a versão de snapshot anteriormente confiável antes de concluir a atualização. Especificamente, o código agora verifica: (a) se os metadados do timestamp possuem exatamente uma entrada (devem ser apenas para snapshot.json), (b) se essa entrada existe e é analisada, e (c) se a versão do snapshot neles é >= à versão mais antiga do snapshot. (veja aqui) Somente após essas validações passarem, o novo timestamp é considerado confiável. A lógica crítica adicionada é ilustrada abaixo:```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 } ); }