murataydemir/aws-tough-library-multiple-cvesProblem mit tough, Versionen vor 0.20.0 (mehrere CVEs)
Im März 2025 wurden mehrere Sicherheitslücken in der Tough-Bibliothek von AWS Labs (einer Rust-Client-Implementierung von TUF – The Update Framework) bekannt gegeben. Diese Probleme werden unter CVE-2025-2885, CVE-2025-2886, CVE-2025-2887 und CVE-2025-2888 geführt und wurden in Tough Version 0.20.0 behoben. Sicherheitsingenieure können dieses Dokument verwenden, um die technischen Details jeder Schwachstelle, die Grundursache in der Codebasis und die Patches zu verstehen, die sie beheben. Allen Benutzern von Tough < 0.20.0 wird dringend empfohlen, auf v0.20.0 oder höher zu aktualisieren.
Tough hat es versäumt, die Version der Root metadata während des Updates in der richtigen Reihenfolge zu validieren. Ein Angreifer, der ein Repository kontrolliert (oder über Man-in-the-Middle-Fähigkeiten verfügt), könnte eine Root-Metadatendatei mit einer unerwarteten Versionsnummer bereitstellen, wodurch der Client eine falsche Version abruft und ihr vertraut. Im Wesentlichen hat Tough nicht sichergestellt, dass die Version einer neuen Root-Metadaten um genau eins höher war als die zuvor vertrauenswürdige Version, was gegen die Anforderung von TUF an eine kontinuierliche Vertrauenskette verstößt. Dies könnte zu Rollback- oder Mix-and-Match-Angriffen führen, bei denen eine alte (aber ordnungsgemäß signierte) Root als die neueste akzeptiert wird, was möglicherweise ausgemusterte Signaturschlüssel oder abgelaufenes Vertrauen wieder einführt.
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
});
Ein Angreifer könnte dies ausnutzen, indem er <b>Root-Metadaten mit einer höheren Version präsentiert, die tatsächlich ein älterer Schlüsselsatz sind</b>. Tough würde dies akzeptieren, in der Annahme, es sei ein Update, und [Inhalten vertrauen, die mit veralteten Schlüsseln signiert wurden](https://github.com/advisories/GHSA-5vmp-m5v2-hx47#:~:text=The%20tough%20client%20will%20trust,with%20a%20previous%20root%20role).
<b>Korrigierte Implementierung:</b> Der gepatchte Code (in Tough 0.20.0) verlangt ausdrücklich, dass die Version der neuen Root-Metadaten genau eins größer ist als die alte Version, siehe [commit 0eeb60a](https://github.com/awslabs/tough/commit/0eeb60aefe27f00b65730634b788a1aafb8bf3c6). Er stellt außerdem sicher, dass die neue Version höher ist (verhindert Gleichheit oder Verringerung) und verhindert jeden Sprung größer als +1:```rust
// (Fixed in v0.20.0) Enforce sequential root version update (new_version == old_version + 1)
ensure!(
root.signed.version < new_root.signed.version &&
root.signed.version.get() + 1 == new_root.signed.version.get(),
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.
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.
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.