Quizá sea mejor no instalar software nuevo por un tiempo

• Después de copy.fail, se dieron a conocer vulnerabilidades adicionales del kernel de Linux
• Actualmente se considera que es un momento especialmente propicio para que un ataque a la cadena de suministro de NPM cause grandes daños
• Se recomienda hacer una excepción con los parches del kernel de Linux proporcionados por la distribución
• Fuera de eso, conviene suspender la instalación de software nuevo durante aproximadamente una semana
• Se añade la salvedad de que, desde la publicación, los hechos o la situación podrían haber cambiado, por lo que se pide contactar antes de sacar conclusiones si algo parece incorrecto o poco claro

[GN⁺]

Comentarios en Hacker News

• Esto era una pesadilla que tarde o temprano iba a explotar. Hay demasiados paquetes y, con eso, la superficie de ataque de la cadena de suministro se volvió tan enorme que en algún momento iba a estallarle a todo el mundo
  Pero era demasiado conveniente. A quienes intentaban advertir o reducir el daño los ignoraban personas que nunca habían probado otra forma de hacer las cosas, y "import antigravity" era demasiado fácil como para renunciar a eso
  Parece que ahora entramos en la etapa de “pagar el precio”

  • En una empresa sí operaban de forma realmente conservadora. Todos los componentes externos tenían versiones fijas, no se actualizaban sin revisión y por lo general pasaban por un período suficiente de estabilización
    Casi todo se compilaba desde el código fuente, incluidos el compilador, el kernel y demás; los servidores/infraestructura de build no tenían ningún acceso a internet, y también había un proceso para introducir cambios. Cada CVE se revisaba al publicarse para decidir si nos afectaba y cómo mitigarla o manejarla
    Después me cambié a una empresa donde los builds sí accedían a internet y actualizaban en cuanto salía una versión nueva. La gente lo veía como una buena práctica porque así recibían las correcciones de bugs más recientes, y la revisión de CVE la llevaba el equipo de seguridad
    Luego estuve en una startup donde había una mezcla de prácticas. Había cosas muy buenas, pero también mucha deuda de CVE. Por ejemplo, usaban secure boot y discos cifrados en los servidores, y también tenían bastante claro el tema de asegurar las comunicaciones entre componentes
    Todos creen que lo están haciendo bien. Es casi imposible convencer a la gente de “actualizar frecuentemente” de que existe el riesgo de introducir problemas nuevos. La industria necesita un mejor conjunto de prácticas, y personalmente creo que la forma de gestionar dependencias de la primera empresa era mejor. En general, las prácticas de seguridad estaban bien establecidas y el producto era realmente seguro
  • Abriendo la caja de Pandora, me pregunto si el efecto neto de sacar a la luz todos estos vectores de ataque desconocidos podría ser vaciar el stock de vulnerabilidades reservadas por las agencias de inteligencia del mundo
    Que todo el software útil termine pasando por fuzzing, pruebas basadas en propiedades y verificación formal, y que cualquiera que busque vulnerabilidades tenga que volver a empezar desde cero
    Claro, eso asumiendo que sobrevivamos el período intermedio en el que cada país lanza lo que le queda contra sus peores enemigos. O quizá al final terminemos golpeándonos con huesos de animales
  • Llevo años queriendo un modelo de seguridad basado en capacidades, y ya lo he discutido aquí. Las capacidades serían algo como punteros a objetos con permisos asociados, parecido a los file descriptors de Unix
    A nivel de sistema operativo, el programa ejecutado recibiría tokens de capacidad desde el shell o desde donde se lo lanzó, y todas las system calls tendrían que recibir una capacidad como primer argumento. Entonces "open path /foo" se convierte en open(cap, "/foo"). Esa capacidad puede ser un filesystem falso, una rama del filesystem real, un filesystem de red o lo que sea, y el programa no necesita saber en qué sandbox vive
    También a nivel de librerías/lenguaje, al importar librerías de terceros como módulos de npm, habría que pasar capacidades en el momento del import o en cada punto de llamada. Esa librería no debería tener acceso de lectura/escritura a todos los bytes del espacio de direcciones de mi programa, ni poder hacer cualquier cosa en mi computadora como si fuera yo. La pregunta clave es: “¿cuál es el radio de explosión de este código?”. Si la librería que uso es maliciosa o vulnerable, necesito valores predeterminados razonables sobre la magnitud del daño. Una llamada como lib::add(1, 2) no debería terminar en un compromiso persistente de toda mi computadora
    SeL4 ofrece capacidades rápidas y eficientes a nivel de sistema operativo desde hace mucho tiempo, y funciona bien. En muchos casos es más rápido que Linux, y es muy útil para sandboxing transparente, drivers en espacio de usuario, comunicación entre procesos, mejoras de seguridad y demás. Incluso se puede ejecutar Linux como un proceso sobre SeL4. Quiero un sistema operativo que tenga toda la funcionalidad de un escritorio Linux, pero que se comporte como SeL4
    Lamentablemente, no parece existir un lenguaje de programación con capacidades a nivel de lenguaje en la forma que quiero. Rust está bastante cerca, pero hace falta una forma de impedir que crates de terceros puedan llamar cualquier código unsafe. Incluyendo unsafe invocado por dependencias no confiables. También hay que corregir viejos bugs de soundness en Rust, y hace falta una biblioteca estándar basada en capacidades. Cosas globales como open() / listen() deberían desaparecer, y solo deberían existir openat() y formas equivalentes para las demás partes del sistema operativo
    Si los LLM siguen mejorando, en unos años, si nadie lo hace antes, pienso pedirle a un LLM que construya todo esto. La seguridad de los sistemas operativos de escritorio modernos es un chiste
  • La mayoría de la gente, por defecto, no se mete cualquier cosa a la boca. No esperan a que un cultivo microbiológico salga positivo para recién entonces rechazar algo
    También necesitamos una cultura de higiene para el código, y no es tan distinta de las normas que la mayoría de las culturas desarrolló para la comida. Es una combinación de heurísticas imperfectas, pero esa sensación de “guácala” salva a miles de millones de personas
  • Hace un año planteé la idea de que, siempre que fuera posible, era mejor escribir el código uno mismo antes que traer terceros. En ese momento, incluso considerar que los LLM llenaran los huecos se veía casi como una herejía
    Ahora estoy reduciendo la exposición a dependencias más que nunca, sobre todo en cosas que se pueden implementar con unos pocos cientos de líneas. Esto sí que es un cambio de paradigma

