Ubuntu corrige falla en less: riesgo de ejecución de comandos

Bajada: Canonical publicó USN-8079-1 para corregir una vulnerabilidad en less que puede terminar en ejecución de comandos al procesar nombres de archivos maliciosos. Aunque afecta específicamente a Ubuntu 14.04 ESM, el caso vuelve a poner foco en un riesgo clásico: procesar artefactos no confiables en herramientas de consola ampliamente usadas por equipos de infraestructura.

Introducción

less es una utilidad simple, pero estratégica en la operación diaria: se usa para revisar logs, inspeccionar salidas de comandos y abrir archivos de configuración en servidores Linux. Por eso, cuando aparece una vulnerabilidad que combina manejo inseguro de nombres de archivo con posible ejecución de comandos, el impacto supera al paquete puntual: toca prácticas operativas comunes en SysAdmin, SRE y DevOps.

El aviso USN-8079-1 de Ubuntu (5 de marzo de 2026) corrige una falla en less y describe un escenario de denegación de servicio o ejecución arbitraria de comandos ante entradas especialmente diseñadas. El problema no es nuevo en la industria (CVE-2024-32487 ya había documentado un patrón similar), pero sí es relevante porque vuelve a aparecer en superficies donde muchos equipos todavía confían en “herramientas de texto inofensivas”.

Qué ocurrió

Ubuntu publicó el aviso USN-8079-1 indicando que less “podría colgarse o ejecutar comandos arbitrarios” al recibir input manipulado. El detalle técnico de Canonical apunta a un manejo incorrecto de ciertos nombres de archivo.

Según el propio aviso, la corrección aplica a:

• Ubuntu 14.04 LTS (Trusty, rama ESM)
• paquete less versión 458-2ubuntu0.1~esm2

En paralelo, la documentación de Debian Security Tracker para less mantiene referenciada la familia de CVEs previa, incluyendo CVE-2024-32487, que describe ejecución de comandos por mal manejo de quoting ante nombres de archivo con salto de línea.

La lectura práctica es clara: incluso en herramientas de línea de comandos muy consolidadas, la interacción entre parsing de argumentos, quoting y variables de entorno puede abrir vectores explotables cuando se procesan archivos no confiables.

Impacto para SysAdmin / DevOps

Para equipos de operación, el impacto no está solo en “un paquete viejo vulnerable”, sino en cómo se manipulan artefactos externos dentro de flujos reales:

1. Investigación de incidentes: descargar un bundle de evidencia y abrir archivos rápidamente con less.
2. Pipelines y jobs de soporte: scripts que inspeccionan archivos temporales generados por terceros.
3. Bastiones y jump hosts: uso intensivo de utilidades POSIX por múltiples operadores.
4. Entornos legacy: sistemas en soporte extendido (ESM/LTS prolongado) donde la ventana de exposición suele ser mayor.

Si un atacante controla nombres de archivos dentro de un tar/zip o directorio compartido, puede provocar condiciones inesperadas en etapas de análisis manual o semiautomático. En operaciones de alta presión (respuesta a incidentes, troubleshooting nocturno), ese tipo de vector tiene probabilidad real de materializarse por error humano.

Detalles técnicos

El patrón técnico asociado (según NVD para CVE-2024-32487 y referencias de upstream/debian) involucra:

• manejo deficiente de quoting/escape en filename.c;
• nombres de archivo con caracteres especiales (incluyendo newline);
• posibilidad de que se invoquen comandos del sistema en contextos no previstos;
• mayor riesgo cuando existen integraciones con LESSOPEN o wrappers que preprocesan contenido.

Aunque la severidad final depende del contexto (versión concreta, variables de entorno, forma de invocación), hay tres factores que aumentan exposición:

• automatización opaca: scripts heredados que llaman less indirectamente;
• confianza en fuentes externas: archivos provenientes de tickets, adjuntos o repos no verificados;
• falta de hardening del entorno shell: variables de entorno globales sin control.

Además, el sitio oficial de less muestra una cadencia activa de releases (actualmente 692), lo que confirma que el proyecto sigue corrigiendo bugs y que permanecer en ramas antiguas incrementa riesgo operativo.

Qué deberían hacer los administradores

1) Aplicar actualización donde corresponda

• En Ubuntu afectado por USN-8079-1, actualizar less a la versión recomendada por Canonical.
• Verificar con inventario real qué hosts siguen en 14.04 ESM o ramas equivalentes con deuda técnica.

2) Revisar exposición en flujos de trabajo

• Identificar scripts internos que invocan less, especialmente en jobs de soporte y diagnóstico.
• Revisar tooling que procese archivos provenientes de terceros sin sanitización previa.

3) Reducir riesgo por configuración

• Auditar uso de LESSOPEN y helpers asociados.
• Limitar herencia de variables de entorno en cuentas de automatización.
• Ejecutar análisis de archivos no confiables en hosts aislados o contenedores efímeros.

4) Endurecer prácticas de triage

• Evitar inspección directa de artefactos externos en bastiones críticos.
• Normalizar pipelines de “descompresión + renombrado seguro + validación” antes de abrir archivos manualmente.
• Registrar y versionar playbooks de respuesta para que el hardening no dependa del operador de turno.

5) Incluir estas utilidades en patch management

Muchas organizaciones priorizan kernel, OpenSSL, OpenSSH o runtime de contenedores, pero dejan fuera utilidades de consola. Este caso demuestra que herramientas pequeñas también deben entrar en:

• matriz de criticidad,
• reportes de cumplimiento,
• y ventanas periódicas de actualización.

Conclusión

USN-8079-1 no representa un “evento masivo” por sí solo, pero sí una alerta útil para infraestructura: la superficie de ataque incluye herramientas cotidianas que se ejecutan en contexto privilegiado y bajo presión operativa. Para equipos SysAdmin y DevOps, la lección es combinar parcheo con disciplina en manejo de artefactos no confiables y revisión de automatizaciones heredadas.

Si ya existe un programa de patch management maduro, esta clase de avisos debería convertirse en una verificación rápida y rutinaria. Si no existe, es un buen punto de partida para cerrar una brecha común: la de los componentes “pequeños” que nadie mira hasta que aparece el incidente.

Fuentes

• https://ubuntu.com/security/notices/USN-8079-1
• https://security-tracker.debian.org/tracker/source-package/less
• https://nvd.nist.gov/vuln/detail/CVE-2024-32487