AWS-Tough-Library-Multiple-CVEs

• Sicherheitshinweis: GitHub Security Advisory GHSA-5vmp-m5v2-hx47 (CVE-2025-2885)
• Betroffener Code: Toughs Aktualisierungslogik für Root-Metadaten in tough/src/lib.rs. Die anfällige Implementierung prüfte nur, ob die Version der neuen Root nicht kleiner war als die alte, anstatt zu verlangen, dass es sich um die nächste sequenzielle Version handelt. Diese Auslassung verstößt gegen die Regel der TUF-Spezifikation, dass Clients Zwischenversionen der Root in der richtigen Reihenfolge herunterladen müssen (kein Überspringen von Versionen).

Anfällige Implementierung: In Version 0.19.x und früher verifizierte Tough nach dem Herunterladen einer neuen root.json zwar Signaturen, setzte die Versionskontinuität jedoch nicht strikt durch. Es erlaubte der neuen Root-Version, einen beliebigen Wert >= der vertrauenswürdigen Version anzunehmen. Wenn beispielsweise die aktuell vertrauenswürdige Root Version N war, akzeptierte Tough eine neue Root mit Version N+2 oder höher (solange die Signaturen gültig waren) und übersprang dabei N+1. Der folgende Codeausschnitt zeigt die Prüfung vor der Korrektur:```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 });

Dieser Wechsel stellt sicher, dass der Client Root-Metadaten in der Reihenfolge (N, N+1, N+2, ...) herunterlädt und anwendet, ohne sie zu überspringen. Wenn eine Root-Metadaten-Datei mit einer Version angetroffen wird, die nicht exakt old_version+1 ist, behandelt Tough dies nun als potenziellen Angriff und bricht das Update ab.

• Grundursache: Fehlende sequenzielle Versionsprüfung (CWE-1288: Improper Validation of Integrity Check Value). Der Code schützte nur davor, dass die neue Root älter als die aktuelle ist, jedoch nicht vor unerwarteten Versionssprüngen.
• Behebung: Aktualisieren Sie auf tough = 0.20.0, das den Patch enthält. Stellen Sie sicher, dass alle Forks oder benutzerdefinierten Updater, die auf Tough basieren, dieselbe strikte Prüfung implementieren. Es ist außerdem ratsam, Protokolle auf verdächtige Sprünge in der Root-Version im Update-Verlauf zu prüfen, da diese auf einen versuchten Angriff hindeuten könnten.

CVE-2025-2886: Terminierende Delegation nicht beachtet

Tough behandelte die von TUF definierten „terminierenden“ delegierten Targets-Rollen falsch. In einem TUF-Repository kann eine Delegation als terminierend markiert werden, was bedeutet, dass die Suche gestoppt werden soll, wenn eine Target-Suche diese Delegation erreicht und das Target dort nicht gefunden wird (und nicht mit anderen Delegationen niedrigerer Priorität fortgesetzt werden soll)​. (siehe hier) Aufgrund eines Logikfehlers beendete Tough die Suche in diesem Fall nicht – es durchsuchte weiterhin nachfolgende Delegationen, obwohl es hätte aufhören müssen. Dies könnte es einem Angreifer, der eine Delegation mit niedrigerer Priorität kontrolliert, ermöglichen, Inhalte für Targets auszuliefern, die er nicht kontrollieren dürfte, und damit die vorgesehenen Vertrauensgrenzen umgehen.​

• Sicherheitshinweis: GitHub Security Advisory GHSA-v4wr-j3w6-mxqc (CVE-2025-2886)​
• Betroffener Code: Der Target-Lookup-Algorithmus in tough/src/editor/targets.rs (und der zugehörige Code zur Delegationsauflösung). Der anfällige Code behandelte das Flag terminating bei Delegationen nicht korrekt. Beim Durchlaufen der Delegationen auf der Suche nach einem Target fuhr Tough mit der nächsten Delegation fort, selbst wenn die aktuelle als terminierend markiert war und keinen Treffer ergab – entgegen der TUF-Spezifikation.

Anfällige Implementierung: In Tough <0.20.0 durchlief die find_target()-Logik einfach rekursiv oder in einer Schleife alle möglichen delegierten Rollen, bis ein Target gefunden oder alle erschöpft waren. Es wurde kein Flag gesetzt und kein Ausstieg ausgeführt, wenn eine terminierende Rolle angetroffen wurde. Pseudocode des alten Verhaltens:```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. }

