AWS-Tough-Library-Multiple-CVEs

• Avis : GitHub Security Advisory GHSA-5vmp-m5v2-hx47 (CVE-2025-2885)
• Code affecté : la logique de mise à jour de Tough pour les métadonnées racine dans tough/src/lib.rs. L’implémentation vulnérable vérifiait uniquement que la version de la nouvelle racine n’était pas inférieure à l’ancienne, au lieu d’exiger qu’elle soit la version suivante dans la séquence. Cette omission enfreint la règle de la spécification TUF selon laquelle les clients doivent télécharger les versions racine intermédiaires dans l’ordre (sans sauter de version).

Implémentation vulnérable : Dans les versions 0.19.x et antérieures, après avoir téléchargé un nouveau root.json, Tough vérifiait les signatures mais n’appliquait pas strictement la continuité des versions. Il permettait que la nouvelle version de la racine soit toute valeur >= la version approuvée. Par exemple, si la racine approuvée actuelle était la version N, Tough acceptait une nouvelle racine prétendant être la version N+2 ou supérieure (tant que les signatures étaient valides), sans tenir compte de N+1. L’extrait de code ci-dessous illustre la vérification effectuée avant le correctif :```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 });

Ce changement garantit que le client télécharge et applique les métadonnées racine dans l’ordre (N, N+1, N+2, ...) sans en sauter. Si un fichier de métadonnées racine est rencontré avec une version qui n’est pas exactement old_version+1, Tough le traite désormais comme une attaque potentielle et interrompt la mise à jour.

• Cause racine : Absence de vérification séquentielle des versions (CWE-1288: Improper Validation of Integrity Check Value). Le code ne protégeait que contre une nouvelle racine plus ancienne que la racine actuelle, mais pas contre les sauts inattendus.
• Correctif : Mettez à niveau tough = 0.20.0, qui inclut le correctif. Assurez-vous que les forks ou les programmes de mise à jour personnalisés basés sur Tough implémentent la même vérification stricte. Il est également prudent d’auditer les journaux pour détecter tout saut suspect de version racine dans l’historique des mises à jour, comme indicateur d’une tentative d’exploitation.

CVE-2025-2886 : Délégation terminante non respectée

Tough a mal géré les rôles de cibles délégués « terminants » tels que définis par TUF. Dans un dépôt TUF, une délégation peut être marquée terminante, ce qui signifie que si une recherche de cible atteint cette délégation et que la cible n’y est pas trouvée, la recherche doit s’arrêter (et ne pas continuer vers d’autres délégations de priorité inférieure). (voir ici) En raison d’une erreur logique, Tough ne parvenait pas à terminer la recherche dans ce cas – il continuait à chercher dans les délégations suivantes alors qu’il aurait dû s’arrêter. Cela pourrait permettre à un attaquant contrôlant une délégation de priorité inférieure de fournir du contenu pour des cibles qu’il ne devrait pas contrôler, contournant les frontières de confiance prévues.

• Avis : GitHub Security Advisory GHSA-v4wr-j3w6-mxqc (CVE-2025-2886)
• Code affecté : L’algorithme de recherche de cible dans tough/src/editor/targets.rs (et le code de résolution des délégations associé). Le code vulnérable ne gérait pas correctement le drapeau terminating sur les délégations. Lors de l’itération sur les délégations pour rechercher une cible, Tough passait à la délégation suivante même si la délégation courante était marquée comme terminante et ne contenait aucune correspondance, contrairement à la spécification TUF.

Implémentation vulnérable : Dans Tough <0.20.0, la logique find_target() parcourait simplement, de manière récursive ou itérative, tous les rôles délégués possibles jusqu’à ce qu’une cible soit trouvée ou que tous soient épuisés. Elle ne levait aucun drapeau et ne sortait pas de la boucle lorsqu’elle rencontrait un rôle terminant. Pseudo-code de l’ancien comportement :```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. }

