AWS-Tough-Library-Multiple-CVEs

• Aviso: GitHub Security Advisory GHSA-5vmp-m5v2-hx47 (CVE-2025-2885)
• Código afectado: la lógica de actualización de Tough para los metadatos root en tough/src/lib.rs. La implementación vulnerable solo comprobaba que la versión de la nueva root no fuera inferior a la anterior, en lugar de exigir que fuera la siguiente versión secuencial​. Esta omisión rompe la regla de la especificación TUF según la cual los clientes deben descargar las versiones intermedias de root en orden (sin saltarse versiones).

Implementación vulnerable: En la versión 0.19.x y anteriores, tras descargar un nuevo root.json, Tough verificaba las firmas pero no aplicaba estrictamente la continuidad de versiones. Permitía que la nueva versión de root fuera cualquier valor >= la versión confiable. Por ejemplo, si la root confiable actual era la versión N, Tough aceptaría una nueva root que afirmara ser la versión N+2 o superior (siempre que las firmas fueran válidas), omitiendo la N+1. El siguiente fragmento de código ilustra la comprobación anterior a la corrección:```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 });

Este cambio garantiza que el cliente descargue y aplique los metadatos raíz en orden (N, N+1, N+2, ...) sin omitir ninguno. Si se encuentra un archivo de metadatos raíz con una versión que no sea exactamente old_version+1, Tough ahora lo trata como un posible ataque y aborta la actualización.

• Causa raíz: Falta de comprobación secuencial de versiones (CWE-1288: Validación incorrecta del valor de comprobación de integridad) El código solo protegía contra una raíz nueva más antigua que la actual, pero no contra saltos inesperados.
• Solución: Actualizar a tough = 0.20.0, que incluye el parche. Asegúrese de que cualquier fork o actualizador personalizado basado en Tough implemente la misma comprobación estricta. También es aconsejable auditar los registros para detectar saltos sospechosos de versión raíz en el historial de actualizaciones como indicador de un intento de explotación.

CVE-2025-2886: No se respeta la delegación terminante

Tough gestionó incorrectamente los roles de objetivos delegados “terminantes” según lo definido por TUF. En un repositorio TUF, una delegación puede marcarse como terminante, lo que significa que si una búsqueda de objetivo llega a esa delegación y el objetivo no se encuentra allí, la búsqueda debe detenerse (y no continuar con otras delegaciones de menor prioridad)​. (ver aquí) Debido a un error de lógica, Tough no logró terminar la búsqueda en este caso: continuaba buscando en delegaciones posteriores incluso cuando debería haberse detenido. Esto podría permitir que un atacante que controle una delegación de menor prioridad sirva contenido para objetivos que no debería controlar, evadiendo los límites de confianza previstos.​

• Aviso: Aviso de seguridad de GitHub GHSA-v4wr-j3w6-mxqc (CVE-2025-2886)​
• Código afectado: El algoritmo de búsqueda de objetivos en tough/src/editor/targets.rs (y el código relacionado de resolución de delegaciones). El código vulnerable no manejaba correctamente el indicador terminating en las delegaciones. Al iterar sobre las delegaciones en busca de un objetivo, Tough pasaba a la siguiente delegación incluso si la actual estaba marcada como terminante y no había coincidencia, en contra de la especificación TUF.

Implementación vulnerable: En Tough <0.20.0, la lógica de find_target() simplemente recurría o recorría todos los roles delegados posibles hasta encontrar un objetivo o agotarlos todos. No establecía ningún indicador ni salía del bucle al encontrar un rol terminante. Pseudocódigo del comportamiento anterior:```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. }

Adicionalmente, las llamadas recursivas a find_target ahora llevan una marca terminated para garantizar que, una vez que se señala la terminación, no se consideren otras delegaciones en los bucles de nivel superior​. Las estructuras RepositoryEditor::delegate_role y relacionadas de Tough también se actualizaron para almacenar el atributo terminating y propagarlo a través de la lógica de búsqueda.

