AWS-Tough-Library-Multiple-CVEs

• Avviso: GitHub Security Advisory GHSA-5vmp-m5v2-hx47 (CVE-2025-2885)
• Codice interessato: La logica di aggiornamento di Tough per i root metadata in tough/src/lib.rs. L'implementazione vulnerabile controllava solo che la versione del nuovo root non fosse inferiore a quella del precedente, invece di richiedere che fosse la versione sequenziale successiva. Questa omissione viola la regola della specifica TUF secondo cui i client devono scaricare le versioni intermedie del root in ordine (senza saltare versioni).

Implementazione vulnerabile: Nella versione 0.19.x e precedenti, dopo aver scaricato un nuovo root.json, Tough verificava le firme ma non applicava rigorosamente la continuità delle versioni. Consentiva alla nuova versione del root di avere qualsiasi valore >= la versione considerata attendibile. Ad esempio, se il root attualmente considerato attendibile era la versione N, Tough accettava un nuovo root con versione N+2 o superiore (purché le firme fossero valide), saltando la N+1. Lo snippet di codice seguente illustra il controllo precedente alla correzione:```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 });

Questa modifica garantisce che il client scarichi e applichi i metadati root in ordine (N, N+1, N+2, ...) senza saltare passaggi. Se viene trovato un file di metadati root con una versione diversa da old_version+1, Tough ora lo considera un potenziale attacco e interrompe l'aggiornamento.

• Causa principale: Mancata verifica sequenziale della versione (CWE-1288: Improper Validation of Integrity Check Value). Il codice proteggeva solo dal caso in cui il nuovo root fosse più vecchio di quello corrente, ma non da salti inaspettati.
• Rimedio: Aggiornare a tough = 0.20.0, che include la patch. Assicurarsi che eventuali fork o aggiornatori personalizzati basati su Tough implementino lo stesso controllo rigoroso. È inoltre opportuno controllare i log per rilevare eventuali salti sospetti della versione root nella cronologia degli aggiornamenti, come indicatore di tentativi di sfruttamento.

CVE-2025-2886: Delegazione terminante non rispettata

Tough gestiva erroneamente i ruoli di destinazione delegati “terminating” come definiti da TUF. In un repository TUF, una delegazione può essere marcata come terminating, il che significa che se una ricerca di target raggiunge quella delegazione e il target non viene trovato, la ricerca deve fermarsi (e non continuare verso altre delegazioni a priorità inferiore). (vedi qui) A causa di un errore logico, Tough non riusciva a terminare la ricerca in questo caso: continuava a cercare nelle delegazioni successive anche quando avrebbe dovuto fermarsi. Questo potrebbe permettere a un attaccante che controlla una delegazione a priorità inferiore di servire contenuti per target che non dovrebbe controllare, bypassando i confini di fiducia previsti.

• Avviso: Avviso di sicurezza GitHub GHSA-v4wr-j3w6-mxqc (CVE-2025-2886)
• Codice interessato: L'algoritmo di ricerca dei target in tough/src/editor/targets.rs (e il relativo codice di risoluzione delle delegazioni). Il codice vulnerabile non gestiva correttamente il flag terminating sulle delegazioni. Iterando attraverso le delegazioni alla ricerca di un target, Tough passava alla delegazione successiva anche se quella corrente era marcata come terminante e non aveva trovato corrispondenza, contrariamente alle specifiche TUF.

Implementazione vulnerabile: In Tough <0.20.0, la logica di find_target() semplicemente ricorreva o iterava attraverso tutti i possibili ruoli delegati finché non trovava un target o finché non li esauriva. Non impostava alcun flag né usciva dal ciclo quando incontrava un ruolo terminante. Pseudocodice del vecchio comportamento:```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. }

Inoltre, le chiamate ricorsive a find_target ora trasportano un flag terminated per garantire che, una volta segnalata la terminazione, nessun'altra delega venga considerata nei loop di livello superiore​. Anche RepositoryEditor::delegate_role di Tough e le strutture correlate sono state aggiornate per memorizzare l'attributo terminating e passarlo attraverso la logica di ricerca.