De plus, les appels récursifs find_target portent désormais un indicateur terminated pour garantir qu’une fois la terminaison signalée, aucune autre délégation n’est envisagée dans les boucles de niveau supérieur​. Les structures RepositoryEditor::delegate_role de Tough et les structures associées ont également été mises à jour pour stocker l’attribut terminating et le transmettre dans la logique de recherche.

• Cause racine : Un défaut logique où le code n’implémentait pas la sémantique de délégation terminale (CWE-284 : Contrôle d’accès inapproprié – les rôles de priorité inférieure pouvaient outrepasser les restrictions prévues)​. Essentiellement, l’absence d’un break sur une délégation terminale permettait que des données de cibles non autorisées soient prises en compte.
• Impact : Les clients pouvaient récupérer des cibles appartenant au mauvais rôle – plus précisément, si un projet déléguait un sous-ensemble de cibles à une autre partie (et marquait cette délégation comme terminale afin de limiter la portée des substitutions), cette partie pouvait néanmoins fournir du contenu arbitraire pour des cibles hors de son périmètre. Cela brise les hiérarchies de confiance dans un dépôt TUF.
• Correctif : Mettre à jour vers tough 0.20.0+ qui implémente correctement la gestion des délégations terminales. Si vous maintenez un fork ou un client personnalisé, assurez-vous que votre recherche de cibles s’arrête sur les délégations terminales. Les testeurs de sécurité ne devraient tenter des scénarios d’abus de délégation que sur les versions plus anciennes ; la version corrigée ignorera correctement les réponses malveillantes de priorité inférieure.

CVE-2025-2887 : Détection incomplète de rollback pour les cibles déléguées

La logique de Tough pour détecter les attaques de rollback dans les métadonnées de snapshot était incomplète. Plus précisément, lors de la mise à jour du rôle Snapshot, Tough devrait vérifier que toutes les métadonnées de cibles déjà vues (y compris les cibles déléguées) sont toujours présentes et ne sont pas rétrogradées en version dans le nouveau snapshot. (voir ici) Tough appliquait bien cette vérification pour le targets.json de niveau supérieur, mais ne le faisait pas pour les fichiers de métadonnées de cibles déléguées. Cette faille pouvait permettre à un attaquant de supprimer ou de restaurer une version antérieure d’un fichier de cible déléguée dans les métadonnées de snapshot du dépôt sans être détecté, ce qui amenait le client à accepter un fichier de cible déléguée obsolète (ou manquant) comme s’il était à jour​.

• Avis : Avis de sécurité GitHub GHSA-q6r9-r9pw-4cf7 (CVE-2025-2887)
• Code affecté : La vérification de mise à jour du snapshot dans tough/src/lib.rs (fonction qui charge/applique les nouvelles métadonnées de snapshot). Le code vulnérable ne vérifiait que la continuité du rôle principal targets.json dans le snapshot, mais n’itérait pas sur les rôles délégués listés dans les métadonnées de snapshot pour effectuer des vérifications similaires.

