"No hay forma de evitarlo": así habla el único gestor de paquetes donde estas cosas pasan con regularidad

 (kevinpatel.xyz)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Un ataque a la cadena de suministro del registro de npm expuso millones de aplicaciones empresariales y miles de millones de registros de usuarios, pero el ecosistema lo asume como si fuera algo inevitable
  • El Senior Frontend Engineer Mark Vance critica la realidad de depender de 40 niveles de dependencias anidadas de paquetes no verificados incluso para convertir una cadena a mayúsculas
  • La toma de control de un paquete utilitario abandonado durante años, que termina inyectando un crypto-miner en builds de producción en todo el mundo, se trata como si fuera un desastre natural
  • El ecosistema de Node.js acepta la ejecución remota de código maliciosa como una tragedia impredecible, mientras los equipos de DevOps se dedican a rotar claves de AWS
  • Los ecosistemas de Go, Rust y las Web API nativas sirven de contraste al reducir la dependencia de terceros con una biblioteca estándar sólida y verificación criptográfica

Sátira sobre el ataque a la cadena de suministro en npm

  • Un ataque a la cadena de suministro del registro de npm comprometió millones de aplicaciones empresariales y expuso miles de millones de registros de usuarios, pero los desarrolladores del ecosistema JavaScript lo asumen como algo “completamente imposible de evitar”
  • El Senior Frontend Engineer Mark Vance ve como el costo del desarrollo moderno de aplicaciones web la realidad de depender de un árbol de 40 niveles de dependencias anidadas de paquetes no verificados para convertir una sola cadena a mayúsculas
  • La toma de control de un paquete utilitario abandonado durante mucho tiempo, que termina inyectando un crypto-miner en builds de producción en todo el mundo, se trata como si fuera un desastre natural
  • El ecosistema de Node.js acepta la ejecución remota de código maliciosa como una tragedia impredecible y envía “pensamientos y oraciones” a los equipos de DevOps ocupados rotando claves de AWS

