El mantenedor de código abierto desconecta los paquetes npm colors y faker: ¿y ahora qué?

El 8 de enero de 2022, el mantenedor de código abierto del popular paquete npm colors publicó colors@1.4.1 y colors@1.4.44-liberty-2, versiones en las que introdujo intencionalmente un commit que agrega un bucle infinito al código fuente. El bucle infinito se activa y ejecuta inmediatamente al inicializar el código fuente del paquete, lo que provocaría una denegación de servicio (DoS) en cualquier servidor Node.js que lo use.

En resumen: Snyk emitió una alerta de vulnerabilidad de denegación de servicio para colors@1.4.1, a raíz de este código vulnerable. Te recomendamos enfáticamente volver a colors@1.4.0 y fijar las versiones de tus dependencias para evitar actualizaciones automáticas a la versión problemática. También te recomendamos migrar a otro paquete. Sigue leyendo para obtener más información sobre el alcance, el impacto y las medidas de mitigación recomendadas.

Acerca de colors

El paquete npm de código abierto colors recibe más de 20 millones de descargas a la semana y es un proyecto clave del ecosistema para los desarrolladores de JavaScript y Node.js, ya que impulsa un gran conjunto de proyectos. Los registros de GitHub muestran que el proyecto colors se usa en más de 4 millones de otros proyectos, y npmjs.org indica que 18,962 paquetes dependen de este paquete npm.

Estos son algunos de los proyectos que dependen de colors:

• El asistente de línea de comandos prompt (alrededor de 500,000 descargas semanales)

• Formato de tablas Unicode cli-table3 (alrededor de 7 millones de descargas semanales)

• El propio aws-cdk de AWS (alrededor de 2 millones de descargas semanales)

De hecho, la versión defectuosa colors@1.4.1 afecta a una gran cantidad de usuarios y no debe tomarse a la ligera. Según las estadísticas de la página del paquete en npmjs, esta versión se había descargado 95,397 veces al momento de escribir esta publicación:

El código que provoca el problema

El siguiente código problemático se incorporó a la biblioteca vulnerable colors:

1for (let i = 666; i < Infinity; i++;) {
2   if (i % 333) {
3       // console.log('testing'.zalgo.rainbow)
4   }
5   console.log('testing testing testing testing testing testing testing'.zalgo)
6}

Este código de bucle infinito, ubicado en el archivo index.js del código fuente del paquete, interrumpirá cualquier uso del paquete y, al mismo tiempo, imprimirá un texto zalgo muy inquietante en la terminal:

Dependo del paquete colors. ¿Qué debo hacer para mitigar el problema?

Si actualmente te afecta el incidente de colors por usar la versión defectuosa 1.4.1, te recomendamos volver a la última versión conocida como segura, colors@1.4.0, que no incluye el código problemático del bucle infinito. Por ejemplo, para fijar la versión estable y segura del paquete colors en tu archivo package.json, reemplaza lo siguiente:

1"colors":"^1.4.0"

por:

1"colors":"1.4.0"

Como referencia para el futuro, te recomendamos seguir estas prácticas recomendadas al administrar bibliotecas de código abierto en tus proyectos:

1. Fija tus dependencias en package.json o usa un archivo de bloqueo. Esto te ayudará a evitar que durante la instalación se resuelvan versiones más recientes, lo que podría haberte llevado a instalar la versión 1.4.1 de colors que introdujo el problema.

2. Este incidente debería llevarte a considerar cambiar a un paquete alternativo para el manejo de colores, como chalk.

3. Revisa el mantenimiento y la sostenibilidad de los paquetes de código abierto que planeas usar y asegúrate de que tengan un modelo de gobernanza adecuado, por ejemplo, con varios colaboradores.

Faker.js: ¿el mismo mantenedor, la misma historia?

