Compromiso de XZ Utils (CVE-2024-3094)

CVE-2024-3094 afectó tarballs XZ Utils 5.6.0/5.6.1. La exposición dependía del build de la distro; identifica y sustituye los paquetes afectados.^{[1], [3], [4], [5], [6]}

Vector CVSS

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H^[9]

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina una fábrica que recibe un kit de piezas sellado y monta un producto. La receta pública parece normal, pero un kit enviado contiene un componente extra oculto. Una fábrica que crea el kit desde la receta no recibe ese componente; una que usa el kit sellado podría recibirlo. Un manifiesto autenticado por un canal independiente puede detectar un kit sustituido, pero ni una firma válida del proveedor demuestra que un kit autorizado sea inocuo: los kits comprometidos de XZ eran lanzamientos oficiales. Sustituye los paquetes afectados según las indicaciones de tu distribución; usa la verificación del manifiesto solo como control separado contra sustituciones.^{[5], [6]}

Conceptos Clave y Términos

Tarball de lanzamiento: Archivo distribuido para una versión de software. Es una entrada de compilación y debe verificarse de forma independiente del código fuente del repositorio que debería representar.^{[3], [4], [6]}
Procedencia de compilación: Evidencia que conecta un artefacto compilado con código revisado, un proceso de compilación definido y una identidad de lanzamiento fiable. La procedencia hace detectable una diferencia entre fuente y artefacto.^{[5], [6]}
Verificación de artefactos: Comprobación de un artefacto de lanzamiento frente a un manifiesto firmado fiable o un digest reproducido de forma independiente antes de permitirlo en una compilación o canal de paquetes.

Mapeos de marcos

Referencia CWE para la debilidad descrita en esta guía: CWE-506

Cronología del Incidente

24 de febrero de 2024

Se publicó XZ Utils 5.6.0; la declaración posterior del proyecto indica que su tarball de lanzamiento contenía una puerta trasera.^{[3], [6]}

9 de marzo de 2024

Se publicó XZ Utils 5.6.1; la misma declaración indica que su tarball de lanzamiento contenía una puerta trasera.^{[4], [6]}

Antes del 29 de marzo de 2024

Freund informó de un script de compilación inyectado en tarballs distribuidos, ausente del archivo fuente upstream correspondiente, después de que uso inusual de CPU por SSH y errores de Valgrind motivaran la investigación.^{[5], [6]}

29 de marzo de 2024

Andres Freund informó públicamente del problema.^[5]

Flujo de Ataque Paso a Paso

Paso 1

Un artefacto de lanzamiento difería de la fuente esperada

Andres Freund informó de un script de compilación inyectado en tarballs distribuidos que no existía en el archivo fuente upstream correspondiente. Es un fallo de procedencia: revisar una entrada no probaba la identidad de la otra.^{[5], [6]}

Paso 2

Las condiciones de compilación y distribución importaban

Los informes describen datos extraídos de archivos de prueba .xz durante la compilación de los tarballs afectados. Freund también indicó que una compilación desde Git no inyectaría el código y que la ruta de dependencia dependía de las decisiones de compilación de la distribución.^{[5], [6]}

Paso 3

Un comportamiento anómalo desencadenó la investigación

Freund informó de uso inusualmente alto de CPU por SSH y errores de Valgrind. Esos síntomas llevaron a investigar el artefacto de lanzamiento y su comportamiento de compilación, en vez de aceptar una regresión de rendimiento sin explicación.^[5]

Paso 4

La contención comienza con reemplazo y verificación de paquetes

Trata el caso como un incidente de paquetes afectados y procedencia de compilación. Sigue las indicaciones de tu distribución y sustituye los paquetes afectados. Para futuros artefactos, verifica procedencia y firmas: esto puede detectar sustituciones, pero no demostrar que un lanzamiento autorizado sea inocuo.^{[1], [6]}

Código Fuente: Vulnerable vs. Seguro

IMPLEMENTACIÓN VULNERABLE

# Acepta una entrada de compilación descargada sin demostrar su identidad.
from pathlib import Path

def stage_release(artifact: Path, build_inputs: Path) -> None:
    build_inputs.joinpath(artifact.name).write_bytes(artifact.read_bytes())

# Una copia correcta no prueba que este archivo corresponda
# al lanzamiento revisado o a un manifiesto fiable del editor.

PARCHE SEGURO Y ROBUSTO

# Puerta ilustrativa: verifica un SHA-256 esperado de un manifiesto fiable.
import hashlib
import hmac
from pathlib import Path

def verify_release(artifact: Path, expected_sha256: str) -> None:
    digest = hashlib.sha256(artifact.read_bytes()).hexdigest()
    if not hmac.compare_digest(digest, expected_sha256.lower()):
        raise ValueError("el artefacto de lanzamiento no coincide con el manifiesto fiable")

# Obtén expected_sha256 mediante un proceso de lanzamiento autenticado aparte
# y llama a verify_release antes de que el archivo entre en la compilación.

# Esto detecta sustituciones, no un lanzamiento autorizado pero malicioso; sigue las indicaciones para los paquetes afectados.

Lista de Verificación de Seguridad para Ingeniería

✓Sigue las indicaciones de tu distribución para CVE-2024-3094, identifica y sustituye los paquetes y versiones realmente afectados, y después verifica la procedencia del paquete sustituto.^{[1], [6]}
✓Antes de usar un archivo de lanzamiento como entrada de compilación, compáralo con un hash o una firma obtenidos por un canal autenticado por separado; falla de forma segura si no coinciden, porque una descarga correcta no demuestra su procedencia.
✓Para compilaciones reproducibles, registra la revisión del código fuente, el entorno de compilación, el digest del artefacto, la identidad del constructor y la configuración; compara compilaciones independientes al actualizar dependencias críticas.
✓Revisa archivos de lanzamiento, scripts de compilación, reglas de empaquetado y artefactos de prueba con el mismo rigor que el código de la aplicación; registra el origen y la integridad de los datos binarios de prueba sin explicación.^{[5], [6]}
✓Exige la aprobación de al menos dos mantenedores para cambios en herramientas de lanzamiento, configuración de CI y pasos de empaquetado, separada de la aprobación del código ordinario de la aplicación; conserva registros trazables.
✓Investiga el uso inexplicado de CPU en compilaciones o servicios, las regresiones de rendimiento y los errores de memoria o de herramientas de validación; conserva artefactos y pruebas para compararlos.^[5]