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
Comentarios
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
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
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.
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 para enviar datos pueden ser inocuos o no.
Hay programas que pueden recopilar datos utiles para la comunidad de desarrollo. Tambien pienso que se deberia delegar en otro programa y enviar unos datos legibles y con un formato concreto.
Yo creo que este caso se evitaria que una libreria accediese a un sitio que no tiene ver con su funcion. Para prevenir el acceso a contraseñas se podria poner un gestor de contraseñas que solo de contraseñas asignadas al programa que lo pida.
En el caso de Firefox, un programa con acceso poco restringido a internet. Se podria restringir el uso a sus temporales y cuango necesite guardar algun archivo o pagina, se lanza ventana de guardar archivos. Si pilla un malware, es dificil que afecte a todo el ordenador, salvo que lo guarde uno mismo, pero por lo menos no hace cosas por debajo de la vista del usuario.
#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, cualquier librería puede necesitar acceder a Internet por motivos que a ti no te resulten evidentes. Por ejemplo ”dateutil” (una de las impersonadas según en artículo) es para tratar datos de fecha, pero hace uso de tablas de desplazamientos de zonas horarias que hay que actualizar más a menudo de lo que la gente cree.
En cuatro lugar, una librería no necesita código propio para acceder a Internet, puede hacerlo usando otra librería perfectamente legítima. Y pretender erradicar cualquier librería que acceda a Internet es completamente irrealista.
Por último, no es tan fácil saltarse los permisos de usuario. El ejemplo que pones (Firefox) ya actúa exactamente como tú dices. Lo que sucede es que la mayoría de usuarios son tontos e interactivamente abren lo que no deben, por mucho que les adviertas.
#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 componente sólo acceda al rango 12.6.203.0/24? ¿Necesita descargar y/o subir? Si necesita actualizar alguna hez, tendrá que descargar, no tiene por qué subir nada local a la red. Con iptables o cualquier otro firewall ya se puede hacer, pero la cosa es que esto sea manejado por el SO automáticamente, que cada componente tenga que especificar qué va a realizar.
En tu cuarto lugar, si el componente A tiene n permisos y quiere hacer uso de B el cual tiene n2 permisos, A sólo tiene permiso a la intersección entre n y n2.
#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í.
Pero si lo que dices es irrealista... pues es irrealista.
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 arreglas con ningún software, ya te lo avanzo.
3. Eso se llama proxy, y necesita configuración específica que el usuario no va a hacer bien ni de coña. Necesitas un administrador con conocimientos, y me da que no estás hablando de eso.
Y si lo que pretendes es que el componente se autoconfigure, ¿qué le impide entonces a un componente malicioso configurarse para tener acceso a todo lo que desee? No ganas ninguna seguridad con eso, sólo haces el sistema más complejo pero igual de inseguro.
4. Eso no tiene sentido, o como mínimo no corresponde a un sistema de seguridad por componentes como tú pretendes. Según tú, para usar el componente B para (por ejemplo) acceder a Internet, el componente A necesitaría también permiso para acceder a Internet, y entonces ya no necesitaría el componente B para obtener dicho acceso. Es justamente lo contrario de lo que quieres.
#11 Yo también te he entendido, joío.