Implémentation vulnérable : Dans Tough <0.20.0, après avoir récupéré un nouveau snapshot.json, le client s’assurait que les rôles root et snapshot n’étaient pas régressés, et il s’assurait spécifiquement que targets.json était toujours présent. Il vérifiait également que la version de targets.json dans le nouveau snapshot était >= la version précédente. Cependant, si le snapshot contenait des cibles déléguées (par exemple, des métadonnées déléguées projects.json, user.json), le client ne les vérifiait pas. Par exemple, à l’origine, le code faisait quelque chose comme :```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 represents each metadata filename like targets.json, delegated-role.json, etc.), the client will catch if any delegated target metadata was removed or reverted. The errors SnapshotRoleMissing and SnapshotRoleRollback will trigger if a role disappeared or its version went backwards. Notably, Tough now also explicitly ensures that the snapshot contains at least the targets.json entry (otherwise it errors with SnapshotTargetsMetaMissing) as a sanity check.

• Root Cause: Incomplete verification – Tough did not apply rollback checks uniformly to delegated target roles. This is a partial implementation of a security control, leaving a gap that attackers could exploit (CWE-352: Missing Crucial Step in Authorization; conceptually a subset of integrity verification issues). The code was only protecting top-level targets, assuming (incorrectly) that delegated roles wouldn’t regress.
• Impact: An attacker able to manipulate the repository could hide updates or re-introduce old delegated target data without client detection. For instance, they could present an older delegated targets file signed with a now-compromised key, and because Tough didn’t check that file’s version, it would be accepted. In practice, this could result in clients fetching outdated content or missing critical revocations for delegated targets. (see here)
• Remediation: Use tough v0.20.0+, which implements full snapshot rollback checking. If maintaining a custom updater, ensure that for every trusted metadata file listed in a snapshot, the new snapshot also lists it with a version number >= the previous version. It’s also recommended to enable logging or auditing for any delegated targets removals in repository updates, as these should be rare and might indicate malicious activity if occurring unexpectedly.

CVE-2025-2888: Improper Timestamp Metadata Caching on Rollback

Tough incorrectly handled a detected rollback in the Timestamp role. The Timestamp role in TUF periodically signs the latest snapshot metadata version to help clients detect if they are seeing an older snapshot (a rollback). Tough did perform the rollback check on the snapshot version contained in the timestamp, but only after caching the new timestamp metadata locally. If a rollback was detected, Tough would reject the update but had already persisted the invalid timestamp as the “latest” in its cache. This meant a malicious timestamp (with an outdated snapshot version) could poison the client’s cache. Subsequent legitimate updates could then appear to Tough as rollbacks (since the cache held a timestamp indicating a higher snapshot version than the new one), blocking valid updates.

• Advisory: GitHub Security Advisory GHSA-76g3-38jv-wxh4 (CVE-2025-2888)
• Affected Code: The timestamp update logic in tough/src/lib.rs (function that loads the new timestamp.json). The core issue was an order-of-operations bug: Tough updated its local cache/state with the new Timestamp metadata before fully validating that the snapshot version inside wasn’t older than what it had seen before.

Vulnerable Implementation: In Tough <0.20.0, when a new timestamp.json was fetched, the client would parse and write it to the cache (marking it as the current trusted timestamp) and then perform the rollback check on the snapshot version. If the snapshot version in the new timestamp was lower than the previously recorded snapshot version (indicating a rollback attempt), Tough would log an error and reject that update cycle – but the cache already held the “bad” timestamp. There was no removal of the cached entry in that error path. Thus, the client’s record of the “trusted” timestamp could become this outdated one.

For example, suppose the last known snapshot version was 5. An attacker could provide a Timestamp metadata (with a higher timestamp version number) that signs snapshot version 4. Tough would accept the timestamp file (caching it), then notice snapshot 4 < 5 and error out of the update – but now its cache says “latest timestamp indicates snapshot 4”. When a correct timestamp (snapshot 5 or 6) comes next, Tough sees snapshot 5 vs cached snapshot 4 as another rollback (since it erroneously trusts the cache’s snapshot version 4 as baseline), and thus rejects even the valid update. The AWS bulletin describes this cycle: “the client caches timestamp metadata despite it being correctly rejected when a rollback was detected… causing tough to subsequently fail to consume valid updates.”

Fixed Implementation: The fix ensures that rollback checks occur before caching the new timestamp, and adds stricter validation of the timestamp contents. In Tough 0.20.0, the load_timestamp() function was modified to enforce that the Timestamp metadata is well-formed and that its snapshot version is not less than the previously trusted snapshot version before concluding the update. Specifically, the code now checks: (a) the timestamp metadata has exactly one entry (must only be for snapshot.json), (b) that entry exists and is parsed, and (c) the snapshot version inside is >= the older snapshot version. (see here). Only after these validations pass is the new timestamp considered trusted. The critical added logic is illustrated below:```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 } ); }