EDICIóN GENERAL
176 meneos
1202 clics

Consiguen infiltrar dos librerías maliciosas en el repositorio oficial de Python

Recientemente se ha detectado que consiguieron infiltrar dos librerías maliciosas en el repositorio oficial de Python que robaban claves GPG y SSH. El desarrollador Lukas Martini encontró dos librerías sospechosas buscando en PyPI. Una de ellas llevaba un año y la otra unos días. Simulaban ser las librerías “datetutil” y “jellyfish”. Simplemente les había cambiado el nombre con “python3-dateutil” y “jeIlifish”. El código malicioso descargaba código codificado desde un repositorio GitLab

| etiquetas: python , librerías maliciosas , datetutil , jellyfish , gitlab
Enésima consecuencia de la libreriítis de los tiempos modernos. Con lo bonito que es programar, no sé en qué momento pasamos a ser montadores del Ikea

Ahora meten un bicho en jQuery y revienta Internet. Y todo porque no querer escribir una petición Ajax o acceder a un elemento a través de la API del DOM de forma nativa
#13 Efectivamente, simplifica mucho la seguridad en caso de que el usuario tenga una minima voluntad.

Es como si un coche tiene testigo de exceso de temperatura. El conductor puede ignorar el aviso. El testigo noo puede impedir que siga conduciendo hasta romper el motor, pero lo normal es que tome medidas.

Que no sea absolutamente imposible de evitar todos los riesgos, no quiere decir que no sirva para nada.
Nunca hay que bajar la guardia incluso cuando usas repositorios oficiales.
Entiendo que es al instalarlas y que no vienen por defecto con python
#1 Están en el repositorio oficial de extensiones, no en la distribución de Python.

La putada es que tienen nombres muy similares a extensiones que la gente suele utilizar.
#12 Sobre 0:
Linux skynet 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

1 y 2, estás hablando de teléfonos móviles? Yo en Linux si ejecuto un script en Python, Perl o compilado de C, puedo acceder a casi todo el sistema de ficheros para leer.

3. Se autoconfigure no, conocerás el AndroidManifest.xml o Info.plist de iOS. No entiendo por qué no ha de ser igual en apps de escritorio. Si uno es gilipollas y autoriza algo que no debe que se joda, pero es que no se pregunta.

4.- Sí necesitaría el componente B si no quiere implementarlo él mismo. Se ahorran tiempos de desarrollo.
#13

1. y 2. Si ejecutas programas con un usuario que tiene acceso a partes del sistema que no quieres que esos programas accedan, ¿en serio pretendes echarle la culpa al programa? Si tienen acceso a esos recursos es porque TÚ se lo permites, tío.

En un sistema bien configurado, un programa sólo va a tener acceso de lectura a los binarios y librerías dinámicas instalados, al directorio temporal, y a SUS bases de datos, SUS ficheros de configuración y SUS logs.

3. Tú proponías un proxy de recursos accesibles, no un manifiesto de privilegios. No me cambies los palos de la portería de sitio cada vez que contesto.

4. Estamos hablando de componentes maliciosos. ¿Crees que se programan pensando en ahorrar tiempo de desarrollo?
#14 Que vaya bien
#15 Chato, no te hagas el ofendidito porque no te dan la razón. Especialmente si no la tienes.

Y lo de ejecutar programas utilizando un usuario con más privilegios de los requeridos es una deformación de ”windowsero”, te pongas como te pongas. Si de verdad usas Debian, que es bastante seguro, cúrratelo y pon un poquito de tu parte en esa seguridad, que ningún sistema es inmune a ser mal administrado.
#16 Pero si es que no se trata de llevar razón o no. Estoy dando ideas que no tienen que ver contigo y tú sin embargo estás atacándome a nivel personal. Si no se trata de mí, miope, estábamos hablando de la noticia.

Según tú uso Windows, administro mal mi Debian, etc etc. ¿No te das cuenta que yo no hice lo mismo contigo? ¿No te das cuenta que yo no hablaba de mí?
Pero están en Pypi. Que es el repositorio oficial y que tiene bastante buena fama por sus controles. Pero entiendo que algo se pueda pasar.
#2 Pypi tiene algun control? Anonadado me hallo :troll:
La verdad es que ha sido una cagada gorda, pero se me ocurren dos soluciones:

- Que las claves estén cifradas con una contraseña maestra, buena suerte rompiendo un AES.
- Utilizar un token hardware. Yo me compré un Yubikey y estoy encantado, es muy fácil de utilizar y extraer la clave privada es imposible.
El uso de librerías de terceros no debería hacerse a la ligera. Es evidente que hoy no puedes construirte aplicaciones en un tiempo razonable sin acudir a ellas pero eso es como decían en la película de Spider-Man: un gran poder implica una gran responsabilidad.

Así que más testear lo que se hace y elegir bien las piezas que usamos en nuestro software y menos abusar de corta pega de stack overflow
Cada vez mas veo que los permisos de usuario son escasos. Deberia haber mas restricciones por programas.
Casi todos los programas necesitan un espacio para cosas temporales suya y luego se guarda el trabajo con un ventana emergente y no necesitan fisgar por el ordenador o guardar ficheros por debajo del conocimiento del usuario.

Otros muchos no necesitan acceder a internet para nada mas que actulizarse. Se delega la actualizacion en otro programa y si accede a internet es sospechoso. Tampoco…   » ver todo el comentario
#6 En primer lugar, la inmensísima mayoría de programas sí necesitan leer y guardar cosas sin conocimiento del usuario. Por infinitos motivos además. Como pretendas que cada vez que lo hagan le pregunten al usuario, te vas a cagar ante un ordenador que estará siempre parado.

En segundo lugar, no todos los programas tienen (ni necesitan) interfaz gráfica. Los que proveen servicios ni siquiera son interactivos. Y hablando de lenguajes de scripting como Python, son la mayoría.

En tercer lugar,…   » ver todo el comentario
#7 En tu primer lugar, él se refiere a que la inmensísima mayoría de programas necesitan un directorio concreto para almacenar sus mierdas, no acceso lectura a TODO tu disco duro.

En tu segundo lugar, ¿y qué? todo pasa por el kernel y sus syscalls. Si un determinado componente necesita ser registrado con una serie de funciones, no se le deja hacer nada más que lo que se le permitió.

En tu tercer lugar, por supuesto que sí, pero ya que estamos imaginando, ¿por qué no limitar que un determinado…   » ver todo el comentario
#9 Gracias, Me alegra que se haya entendido. :-)
A veces hay que tener un poco de voluntad por entender las cosas.
#9 Me parece que estáis tan acostumbrados a usar Windows con sus infinitos agujeros que os creéis que todo es así.

1. Eso ya funciona así. Para obtener datos externos a su espacio de almacenamiento una aplicación necesita el permiso expreso del usuario.

2. Eso ya funciona así. Las llamadas a sistema están férreamente protegidas en función de los derechos del usuario.

Lo que sucede con 1 y 2 es que el usuario estándar es memo y autoriza todo sin hacer caso de las advertencias. Eso no lo…   » ver todo el comentario
comentarios cerrados

menéame