• Causa raíz: Un fallo lógico donde el código no implementaba la semántica de delegación terminante (CWE-284: Improper Access Control – los roles de menor prioridad podían anular las restricciones previstas)​. Esencialmente, la ausencia de un break en una delegación terminante permitía que se consideraran datos de targets no autorizados.
• Impacto: Los clientes podían obtener targets propiedad del rol equivocado; específicamente, si un proyecto delegaba un subconjunto de targets a otra parte (y marcaba esa delegación como terminante para limitar el alcance de anulación), esa parte aún podía servir contenido arbitrario para targets fuera de su alcance. Esto rompe las jerarquías de confianza en un repositorio TUF.
• Remediación: Actualice a tough 0.20.0+, que implementa correctamente el manejo de delegaciones terminantes. Si mantiene un fork o un cliente personalizado, asegúrese de que su búsqueda de targets se detenga en las delegaciones terminantes. Los testers de seguridad solo deberían intentar escenarios de abuso de delegación en versiones antiguas; la versión parcheada ignorará correctamente las respuestas maliciosas de menor prioridad.

CVE-2025-2887: Detección incompleta de rollback para targets delegados

La lógica de Tough para detectar ataques de rollback en los metadatos de snapshot era incompleta. Específicamente, al actualizar el rol Snapshot, Tough debería verificar que todos los metadatos de targets vistos previamente (incluidos los targets delegados) sigan presentes y no tengan versiones anteriores en el nuevo snapshot. (ver aquí) Tough sí aplicaba esto para el targets.json de nivel superior, pero no lo hacía para los archivos de metadatos de targets delegados. Esta brecha podría permitir que un atacante eliminara o revirtiera un archivo de target delegado en los metadatos de snapshot del repositorio sin ser detectado, lo que provocaba que el cliente aceptara un archivo de target delegado desactualizado (o faltante) como si estuviera actualizado​.

• Aviso: GitHub Security Advisory GHSA-q6r9-r9pw-4cf7 (CVE-2025-2887)
• Código afectado: La verificación de actualización de snapshot en tough/src/lib.rs (función que carga/aplica los nuevos metadatos de Snapshot). El código vulnerable solo comprobaba la continuidad del rol principal targets.json en el snapshot, pero no iteraba sobre los roles delegados listados en los metadatos de snapshot para realizar comprobaciones similares.

Implementación vulnerable: En Tough <0.20.0, después de recuperar un nuevo snapshot.json, el cliente se aseguraba de que los roles root y snapshot no se revirtieran, y específicamente se aseguraba de que targets.json siguiera presente. También verificaba que la versión de targets.json en el nuevo snapshot fuera >= la versión anterior. Sin embargo, si el snapshot contenía targets delegados (p. ej., metadatos delegados projects.json, user.json), el cliente no los verificaba. Por ejemplo, originalmente el código hacía 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.)

Al recorrer todos los roles (el nombre representa cada nombre de archivo de metadatos como targets.json, delegated-role.json, etc.), el cliente detectará si se eliminó o revirtió algún metadato de targets delegados. Los errores SnapshotRoleMissing y SnapshotRoleRollback se activarán si un rol desapareció o su versión retrocedió. Notablemente, Tough ahora también garantiza explícitamente que el snapshot contenga al menos la entrada targets.json (de lo contrario, devuelve un error con SnapshotTargetsMetaMissing) como comprobación de cordura​.

• Causa raíz: Verificación incompleta: Tough no aplicaba comprobaciones de rollback de manera uniforme a los roles de targets delegados. Esto es una implementación parcial de un control de seguridad, lo que deja una brecha que los atacantes podrían explotar (CWE-352: Missing Crucial Step in Authorization; conceptualmente un subconjunto de problemas de verificación de integridad). El código solo protegía los targets de nivel superior, asumiendo (incorrectamente) que los roles delegados no retrocederían.
• Impacto: Un atacante capaz de manipular el repositorio podría ocultar actualizaciones o reintroducir datos antiguos de targets delegados sin que el cliente lo detecte. Por ejemplo, podría presentar un archivo de targets delegados más antiguo firmado con una clave ahora comprometida y, como Tough no verificaba la versión de ese archivo, sería aceptado. En la práctica, esto podría dar lugar a que los clientes obtengan contenido desactualizado o pierdan revocaciones críticas de targets delegados. (ver aquí)
• Remediación: Use tough v0.20.0+, que implementa la comprobación completa de rollback del snapshot​. Si se mantiene un actualizador personalizado, asegúrese de que, para cada archivo de metadatos de confianza listado en un snapshot, el nuevo snapshot también lo liste con un número de versión >= la versión anterior. También se recomienda habilitar registros o auditorías para cualquier eliminación de targets delegados en las actualizaciones del repositorio, ya que deberían ser raras y podrían indicar actividad maliciosa si ocurren inesperadamente.