Zusätzlich tragen die rekursiven find_target-Aufrufe nun ein terminated-Flag, um sicherzustellen, dass nach einem Terminierungssignal keine anderen Delegationen in übergeordneten Schleifen berücksichtigt werden. Toughs RepositoryEditor::delegate_role und zugehörige Strukturen wurden ebenfalls aktualisiert, um das Attribut terminating zu speichern und es durch die Suchlogik zu reichen.

• Grundursache: Ein logischer Fehler, bei dem der Code die Semantik terminierender Delegationen nicht umsetzte (CWE-284: Improper Access Control – Rollen mit niedrigerer Priorität konnten beabsichtigte Einschränkungen außer Kraft setzen). Im Wesentlichen erlaubte das Fehlen eines break bei einer terminierenden Delegation, dass nicht autorisierte Zieldaten berücksichtigt wurden.
• Auswirkungen: Clients konnten Ziele abrufen, die der falschen Rolle gehörten – insbesondere, wenn ein Projekt eine Teilmenge von Zielen an eine andere Partei delegierte (und diese Delegation als terminierend markierte, um den Überschreibungsbereich zu begrenzen), konnte diese Partei weiterhin beliebige Inhalte für Ziele außerhalb ihres Bereichs ausliefern. Dies bricht Vertrauenshierarchien in einem TUF-Repository.
• Behebung: Aktualisieren Sie auf tough 0.20.0+, das die Behandlung terminierender Delegationen korrekt implementiert. Wenn Sie einen Fork oder einen benutzerdefinierten Client pflegen, stellen Sie sicher, dass Ihre Target-Suche bei terminierenden Delegationen anhält. Sicherheitstester sollten Szenarien zum Missbrauch von Delegationen nur auf älteren Versionen versuchen; die gepatchte Version ignoriert bösartige Antworten mit niedrigerer Priorität korrekt.

CVE-2025-2887: Unvollständige Rollback-Erkennung für delegierte Targets

Toughs Logik zur Erkennung von Rollback-Angriffen in Snapshot-Metadaten war unvollständig. Konkret sollte Tough beim Aktualisieren der Snapshot-Rolle überprüfen, dass alle zuvor gesehenen Targets-Metadaten (einschließlich delegierter Targets) im neuen Snapshot weiterhin vorhanden und nicht auf eine ältere Version zurückgesetzt sind. (siehe hier) Tough setzte dies zwar für die oberste Ebene targets.json durch, versäumte es jedoch bei delegierten Target-Metadatendateien. Diese Lücke könnte es einem Angreifer ermöglichen, eine delegierte Target-Datei in den Snapshot-Metadaten des Repositorys unbemerkt zu entfernen oder zurückzusetzen, wodurch der Client eine veraltete (oder fehlende) delegierte Target-Datei als aktuell akzeptiert.

• Sicherheitshinweis: GitHub Security Advisory GHSA-q6r9-r9pw-4cf7 (CVE-2025-2887)
• Betroffener Code: Die Snapshot-Aktualisierungsprüfung in tough/src/lib.rs (Funktion, die neue Snapshot-Metadaten lädt/anwendet). Der anfällige Code prüfte nur die Kontinuität der Hauptrolle targets.json im Snapshot, iterierte jedoch nicht über delegierte Rollen, die in den Snapshot-Metadaten aufgeführt sind, um ähnliche Prüfungen durchzuführen.