El contraste entre otros ecosistemas y npm

  • Los ecosistemas de Go, Rust y las Web API nativas reducen de forma importante la dependencia de código de terceros gracias a una biblioteca estándar sólida e incluyen verificación criptográfica estricta en su toolchain principal
  • En esos ecosistemas, el contraste se plantea como que hoy hubo 0 casos en los que “un proyecto de fin de semana de un desertor universitario” arruinó la infraestructura logística global
  • Un vocero de npm remarca que, en un mundo donde existen actores maliciosos, esto simplemente debe aceptarse y que no hay políticas del registro ni guardrails de sandboxing de builds que puedan impedirlo
  • Se retrata al registro de npm como un registro open source que ejecuta por defecto scripts de instalación arbitrarios en la máquina local, alineando las declaraciones del vocero con el riesgo estructural
  • Al final, aunque expresa consuelo a las víctimas, cierra con la idea de que hay que mantener la resiliencia hasta “la próxima violación inevitable” de mañana por la mañana

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Comentarios en Hacker News

  • Cada quien tendrá su opinión sobre los períodos de enfriamiento, pero muchos de los ataques recientes a la cadena de suministro de npm, incluidos axios y tanstack, probablemente se habrían evitado con uno
    Si usas Artifactory / Nexus, es muy probable que ya tengas un período de enfriamiento, y si no, es fácil configurarlo
    Como la mayoría de las intrusiones en npm o PyPI se bajaron en cuestión de horas, la idea del período de enfriamiento es “ignorar paquetes publicados hace menos de N días”. Incluso 1 día ayuda, 3 días está bien y 7 días es un poco excesivo, pero funciona
    Para configurarlo, puedes usar la versión reciente de pnpm, que ya incluye por defecto un período de enfriamiento de 1 día, o https://pnpm.io/supply-chain-security; si quieres arreglarlo de una sola vez, puedes usar https://depsguard.com, que añade períodos de enfriamiento y configuraciones recomendadas a npm, pnpm, yarn, bun, uv y dependabot. Yo soy el mantenedor
    O también está https://cooldowns.dev, más enfocado específicamente en períodos de enfriamiento, con scripts para ayudarte a configurar lo local. Todo es open source o gratis
    Si sabes editar directamente ~/.npmrc y similares, realmente no hace falta, pero para gente cercana a ti que necesite una solución de un clic, probablemente les ayude a evitar el próximo ataque
    Eso sí, si necesitas parchear un CVE crítico nuevo, tendrás que saltarte el período de enfriamiento, y cada herramienta tiene su forma de hacerlo. No tengo cifras exactas, pero en las últimas semanas parece que el riesgo más grande ha venido de ataques a la cadena de suministro de software más que de CVE de día cero nuevos

    • Hasta me parece raro decir que 7 días es excesivo. Si no necesitas una funcionalidad nueva en particular, incluso al arrancar un proyecto nuevo normalmente debería bastar con versiones de dependencias publicadas hace meses
      Lo mismo aplica para actualizaciones periódicas de dependencias. Claro, a veces hay que subir de versión de inmediato, por ejemplo para responder a una vulnerabilidad, pero en ese caso me parece bien que el desarrollador tenga que indicar explícitamente la nueva versión que quiere
    • Entonces, ¿no sería que el problema solo se retrasa 7 días? Yo pensaba que estos incidentes terminaban cuando alguien resultaba infectado y se daba cuenta, no porque exista un ejército auditando cambios y detectándolos
      Si todo el mundo pone un período de enfriamiento de 7 días, ¿no explotaría simplemente más tarde?
    • Parece que falta una frase:

      Disclaimer: I maintain depsguard

    • No estoy seguro de que el período de enfriamiento sea tan efectivo. Alguien tiene que saltárselo, instalar una versión potencialmente problemática y descubrir el problema. Si nadie lo hace, solo retrasaste el problema 3/7/10/14 días
      Pensándolo mejor mientras escribo, igual sí estoy de acuerdo con un período de enfriamiento de 10 días para no instalar nada publicado en los últimos 10 días. Solo que no creo que deba esperarse que sea la única mitigación
    • ¿No podrían hacer distribuciones o canales separados, tipo latest/stable/LTS, como hacen las distribuciones de Linux?

  • Me pregunto qué garantizan realmente Go o Rust frente a Python/npm. También puede ser que Python/npm simplemente sean un blanco más atractivo
    Cada vez intento evitar más todos los paquetes de terceros

    • La forma en que se asigna la propiedad de paquetes y espacios de nombres depende 100% del operador del gestor de paquetes
      Maven Central existe desde hace décadas, pero los incidentes de robo de espacios de nombres han sido muy pocos
      No puedes subir un paquete con el groupId "com.ycombinator" sin verificar que eres dueño del dominio ycombinator.com. Y una vez publicado, el paquete es 100% inmutable, incluso si contiene malware. Claro, esas librerías quedan marcadas por todos lados como vulnerables
      No entiendo cómo NPM no logró copiar desde hace tanto estas protecciones tipo Maven Central
    • Uno de los puntos centrales del artículo es que la mayoría de los otros lenguajes populares tienen una biblioteca estándar bastante completa. La biblioteca estándar de JS es sorprendentemente pequeña
      En vez de tener un conjunto de librerías confiables distribuidas junto con el lenguaje, las aplicaciones tienen que construirlas ellas mismas o traerlas de un repositorio de paquetes de terceros. Como nos han enseñado constantemente a evitar el NIH, la gente termina tomando paquetes
      Eso no es necesariamente malo por sí mismo, pero muchas veces termina arrastrando mucho más código del necesario. El ecosistema de JS además favorece módulos pequeños, así que hacen falta muchos, y todos vuelven a apilar cosas encima, haciendo gigantesco el grafo de dependencias. Sea intencional o no, la superficie para que algo salga mal es enorme
      Otros lenguajes traen mucho más de serie. No es que no hayan tenido bugs o problemas de seguridad, pero comparado con lo que se ve en el ecosistema de JS, es poquísimo. El grafo de dependencias externas es mucho menor y la funcionalidad central viene de terceros de confianza
    • Los atacantes van donde están las víctimas. El frontend es casi una monocultura donde la gran mayoría usa NPM; el backend lo es bastante menos
      Eso no excusa a NPM; de hecho, solo suma otro factor en su contra
      También podría decirse que estos ataques muestran aún más la diferencia entre desarrolladores frontend y backend, pero no voy a llegar tan lejos
    • Sinceramente, Rust tiene exactamente el mismo patrón de ataque a la cadena de suministro. Solo que es más nuevo y por ahora está mejor administrado. Solo hay que esperar 10 años
    • La última vez que revisé, npm tenía autenticación de dos factores para publicar, pero cargo no. No creo que cargo sea especialmente mejor que npm; simplemente no es un blanco tan atractivo

  • En varios trabajos me tocó sufrir bastante instalando una configuración global segura de npm en todas las máquinas de desarrollo, pidiéndole a la gente que no la desactivara y verificándolo con herramientas MDM
    Una configuración predeterminada más segura debió existir desde hace mucho

    • La solución es no usar npm. Usa un gestor de paquetes que no ejecute postinstall por defecto, y el cambio es increíblemente sencillo
    • Me pregunto qué significa exactamente configuración segura. Si quieres forzar períodos de enfriamiento o listas de paquetes permitidos/bloqueados, el enfoque correcto es configurar un repositorio controlado por la empresa que traiga desde el repositorio upstream de npm pero aplique las políticas que tú quieras

  • No hay una razón legítima para que existan scripts de postinstall. El equipo de npm ya debería estar lo bastante maduro como para declarar: “a partir de cierta versión de npm, los scripts de postinstall solo se ejecutarán para versiones de paquetes publicadas antes de ${today}”

    • He auditado varios scripts de postinstall de paquetes populares recientemente. La mayoría usan o descargan binarios nativos, detectan compatibilidad de plataforma, hacen el enlace ellos mismos en vez de dejar que Node haga el bootstrap y esquivan problemas de versiones viejas de npm
      Esto pasa porque cadenas de herramientas de desarrollo como esbuild están hechas en lenguajes compilados y se distribuyen como binarios a través del repositorio de npm. Si usas una versión reciente de Node/npm y un OS/plataforma modernos y comunes, deberías poder desactivar todos los scripts de postinstall sin problemas legítimos
    • Los scripts de instalación, igual que las firmas de paquetes, son una distracción. Agregar o quitar cualquiera de esas funciones no cambia mucho la posibilidad de que este ecosistema se convierta en un gusano
      El código instalado desde npm casi sin excepción termina ejecutándose
    • El hecho de que los paquetes de Rust puedan ejecutarse sin sandbox durante la compilación tampoco tiene mucha justificación
    • Esto en realidad no arregla el problema. El código del paquete también se ejecuta durante la compilación y en las pruebas. Puede reducir un poco el alcance, pero hasta ahí
    • Dicho con cuidado, los scripts de postinstall son casi un tema señuelo. A la gente le sorprende que código controlado por otra persona pueda ejecutarse en su computadora y hacer cosas malas, y sí, puede pasar
      Pero lo mismo aplica al código normal dentro de ese paquete. Aunque no se ejecute al momento de instalarlo, tarde o temprano algo de ahí va a correr. Si no, ni siquiera habría terminado como dependencia
      Pensar que eliminar los scripts de postinstall va a tener un impacto más que momentáneo en la tasa de abuso es señal de que no se pensó el problema hasta el final. Por desgracia, esto es mucho más sutil de lo que da a entender el artículo original
      No es un problema tipo “no pongamos el botón que hace caer las alas junto al interruptor de la luz”, sino que el punto es que no hay forma, salvo con un trabajo manual muy pesado, de distinguir entre “código malo de otros ejecutándose en mi computadora”, que queremos evitar, y “código bueno de otros ejecutándose en mi computadora”, que sí queremos. Y justamente ejecutamos código de otros para evitar ese trabajo manual pesado

  • Todos los proyectos de Node.js empiezan con npm install, y de pronto aparecen 500 paquetes que ni querías. La mitad de ellos no se tocan desde hace años

  • Hay un problema cultural de querer actualizar a los paquetes más recientes todo lo que ya funciona bien. A veces ni siquiera leen el changelog para ver si el cambio aplica
    El período de enfriamiento es solo una forma de obligar a los mantenedores a tener un poco de paciencia, y sí funciona

    • Si tienes requisitos de cumplimiento, te obligan a actualizar por las vulnerabilidades CVE que caen sobre versiones viejas. La mayoría son casi falsas alarmas, tipo “ReDoS en regex”, pero igual tienes que actualizar para cumplir el proceso
    • Y también pasa que los dueños de paquetes actualizan cosas que no necesitan actualizarse para no parecer viejas y abandonadas
      Un paquete de Lisp puede usarse perfectamente durante 15 años sin cambios, pero si un paquete de JS no se mantiene se trata como si fuera una catástrofe. Aunque ya estuviera terminado hace 15 años, para seguir pareciendo “mantenido” en npm y GitHub terminan subiendo versiones sin agregar nada o, a veces, hasta metiendo cambios rompientes. Y entonces todo se actualiza

  • Un período de enfriamiento de 7 días se siente como una solución provisional barata de implementar. La solución real probablemente sean builds reproducibles y certificaciones firmadas, pero la mayoría de los equipos no va a pagar ese costo hasta después de haber sido víctima

  • Esto se lee como un artículo de The Onion

    residents of the Node.js ecosystem stood unified in their belief that the malicious remote-code execution was a completely unpredictable tragedy
    ¿De verdad hay alguien que se crea eso? Ha habido demasiados contraejemplos
    Es una buena sátira del fracaso del ecosistema, pero al final sigue siendo entretenimiento. Tal vez incluso sirva para que los marketers promocionen lo suyo. Como cuando el mantenedor de depsguard quitó ese dato de su propio post, luego lo volvió a poner y luego lo volvió a quitar. Al momento de escribir esto, ese post está arriba de todo

  • Este enlace es claramente una versión lavada con IA de un chiste que Xe Iaso lleva haciendo desde hace tiempo. Qué lástima
    https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
    https://news.ycombinator.com/item?id=40438408