• Causa principale: Un difetto logico per cui il codice non implementava la semantica della delega terminante (CWE-284: Improper Access Control – i ruoli a priorità inferiore potevano sovrascrivere le restrizioni previste)​. In sostanza, l'assenza di un break su una delega terminante consentiva di prendere in considerazione dati di target non autorizzati.
• Impatto: I client potevano recuperare target di proprietà del ruolo sbagliato – in particolare, se un progetto delegava un sottoinsieme di target a un'altra parte (e contrassegnava tale delega come terminante per limitare l'ambito di sovrascrittura), quella parte poteva comunque servire contenuti arbitrari per target al di fuori del proprio ambito. Questo rompe le gerarchie di fiducia in un repository TUF.
• Rimedio: Aggiornare a tough 0.20.0+ che implementa correttamente la gestione delle deleghe terminanti. Se mantieni un fork o un client personalizzato, assicurati che la ricerca dei target si interrompa in presenza di deleghe terminanti. I security tester dovrebbero provare gli scenari di abuso delle deleghe solo su versioni precedenti; la versione corretta ignorerà correttamente le risposte dannose a priorità inferiore.

CVE-2025-2887: Rilevamento incompleto del rollback per i target delegati

La logica di Tough per rilevare attacchi di rollback nei metadati dello snapshot era incompleta. In particolare, quando si aggiorna il ruolo Snapshot, Tough dovrebbe verificare che tutti i metadati dei target visti in precedenza (inclusi i target delegati) siano ancora presenti e non abbiano una versione arretrata nel nuovo snapshot. (vedi qui) Tough applicava questo controllo per targets.json di primo livello, ma non lo faceva per i file di metadati dei target delegati. Questa lacuna poteva consentire a un attaccante di rimuovere o ripristinare un file di target delegato nei metadati dello snapshot del repository senza essere rilevato, facendo sì che il client accettasse un file di target delegato obsoleto (o mancante) come se fosse aggiornato​.

• Avviso: GitHub Security Advisory GHSA-q6r9-r9pw-4cf7 (CVE-2025-2887)
• Codice interessato: La verifica dell'aggiornamento dello snapshot in tough/src/lib.rs (funzione che carica/applica i nuovi metadati dello Snapshot). Il codice vulnerabile controllava solo la continuità del ruolo principale targets.json nello snapshot, ma non iterava sui ruoli delegati elencati nei metadati dello snapshot per eseguire controlli simili.