CVE-2025-2888: Caché inadecuado de metadatos de Timestamp durante un rollback

Tough manejó incorrectamente un rollback detectado en el rol Timestamp. El rol Timestamp en TUF firma periódicamente la última versión de metadatos del snapshot para ayudar a los clientes a detectar si están viendo un snapshot más antiguo (un rollback). Tough sí realizaba la comprobación de rollback en la versión del snapshot contenida en el timestamp, pero solo después de almacenar en caché localmente los nuevos metadatos del timestamp. Si se detectaba un rollback, Tough rechazaba la actualización pero ya había persistido el timestamp inválido como el “más reciente” en su caché. Esto significaba que un timestamp malicioso (con una versión de snapshot desactualizada) podía envenenar la caché del cliente. Las actualizaciones legítimas posteriores podrían entonces parecerle a Tough rollbacks (ya que la caché contenía un timestamp que indicaba una versión de snapshot más alta que la nueva), bloqueando actualizaciones válidas.

• Aviso de seguridad: GitHub Security Advisory GHSA-76g3-38jv-wxh4 (CVE-2025-2888)
• Código afectado: La lógica de actualización del timestamp en tough/src/lib.rs (función que carga el nuevo timestamp.json). El problema central era un error de orden de operaciones: Tough actualizaba su caché/estado local con los nuevos metadatos de Timestamp antes de validar completamente que la versión del snapshot en su interior no fuera anterior a la que ya había visto antes.

Implementación vulnerable: En Tough <0.20.0, cuando se obtenía un nuevo timestamp.json, el cliente lo analizaba y lo escribía en la caché (marcándolo como el timestamp de confianza actual) y luego realizaba la comprobación de rollback en la versión del snapshot. Si la versión del snapshot en el nuevo timestamp era inferior a la versión de snapshot registrada anteriormente (lo que indicaba un intento de rollback), Tough registraba un error y rechazaba ese ciclo de actualización – pero la caché ya contenía el timestamp “malo”. No se eliminaba la entrada de la caché en esa ruta de error. Por lo tanto, el registro del cliente del timestamp “de confianza” podía convertirse en este obsoleto.

Por ejemplo, supongamos que la última versión de snapshot conocida era 5. Un atacante podría proporcionar un metadato de Timestamp (con un número de versión de timestamp más alto) que firma la versión de snapshot 4. Tough aceptaría el archivo de timestamp (almacenándolo en caché), luego notaría que snapshot 4 < 5 y fallaría la actualización – pero ahora su caché dice “el último timestamp indica snapshot 4”. Cuando llegue a continuación un timestamp correcto (snapshot 5 o 6), Tough verá snapshot 5 frente al snapshot 4 en caché como otro rollback (ya que erróneamente confía en la versión de snapshot 4 de la caché como referencia) y, por tanto, rechazará incluso la actualización válida. El boletín de AWS describe este ciclo: “el cliente almacena en caché los metadatos del timestamp a pesar de que se rechazan correctamente cuando se detecta un rollback… lo que hace que tough posteriormente no pueda consumir actualizaciones válidas.”​

Implementación corregida: La corrección garantiza que las comprobaciones de rollback ocurran antes de almacenar en caché el nuevo timestamp y añade una validación más estricta del contenido del timestamp. En Tough 0.20.0, la función load_timestamp() se modificó para garantizar que los metadatos del Timestamp estén bien formados y que su versión de snapshot no sea inferior a la versión de snapshot previamente confiable antes de concluir la actualización. Específicamente, el código ahora verifica: (a) que los metadatos del timestamp tengan exactamente una entrada (debe ser solo para snapshot.json), (b) que esa entrada exista y se analice, y (c) que la versión de snapshot en su interior sea >= a la versión de snapshot anterior. (ver aquí) Solo después de que estas validaciones pasen, el nuevo timestamp se considera confiable. La lógica crítica añadida se ilustra a continuación:```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 } ); }