• El enfoque de “espera una semana antes de instalar software” no funciona. Hace apenas unos meses una vulnerabilidad masiva golpeó la web, y fue un ataque diferido que estuvo latente más de un mes antes de ejecutarse
  Si todos empiezan a esperar una semana, los atacantes esperarán dos. Los ciberdelincuentes no necesitan explotar algo de inmediato; solo necesitan explotarlo eventualmente. Además, muchos tipos de vulnerabilidad, como el typosquatting, no cambian en nada con este enfoque

  • Parece que el autor no está diciendo que se retrasen todas las actualizaciones para siempre, sino proponiendo esperar una semana como medida única hasta que se publiquen correcciones y parches para ciertas vulnerabilidades que esta vez se revelaron demasiado pronto. En lo demás, estoy de acuerdo
  • Creo que entendiste mal el texto. La propuesta no es esperar una semana después de que salga un software para instalarlo. Lo que dice es: desde ahora y durante los próximos 7 días, simplemente no instales nada
    Porque es muy probable que todavía no haya parches para estas vulnerabilidades, y aunque ya existan, es muy probable que pronto se descubran otras aún peores
  • Entonces podrían esperar un mes o dos. El punto del período de espera no es impedir que se ejecute un exploit ya instalado, sino evitar la instalación de nuevos exploits
  • Los paquetes populares tienen más exposición. Cuando se publica un artefacto, todo el mundo puede verlo, y se puede esperar que alguien revise las diferencias entre versiones
    Pero si no hay ningún retraso, podrías comerte un exploit que todavía nadie ha visto
  • Todos los compromisos de dependencias que recuerdo de los “últimos meses” se detectaron en minutos, no en horas: litellm, axios, bitwarden CLI, la imagen Docker de Checkmarx, Pytorch lightning e intercom/intercom-php
    Además, el descubrimiento de esos compromisos no dependió en absoluto de si llegaron a explotarse de verdad. Por eso no entiendo lo de “si todos esperan una semana, los atacantes esperarán dos semanas”