Implementazione vulnerabile: In Tough <0.20.0, dopo aver recuperato un nuovo snapshot.json, il client si assicurava che i ruoli root e snapshot non fossero stati sottoposti a rollback e, in particolare, che targets.json fosse ancora presente. Verificava inoltre che la versione di targets.json nel nuovo snapshot fosse >= alla versione precedente. Tuttavia, se lo snapshot conteneva target delegati (ad es., metadati delegati projects.json, user.json), il client non li verificava. Ad esempio, originariamente il codice faceva qualcosa del genere:```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.)

Iterando attraverso tutti i ruoli (name rappresenta ogni nome di file di metadati come targets.json, delegated-role.json, ecc.), il client rileverà se alcuni metadati di target delegati sono stati rimossi o ripristinati. Gli errori SnapshotRoleMissing e SnapshotRoleRollback verranno attivati se un ruolo è scomparso o la sua versione è regredita. In particolare, Tough ora garantisce anche esplicitamente che lo snapshot contenga almeno la voce targets.json (altrimenti segnala un errore con SnapshotTargetsMetaMissing) come controllo di coerenza​.

• Causa principale: Verifica incompleta – Tough non applicava i controlli di rollback in modo uniforme ai ruoli di target delegati. Questa è un'implementazione parziale di un controllo di sicurezza, che lascia un varco che gli aggressori potrebbero sfruttare (CWE-352: Mancanza di un passaggio cruciale nell'autorizzazione; concettualmente un sottoinsieme dei problemi di verifica dell'integrità). Il codice proteggeva solo i target di livello superiore, assumendo (erroneamente) che i ruoli delegati non sarebbero regrediti.
• Impatto: Un aggressore in grado di manipolare il repository potrebbe nascondere aggiornamenti o re-introdurre vecchi dati di target delegati senza che il client se ne accorga. Ad esempio, potrebbe presentare un file di target delegati più vecchio firmato con una chiave ora compromessa e, poiché Tough non controllava la versione di quel file, verrebbe accettato. In pratica, questo potrebbe comportare che i client recuperino contenuti obsoleti o perdano revoche critiche per i target delegati​. (vedi qui)
• Rimedio: Utilizzare tough v0.20.0+, che implementa il controllo completo del rollback dello snapshot​. Se si mantiene un aggiornatore personalizzato, assicurarsi che per ogni file di metadati attendibile elencato in uno snapshot, il nuovo snapshot lo elenchi anch'esso con un numero di versione >= alla versione precedente. Si raccomanda inoltre di abilitare la registrazione (logging) o l'audit per qualsiasi rimozione di target delegati negli aggiornamenti del repository, poiché questi eventi dovrebbero essere rari e potrebbero indicare attività dannose se si verificano inaspettatamente.

CVE-2025-2888: Caching improprio dei metadati Timestamp durante il rollback

Tough gestiva in modo errato un rollback rilevato nel ruolo Timestamp. Il ruolo Timestamp in TUF firma periodicamente la versione più recente dei metadati dello snapshot per aiutare i client a rilevare se stanno vedendo uno snapshot più vecchio (un rollback). Tough eseguiva sì il controllo di rollback sulla versione dello snapshot contenuta nel timestamp, ma solo dopo aver memorizzato nella cache locale i nuovi metadati del timestamp. Se veniva rilevato un rollback, Tough rifiutava l'aggiornamento ma aveva già persistito il timestamp non valido come "più recente" nella sua cache. Ciò significava che un timestamp dannoso (con una versione dello snapshot obsoleta) poteva avvelenare la cache del client. Gli aggiornamenti legittimi successivi potevano quindi apparire a Tough come rollback (poiché la cache conteneva un timestamp che indicava una versione dello snapshot superiore rispetto al nuovo), bloccando aggiornamenti validi.

• Avviso di sicurezza: GitHub Security Advisory GHSA-76g3-38jv-wxh4 (CVE-2025-2888)
• Codice interessato: La logica di aggiornamento del timestamp in tough/src/lib.rs (funzione che carica il nuovo timestamp.json). Il problema centrale era un bug nell'ordine delle operazioni: Tough aggiornava la propria cache/stato locale con i nuovi metadati Timestamp prima di convalidare completamente che la versione dello snapshot al loro interno non fosse più vecchia di quella vista in precedenza.

Implementazione vulnerabile: In Tough <0.20.0, quando veniva recuperato un nuovo timestamp.json, il client lo analizzava e lo scriveva nella cache (marcandolo come timestamp attendibile corrente) e poi eseguiva il controllo di rollback sulla versione dello snapshot. Se la versione dello snapshot nel nuovo timestamp era inferiore alla versione dello snapshot registrata in precedenza (indicando un tentativo di rollback), Tough registrava un errore e rifiutava quel ciclo di aggiornamento – ma la cache conteneva già il timestamp "cattivo". Non era prevista la rimozione della voce dalla cache in quel percorso di errore. Di conseguenza, la registrazione del timestamp "attendibile" da parte del client poteva diventare quella obsoleta.

Ad esempio, supponiamo che l'ultima versione nota dello snapshot fosse la 5. Un aggressore potrebbe fornire metadati Timestamp (con un numero di versione del timestamp più alto) che firmano la versione 4 dello snapshot. Tough accetterebbe il file timestamp (memorizzandolo nella cache), poi noterebbe che lo snapshot 4 < 5 e uscirebbe dall'aggiornamento con un errore – ma ora la sua cache dice "l'ultimo timestamp indica lo snapshot 4". Quando arriva un timestamp corretto (snapshot 5 o 6), Tough vede lo snapshot 5 rispetto allo snapshot 4 in cache come un altro rollback (poiché si fida erroneamente della versione 4 dello snapshot in cache come riferimento) e quindi rifiuta anche l'aggiornamento valido. Il bollettino AWS descrive questo ciclo: "il client memorizza nella cache i metadati del timestamp nonostante vengano correttamente rifiutati quando viene rilevato un rollback… facendo sì che tough successivamente non riesca a consumare aggiornamenti validi."​

Implementazione corretta: La correzione garantisce che i controlli di rollback avvengano prima della memorizzazione nella cache del nuovo timestamp e aggiunge una validazione più rigorosa del contenuto del timestamp. In Tough 0.20.0, la funzione load_timestamp() è stata modificata per imporre che i metadati Timestamp siano ben formati e che la loro versione dello snapshot non sia inferiore alla versione dello snapshot precedentemente attendibile prima di concludere l'aggiornamento. Nello specifico, il codice ora verifica: (a) che i metadati del timestamp abbiano esattamente una voce (deve essere solo per snapshot.json), (b) che quella voce esista e sia analizzata, e (c) che la versione dello snapshot al suo interno sia >= alla versione precedente dello snapshot. (vedi qui) Solo dopo che queste validazioni hanno avuto esito positivo, il nuovo timestamp è considerato attendibile. La logica critica aggiunta è illustrata di seguito:```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 } ); }