Anfällige Implementierung: In Tough <0.20.0 stellte der Client nach dem Abruf einer neuen snapshot.json sicher, dass die Rollen root und snapshot nicht zurückgesetzt wurden, und stellte insbesondere sicher, dass targets.json weiterhin vorhanden war. Außerdem prüfte er, ob die Version von targets.json im neuen Snapshot >= der vorherigen Version war. Wenn der Snapshot jedoch delegierte Targets enthielt (z. B. delegierte Metadaten projects.json, user.json), prüfte der Client diese nicht. Beispielsweise führte der Code ursprünglich etwa Folgendes aus:```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.)

Indem der Client alle Rollen durchläuft (der Name steht für jeden Metadaten-Dateinamen wie targets.json, delegated-role.json usw.), erkennt er, wenn Metadaten delegierter Ziele entfernt oder zurückgesetzt wurden. Die Fehler SnapshotRoleMissing und SnapshotRoleRollback werden ausgelöst, wenn eine Rolle verschwunden ist oder ihre Version zurückgegangen ist. Bemerkenswert ist, dass Tough nun auch explizit sicherstellt, dass der Snapshot mindestens den Eintrag targets.json enthält (andernfalls wird der Fehler SnapshotTargetsMetaMissing ausgelöst), als Plausibilitätsprüfung.

• Grundursache: Unvollständige Überprüfung – Tough wandte Rollback-Prüfungen nicht einheitlich auf delegierte Zielrollen an. Dies ist eine teilweise Umsetzung einer Sicherheitskontrolle, die eine Lücke hinterlässt, die Angreifer ausnutzen könnten (CWE-352: Fehlender entscheidender Schritt bei der Autorisierung; konzeptionell eine Teilmenge von Integritätsprüfungsproblemen). Der Code schützte nur Top-Level-Ziele und nahm fälschlicherweise an, dass delegierte Rollen nicht zurückfallen würden.
• Auswirkung: Ein Angreifer, der das Repository manipulieren kann, könnte Updates verbergen oder alte Daten delegierter Ziele erneut einführen, ohne dass der Client es bemerkt. Beispielsweise könnte er eine ältere Datei für delegierte Ziele vorlegen, die mit einem inzwischen kompromittierten Schlüssel signiert ist, und da Tough die Version dieser Datei nicht prüfte, würde sie akzeptiert. In der Praxis könnte dies dazu führen, dass Clients veraltete Inhalte abrufen oder kritische Widerrufe für delegierte Ziele übersehen. (siehe hier)
• Gegenmaßnahme: Verwenden Sie tough v0.20.0+, das eine vollständige Snapshot-Rollback-Überprüfung implementiert. Wenn Sie einen eigenen Updater verwalten, stellen Sie sicher, dass für jede vertrauenswürdige Metadatendatei, die in einem Snapshot aufgeführt ist, der neue Snapshot sie ebenfalls mit einer Versionsnummer >= der vorherigen Version aufführt. Außerdem wird empfohlen, für jegliche Entfernung delegierter Ziele bei Repository-Updates Protokollierung oder Auditing zu aktivieren, da diese selten vorkommen sollten und bei unerwartetem Auftreten auf böswillige Aktivitäten hindeuten könnten.

CVE-2025-2888: Fehlerhaftes Caching von Timestamp-Metadaten bei Rollback

Tough behandelte ein erkanntes Rollback in der Timestamp-Rolle falsch. Die Timestamp-Rolle in TUF signiert regelmäßig die neueste Snapshot-Metadatenversion, um Clients dabei zu helfen zu erkennen, ob sie einen älteren Snapshot (ein Rollback) sehen. Tough führte zwar die Rollback-Überprüfung für die im Timestamp enthaltene Snapshot-Version durch, jedoch erst nachdem die neuen Timestamp-Metadaten lokal zwischengespeichert wurden. Wenn ein Rollback erkannt wurde, lehnte Tough das Update ab, hatte aber den ungültigen Timestamp bereits als „neuesten“ in seinem Cache gespeichert. Das bedeutete, dass ein bösartiger Timestamp (mit einer veralteten Snapshot-Version) den Cache des Clients vergiften konnte. Nachfolgende legitime Updates konnten Tough dann wie Rollbacks erscheinen (da der Cache einen Timestamp mit einer höheren Snapshot-Version als der neue enthielt), wodurch gültige Updates blockiert wurden.

• Sicherheitshinweis: GitHub Security Advisory GHSA-76g3-38jv-wxh4 (CVE-2025-2888)
• Betroffener Code: Die Timestamp-Update-Logik in tough/src/lib.rs (Funktion, die die neue timestamp.json lädt). Das Kernproblem war ein Fehler in der Reihenfolge der Operationen: Tough aktualisierte seinen lokalen Cache/Status mit den neuen Timestamp-Metadaten, bevor es vollständig validierte, dass die darin enthaltene Snapshot-Version nicht älter war als die zuvor gesehene.

Anfällige Implementierung: In Tough <0.20.0 analysierte und schrieb der Client eine neue timestamp.json in den Cache (wodurch sie als aktueller vertrauenswürdiger Timestamp markiert wurde) und führte dann die Rollback-Überprüfung auf die Snapshot-Version durch. Wenn die Snapshot-Version im neuen Timestamp niedriger war als die zuvor aufgezeichnete Snapshot-Version (was auf einen Rollback-Versuch hindeutete), protokollierte Tough einen Fehler und lehnte diesen Update-Zyklus ab – aber der Cache enthielt bereits den „schlechten“ Timestamp. In diesem Fehlerpfad wurde der zwischengespeicherte Eintrag nicht entfernt. Dadurch konnte der Datensatz des Clients für den „vertrauenswürdigen“ Timestamp dieser veraltete werden.

Angenommen, die zuletzt bekannte Snapshot-Version war 5. Ein Angreifer könnte Timestamp-Metadaten (mit einer höheren Timestamp-Versionsnummer) bereitstellen, die Snapshot-Version 4 signieren. Tough würde die Timestamp-Datei akzeptieren (und sie zwischenspeichern), dann feststellen, dass Snapshot 4 < 5 ist, und den Update-Vorgang mit einem Fehler abbrechen – aber sein Cache sagt nun „neuester Timestamp zeigt auf Snapshot 4“. Wenn als Nächstes ein korrekter Timestamp (Snapshot 5 oder 6) kommt, sieht Tough Snapshot 5 im Vergleich zum zwischengespeicherten Snapshot 4 als weiteres Rollback (da es fälschlicherweise der Cache-Version 4 als Basis vertraut) und lehnt folglich sogar das gültige Update ab. Das AWS-Bulletin beschreibt diesen Kreislauf: „Der Client cached Timestamp-Metadaten, obwohl sie bei Erkennung eines Rollbacks korrekt abgelehnt wurden … was dazu führt, dass Tough anschließend keine gültigen Updates mehr konsumieren kann.“

Behobene Implementierung: Der Fix stellt sicher, dass Rollback-Prüfungen vor dem Zwischenspeichern des neuen Timestamps erfolgen, und fügt eine strengere Validierung des Timestamp-Inhalts hinzu. In Tough 0.20.0 wurde die Funktion load_timestamp() so geändert, dass vor Abschluss des Updates erzwungen wird, dass die Timestamp-Metadaten wohlgeformt sind und ihre Snapshot-Version nicht kleiner ist als die zuvor vertrauenswürdige Snapshot-Version. Konkret prüft der Code jetzt: (a) Die Timestamp-Metadaten haben genau einen Eintrag (der nur für snapshot.json sein darf), (b) dieser Eintrag existiert und wird geparst, und (c) die darin enthaltene Snapshot-Version ist >= der älteren Snapshot-Version. (siehe hier) Erst wenn diese Validierungen bestanden sind, gilt der neue Timestamp als vertrauenswürdig. Die kritische neue Logik wird unten veranschaulicht:```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 } ); }