• Como otra opción, puedes moverte a un sistema operativo como FreeBSD, que no aborda la seguridad con mentalidad YOLO
  Las correcciones de seguridad no se tiran así nomás al kernel de FreeBSD sin coordinación. Pasan por el equipo de seguridad de FreeBSD, y pocos minutos después de que el parche entra al árbol src, se distribuyen actualizaciones binarias mediante FreeBSD Update y pkgbase para 15.0-RELEASE
  Más o menos toma unos segundos que aparezca el mensaje en Slack de “empujé el parche”, 10 a 30 segundos subirlo, y hasta 1 minuto para la sincronización de mirrors

  • Soy un poco escéptico con eso. Hace unos años reporté una vulnerabilidad al equipo de seguridad de FreeBSD, y unas semanas después incluso envié seguimiento, pero no recibí respuesta
    Siendo justos, mi reporte era sobre algo que no era un componente central y tampoco era fácil de explotar, pero Debian, OpenBSD, SUSE y Gentoo lo parchearon todo dentro de una semana https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
    Dicho eso, tampoco estoy diciendo que se deba juzgar todo un sistema operativo por cómo manejó un solo reporte menor, porque todo lo demás que he visto apunta más bien a que FreeBSD sí toma bastante en serio los reportes de seguridad. Aunque la misma lógica también puede aplicarse a bugs del kernel de Linux. Ese tipo de mala gestión de parches también es bastante raro en Linux
  • Si te cambias a BSD por seguridad, ¿por qué FreeBSD? ¿No es OpenBSD el realmente súper seguro? Lo pregunto porque hace tiempo que no sigo esos proyectos
  • FreeBSD es bastante laxo en seguridad, especialmente en defaults y configuración
    Suele priorizar la usabilidad por encima de la seguridad. Aquí hay un ejemplo conocido: https://vez.mrsk.me/freebsd-defaults
    Agradezco el trabajo que aporta al proyecto, pero mientras existan esos malos valores por defecto, no puedo recomendarle a la gente que se cambie con la conciencia tranquila
  • FreeBSD ni siquiera tenía ASLR en espacio de usuario hasta 2019, y todavía no tiene kASLR, otra de las mitigaciones. Para alguien que prioriza la seguridad, no es un sistema operativo serio
    Si quieres FreeBSD y seguridad, mejor usa HardenedBSD de Shawn Webb
  • En estas discusiones siempre aparece alguien. Qué bueno que su distribución favorita sea definitivamente más segura. Aunque reduzca los exploits por un factor de un dígito, igual quedarán unos cuantos miles. Ozymandias habría usado Gentoo

• Incluso los expertos en seguridad ya tienen que aceptar que nuestro mundo está sostenido sobre un equilibrio enormemente frágil. Creo que la gente realmente subestima esto
  Y no solo el mundo de TI, sino el mundo entero está construido sobre montones de equilibrios muy frágiles. Los exploits de seguridad siempre van a existir. No solo en software, también en la vida real. Alguien logró colarse en una conferencia de seguridad, y ni siquiera fue un actor sofisticado, sino un youtuber. Claro, no era un evento de máxima seguridad, pero es el ejemplo que se me viene a la mente. Básicamente, en la mayoría de los casos, saltarse la seguridad es realmente fácil
  Lo que quiero decir es que, en el fondo, nuestro mundo funciona porque la mayoría de la gente, al menos la mayor parte del tiempo, no abusa de ello. La sociedad humana siempre ha funcionado así, y probablemente seguirá funcionando así

  • Recuerdo que entre influencers del Reino Unido hubo una moda de entrar a lugares con la táctica de “la escalera y el chaleco fluorescente” para mostrar lo floja que es la seguridad física https://www.youtube.com/watch?v=LTI0SeyhAPA
    Según entiendo, un youtuber llamado Max Fosh logró entrar repetidamente a la International Security Expo. En el Reino Unido usó el alias “Rob Banks” en https://www.youtube.com/watch?v=qM3imMiERdU y en Estados Unidos “Nick Everything” en https://www.youtube.com/watch?v=NmgLwxK8TvA
    He estudiado un poco la cultura de la seguridad, y casi siempre termina siendo una escala deslizante entre seguridad de un lado y conveniencia/accesibilidad del otro. Cuanto más seguro, menos accesible; y al revés también

