Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon GitHub desactiva la ejecución automática de scripts en npm


GitHub cambiará los valores predeterminados de npm 12 para desactivar la ejecución automática de scripts durante la instalación, reduciendo así la superficie de ataque contra malware. También se restringirán las descargas desde URLs remotas y el uso de Git, requiriendo ahora una lista de permisos explícitos. Aunque mejora la seguridad, algunos expertos advierten que el código malicioso podría trasladarse al módulo mismo.




GitHub cambiará los valores predeterminados de npm para que el comando de instalación ya no ejecute scripts automáticamente, desactivando una función comúnmente explotada por paquetes maliciosos como el notorio gusano Shai-Hulud.

El mantenedor Leo Balter afirmó en GitHub: "Los scripts de ciclo de vida en el momento de la instalación son la superficie de ejecución de código más grande en el ecosistema npm. Cada npm install ejecuta scripts de cada dependencia transitiva, por lo que un solo paquete comprometido en cualquier lugar de su árbol puede ejecutar código arbitrario en la máquina de un desarrollador o en un ejecutor de CI (integración continua)".

En npm 12, previsto para julio, cambiarán tres valores predeterminados centrados en la seguridad. Los scripts configurados para preinstall, install o postinstall ya no se ejecutarán a menos que se permitan explícitamente a través de allow-scripts. El flag --allow-git, que extrae dependencias de URLs remotas, estará desactivado por defecto, cerrando una vía de ataque donde un archivo .npmrc malicioso podría anular el ejecutable de Git y lograr la ejecución de código arbitrario. Finalmente, allow-remote tendrá como valor predeterminado "none", bloqueando completamente las descargas de dependencias desde URLs remotas.

Sigue siendo posible permitir la ejecución de scripts mediante una lista de permitidos (allowlist) en el archivo de configuración package.json. Esto estará vinculado por defecto a la versión instalada de un paquete.

Estos son cambios disruptivos, y Balter recomendó que los desarrolladores ejecuten los comandos para permitir scripts en cada paquete actualmente instalado en un proyecto que los requiera. "Esto te protege inmediatamente contra scripts nuevos e inesperados", afirmó. El siguiente paso es revisar estos paquetes y denegar los scripts en aquellos donde no sean necesarios.

Algunos paquetes requieren la aprobación de scripts para funcionar, incluidos los módulos nativos que se compilan al instalar, herramientas de prueba como Playwright y Puppeteer (que obtienen binarios vía postinstall), y Electron, que envuelve el motor del navegador Chromium para aplicaciones de escritorio multiplataforma.

Estas funciones han estado disponibles desde la versión 11.10.0 de npm, lanzada en febrero, pero como flags opcionales en lugar de predeterminados. Esa versión también introdujo min-release-age, que bloquea la instalación de versiones de paquetes más recientes que un número especificado de días, diseñado como una salvaguarda contra paquetes maliciosos recién publicados.

La mejor práctica de seguridad para los desarrolladores que utilizan npm 11.16, la versión actual, es activar estos flags en .npmrc o mediante variables de entorno, lo que también preparará un proyecto para los cambios en la versión 12. Una molestia es que el flag existente ignore-scripts no admite una lista de permitidos, salvo mediante una herramienta adicional. La configuración ignore-scripts anulará a allow-scripts, por lo que los desarrolladores deberán eliminarla, si está establecida en true, para permitir que se ejecuten los scripts aprobados. La configuración allowScripts existe en npm 11 pero es solo consultiva.

¿Solucionará esto los problemas de seguridad de npm?



Lamentablemente no. "Ahora todo el malware puede moverse del script de instalación al módulo mismo, donde inevitablemente se seguirá ejecutando", dijo un desarrollador. Otra opinión común es que los desarrolladores deberían usar pnpm, que ya tiene valores predeterminados más seguros que npm, incluida una edad mínima de lanzamiento.

Existe consenso, sin embargo, en que estos cambios mejoran la seguridad de npm y que eran muy necesarios. El pull request de este cambio incluye la observación de que "npm es el único gestor de paquetes importante restante que ejecuta scripts de instalación de dependencias por defecto. pnpm v10+, Yarn Berry, Bun y Deno los bloquean todos".

Fuente:
TheRegister

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.