XZ Utils: el backdoor sigue vivo en imágenes de Docker

TL;DR

• Hubo builds de imágenes Debian en Docker Hub (marzo 2024) que incluyen la biblioteca liblzma.so con backdoor de XZ Utils.
• Esas imágenes quedaron públicas y otras se construyeron encima, heredando el problema (segundo orden).
• Si tu pipeline o tus runners usan imágenes históricas por digest o tag viejo, podrías seguir arrastrando el riesgo.
• Acción inmediata: identificar bases afectadas, reconstruir con base images limpias y agregar controles binarios (no solo por versión). Al final hay guía y checklist.

Contexto técnico rápido

El caso XZ Utils (marzo de 2024) introdujo un implante en liblzma.so que podía activarse al interactuar con OpenSSH (sshd), mediante una cadena de hooks que apuntaba a RSA_public_decrypt, RSA_get0_key y EVP_PKEY_set1_RSA, disparada por resolutores IFUNC modificados para lzma_crc32/lzma_crc64. El impacto trascendió lo teórico porque paquetes distribuidos por distros (p. ej. Debian/Fedora/openSUSE) llegaron a canales oficiales.

Lo que se encontró en Docker Hub

Se identificaron imágenes Debian de marzo de 2024 con el backdoor, aún disponibles públicamente. Además, imágenes de segundo orden (construidas sobre esas bases) heredan el problema. La muestra es acotada (foco en Debian y hasta segundo orden), por lo que la cifra real puede ser mayor y no se cubren aquí Fedora/openSUSE ni terceros que hayan cacheado artefactos.

Nota: La siguiente información resume el artículo técnico enlazado en Fuente (al final). La enumeración no es exhaustiva y puede cambiar con el tiempo.

Tabla 1 — Imágenes Debian con backdoor (arquitectura amd64)

Tabla 2 — Imágenes de segundo orden basadas en las anteriores

Según la nota original, se contactó a desarrolladores para reportar la situación y la respuesta fue que las imágenes históricas se conservan y se recomienda usar versiones nuevas. Aun así, dejar imágenes comprometidas accesibles públicamente aumenta la superficie de ataque, especialmente si alguien las usa sin revisar.

Qué deberías hacer (infra, contenedores y hosts)

1) Identificar base images afectadas

• Pin por digest (no solo tag) y auditar historiales:

  docker inspect <img> --format '' | jq .
  docker history --no-trunc <img>
  

  Si usás digests antiguos (marzo 2024 en Debian sid/testing/trixie), consideralos sospechosos.

2) Escanear imágenes y binarios

Generá un tar de la imagen y buscá liblzma.so:

img=<namespace>/<name>:<tag>
docker save "$img" | tar -t | grep -E 'liblzma\.so(\.|$)'

Si tenés el layer desempaquetado, inspeccioná IFUNC inusuales:

readelf -sW /path/a/liblzma.so | grep IFUNC
strings /path/a/liblzma.so | grep -E 'lzma_crc(32|64)'

Corré un verificador dedicado (ej.: XZ.fail): https://xz.fail/

3) Rebuild y policy de base images

Reconstruí todas las imágenes que dependan de bases listadas arriba.

Bloqueá en tu registry corporativo tags/digests vetados (cuarentena).

En CI/CD: política de freshness (expirar base images viejas), SBOM (Syft/otros), scaneo binario y diff de capas entre builds.

4) Hosts expuestos (si usaron esos paquetes)

Verificá versión de xz-utils y binarios en /usr/lib/liblzma.so.

Si el host o contenedor corre sshd, priorizá su revisión. Aún con impacto práctico acotado, el riesgo existe.

Conclusión

El incidente de XZ Utils muestra que artefactos comprometidos pueden persistir en registries públicos, propagarse por herencia y colarse en pipelines automatizados si no hay controles binarios. No alcanza con “estar en la versión correcta”: hay que mirar el binario y dominar la cadena de suministro (bases, capas, digests, runners, caches).

Fuente

Artículo original: Persistent Risk: XZ Utils Backdoor Still Lurking in Docker Images — https://www.binarly.io/blog/persistent-risk-xz-utils-backdoor-still-lurking-in-docker-images

Herramienta útil

Chequeo de backdoor (gratuito): https://xz.fail/