• Ya hay una solución bastante buena para los ataques a la cadena de suministro en gestores de dependencias como npm, PyPI y Cargo: configurar que solo se instalen versiones de paquetes con algunos días de antigüedad
  Todos los ataques grandes recientes se detectaron y revirtieron en menos de un día, así que con eso se habrían evitado sin problema. Este comportamiento debería ser el predeterminado. Puedes dejar que beta testers voluntarios y empresas de escaneo de seguridad prueben primero por un día las versiones más recientes de los paquetes. La idea está aquí: https://cooldowns.dev/

  • Una herramienta como esta, que apareció en Show HN hace 3 meses, me parece más adecuada: https://github.com/artifact-keeper
    Es un gestor de artefactos. Te permite traer solo lo que aprobaste. Puedes actualizar rápido cuando lo necesites, y usar versiones estables validadas de forma consistente cuando haga falta. Requiere un poco de override de configuración, pero es algo fácil
    Yo mismo hice una herramienta improvisada para un objetivo parecido, y este es un buen proyecto
  • Una forma mejor es que la empresa use solo repositorios validados internamente, y que nadie pueda instalar directamente desde repositorios de internet
    Claro, fuera del entorno corporativo eso naturalmente no funciona tan bien
  • ¿Pero eso no hace que también recibas tarde las actualizaciones de seguridad? Muchas vulnerabilidades existen en producción durante años antes de ser descubiertas y parchadas
    Una vez descubiertas, explotan de inmediato, y retrasar las actualizaciones les da más tiempo a atacantes entusiasmados
  • Personalmente, creo que el enfoque más sostenible es el modelo de distribuciones Linux/BSD ports/Homebrew: no subir una librería nueva directamente a un registro público, sino escribir un script de empaquetado que se revise con cada cambio nuevo
    Otro modelo es CPAN de Perl, que distribuye solo archivos fuente

• Quienes adoptaron integración continua y builds en contenedores relativamente hace poco deberían revisar si su sistema no está trayendo latest de varios paquetes en cada build
  Nosotros armamos un contenedor base con todas las dependencias externas incluidas, y solo lo actualizamos explícitamente cuando decidimos que ya es momento
  Así que quizá vayamos un poco detrás de la punta de lanza, pero asumimos mucho menos riesgo de que una vulnerabilidad de la cadena de suministro aleatoria se despliegue de inmediato por todo el mundo

  • También van a descubrir que así bajan muchísimo los tiempos de build de CI y los fallos inestables
  • Además, conviene usar solo repositorios internos

• Es un texto de opinión activamente dañino. Cuesta entender la lógica
  Toma 45 segundos verificar desde cuándo existen realmente las vulnerabilidades copyfail y dirtyfrag. Es más tiempo del que toma leer el texto, sí. Dirtyfrag podría afectar incluso a sistemas que se remontan a 2017
  Lo afectado no es software “nuevo”. Y el software realmente viejo está todavía peor, porque ha tenido mucho más tiempo para que le encuentren problemas

  • El post original propone que, como sería malo que ocurra ahora un ataque a la cadena de suministro, no instales ni actualices paquetes de NPM para reducir ese riesgo

• Algún día alguien va a reconstruir toda la pila, desde el sistema operativo hasta las aplicaciones, con upgrades de proof-carrying code
  La única forma de ejecutar código confiable es mediante el codiseño y la coconstrucción de la prueba y el código

• Esto no aplica solo al software; en realidad aplica a casi todo
  No recuerdo dónde lo leí, pero al final se reduce a la diferencia entre necesidad y deseo
  He usado esta regla al decidir si comprar un auto nuevo o usado, una aspiradora premium o una básica. Lo mismo con traer un aparato nuevo y brillante, algo nuevo al stack tecnológico, o elegir un stack tecnológico nuevo

• Me gustaría ayuda para entender qué es copyfail y cómo se conecta con los paquetes de NPM
  Por lo que logré ordenar, copyfail parece ser un bug del kernel que permite que un paquete npm malicioso obtenga privilegios de root en un servidor Linux
  Entonces, como todavía hay servidores sin parchear, este sería el momento perfecto para que atacantes apunten a paquetes de NPM
  ¿La razón por la que el consejo no es simplemente “actualiza el kernel” es que siguen descubriéndose problemas nuevos relacionados?

  • Los parches para las vulnerabilidades más recientes ni siquiera han salido todavía. Por eso, si ocurre ahora un nuevo ataque a la cadena de suministro, sería un momento realmente malo porque podría obtener root en casi cualquier sistema
  • Los ataques a la cadena de suministro en NPM se propagan realmente rápido
    Si un paquete popular de NPM fuera comprometido e incluyera un exploit de copy.fail, muchos sistemas quedarían vulnerables a una escalada de privilegios a root
  • La razón por la que el consejo no es “actualiza el kernel” es que no hay actualización. La vulnerabilidad más reciente descubierta después de copy.fail todavía no tiene corrección