Este evento ocurre después de un incidente similar relacionado con el popular paquete npm faker (conocido ampliamente como Faker.js), mantenido por la misma persona. Muchos desarrolladores usan Faker para generar grandes cantidades de datos ficticios, que suelen utilizarse en las pruebas de software.

Faker recibe 2 millones de descargas semanales y también es una dependencia bastante popular en proyectos de JavaScript y Node.js. Sin embargo, el 5 de enero de 2022, el repositorio de código abierto de este paquete en GitHub recibió un commit forzado que revirtió por completo el código fuente original del paquete:

La versión del paquete npm faker se actualizó a 6.6.6 y se publicó en el registro público de npmjs como un paquete vacío que no contiene código fuente.

El mantenedor creó un issue en el que afirmó que ya no mantendría el paquete de forma gratuita:

Más tarde, el autor eliminó el repositorio de GitHub donde se alojaba el proyecto, lo que probablemente causó una gran interrupción para los miles de desarrolladores que usaban este paquete y que ahora quizás estén buscando formas de migrar.

Más adelante, publicó un artículo sobre el tema en su blog personal, donde detalló los intentos fallidos de monetizar el proyecto o conseguir patrocinadores, y expresó que el estado actual de las donaciones no es sostenible: «Como la mayoría de nosotros, tengo personas que dependen de mí y cuentas que pagar».

Como el mismo mantenedor participa en alrededor de otros 170 paquetes npm, es muy posible que esta historia no termine aquí.

Los riesgos de los modelos de financiamiento y gobernanza del código abierto

Este evento forma parte de una tendencia general en la comunidad de código abierto sobre la responsabilidad de las empresas y organizaciones que dependen del código abierto en producción para crear sus productos.

Después de publicar el código problemático en colors, el mantenedor también abrió un issue en GitHub para hablar del tema. En él, bromeó sobre no poder encontrar la causa de este «error» y no tener tiempo para solucionarlo.

Marak sigue etiquetando a otros desarrolladores de Node.js muy prolíficos para que ayuden con el problema, pero ninguno tiene acceso real al repositorio del proyecto:

Estos incidentes se suman a una tendencia reciente de debate en la comunidad de código abierto, en la que cada vez más mantenedores expresan su descontento con las empresas y organizaciones que monetizan y usan software de código abierto en sus productos.

En respuesta a las críticas al código abierto después de Log4Shell, abordamos recientemente las dificultades que enfrentan los mantenedores para sostener un software de código abierto saludable sin financiamiento.

Es posible que sigamos viendo cómo los mantenedores bloquean por completo el acceso a sus paquetes. Aunque el sentimiento es totalmente comprensible y los argumentos son válidos, cabe señalar que bloquear el acceso a los paquetes de código abierto también perjudica a otros desarrolladores y mantenedores de código abierto.

Adopta prácticas recomendadas de seguridad para el código abierto

Usar software de código abierto significa que debemos evaluar adecuadamente los riesgos de este tipo de incidentes, así como otros problemas de seguridad y legales, y estar bien preparados para responder a medida que se desarrollan. Mejor aún, podemos adoptar prácticas recomendadas para evitar y mitigar posibles problemas de seguridad en la cadena de suministro.

Te recomendamos las siguientes prácticas y lecturas para que estés mejor preparado ante situaciones similares en el futuro:

1. Debes revisar el estado de mantenimiento y sostenibilidad de los proyectos de código abierto. Snyk Advisor es una herramienta que ayuda a evaluar el puntaje de estado de un paquete.

2. 10 prácticas recomendadas de seguridad para npm destaca la importancia de habilitar la autenticación de dos factores, fijar las dependencias mediante el uso adecuado de archivos de bloqueo y otras medidas.

3. Infórmate sobre cómo proteger tu cadena de suministro de software moderna frente a amenazas como la confusión de dependencias, el typosquatting y los paquetes maliciosos.

4. Consejos prácticos sobre cómo Snyk ayuda a prevenir paquetes maliciosos y ataques a la cadena de suministro