[LUG.ro] Virus en GNU/Linux

[Gabriel Parrondo]

David, muchas gracias por tomarte el tiempo de responder.

El día 9 de septiembre de 2014, 15:22, David Santo Orcero
<irbis en orcero.org> escribió:
>
>
>  No me molesta. :)
>
>
>> No es específico de GNU/Linux, cualquier SO moderno funciona así,
>> incluído Windows.
>
>
>  No siempre ha sido así. En los noventa, los únicos sistemas operativos que
> corrían en un PC e implementaban separación de memoria total eran los
> sabores de Unix.

Pero los 90 fueron hace 20 años ;)

[...]


>
>  Es evidente que el hecho de no haberlo visto, no significa que no exita.
> Pero si técnicamente no puede existir, y además nadie ha visto uno...
>

Ese es el punto, tecnicamente puede existir, aunque sea poco practico
comparado con otras formas de "infectar" un sistema GNU/Linux.


>> Esto tampoco es específico de linux, windows funciona igual a menos
>> que se use alguna versión antigua. Y en ese caso, deberia compararse
>> contra una distribución antigua de GNU/Linux.
>
>
>  El sistema de seguridad de Linux es el de Unix, y hasta donde sé,
> implementa separación de privilegios desde los años setenta. Linux lo
> implementa desde su inicio. La separación de privilegios era inexistente
> hasta XP (dejando a un lado la rama de NT, que sí la tenía); y a partir de
> XP ha sido discutible hasta hace poco (lo que he de confesar que no ha sido
> un problema en NT hasta NT 4).
>

XP se publicó hace mas de 10 años. Si tomo una versión del kernel de
hace 10 años hay varios exploit localroot y otros zero-day
disponibles.

Limitémonos a sistemas actuales, con todos los parches de seguridad instalados.


>Eso es un problema, pero en el momento en el que el API es un queso de gruyere, se convierte en un problemón. Problema que no tiene >linux; que tiene el acceso entero a través de la interrupción 80, con un único mecanismo exclusivo de escalado a kernel.

Desconozco la API de WIndows como para decir si es un queso gruyere o no.

De todas formas, estás confundiendo API con ABI. La interrupción 80h
es el mecanismo de bajo nivel para realizar una syscall en
procesadores intel x86 en linux. Otros procesadores tienen la
instrucción syscall y otros no tienen este mecanismo. En windows por
otro lado, la única forma de hacer una syscall es a traves de una
biblioteca del sistema, no hay un ABI directa con el kernel en este
sentido. Si es mas seguro de una forma u otra no lo se, no creo que
haya diferencia.

La lista de syscalls es grande y aburrida, tanto en windows como en
linux. Lo que importa son los esquemas de autorización y escalado de
privilegios.

En un escritorio GNU/Linux, el escalado de privilegios se realiza a
traves de dbus, utilizando polkit como mecanismo de autorización.

En escritorios windows creo que el sistema se llama UAC. No estoy tan
familiarizado con éste último.

Respecto a lo que mencionas en otro punto sobre los drivers de video
en windows, los drivers de video en linux también pasaron al kernel
mediante DRM/KMS. Hay ventajas importantes en hacerlo así, y en todo
caso el acceso a los dispositivos es competencia del kernel, sean de
video, I/O, audio, etc.




>> Inyectar código para que un programa lo ejecute no necesariamente
>> implica modificar el ejecutable del programa. LD_PRELOAD puede hacer
>> mucho por un potencial atacante.
>
>
>  Completamente cierto. Ahora dime como haces un escalado de privilegios con
> LD_PRELOAD, y cómo lo automatizas para meterlo en un virus. Te recuerdo que
> LD_PRELOAD solo te permite sustituir bibliotecas dinámicas en arranque, lo
> que se utiliza mucho para depurar y para ingeniería inversa; pero de por sí
> solo podrás hacer lo que pueda hacer el usuario y el proceso que estás
> lanzando.
>

Mas que suficiente para abrir un backdoor, e iniciarlo cada vez que el
usuario carga el DE. O hacer un millon de cosas mas.

>
>> Ademas, la proteccion por permisos del sistema de archivos solo tiene
>> relevancia en un sistema multiusuario, en un sistema monousuario
>
>
>  8-O
>
>
>> (tipica instalación de escritorio) lo único importante está en el home
>> del usuario, no hace falta elevación. En este sentido el esquema que
>> usan los sistemas como android ofrece una gran mejora para la
>> seguridad.
>
>
>  Si. El android es muy seguro. Ejem. Ejem.

No se si lo sea, pero dentro del esquema de seguridad considera el
hecho de que el sistema es monousuario y lo utiliza muy bien. A eso me
refería. Varias distros podrian tomar este ejemplo y la seguridad
mejoraría muchisimo.


>
>  Respecto a lo del sistema monousuario y multiusuario.
>
>  Te recomiendo que indages un poco en el modelo de seguridad de Unix, porque
> creo que no lo has entendido. Un unix que solo lo utilice una persona, así a
> ojo tiene un mínimo de 30 usuarios. En sistemas donde la seguridad es
> delicada y se hace uso intensivo del grupo weel, podemos tener unas pocas de
> usuarios más.
>
>  Una pista: como mínimo tienes un usuario por servicio, o por dispositivo
> privilegiado. Cuando entiendas porqué, entenderas el modelo de seguridad de
> Unix.

Entiendo perfectamente porqué. A lo que iba es a que en un sistema que
utiliza una sola persona, infectar /home/usuario o infectar /usr/bin
es exactamente lo mismo.

En otras palabras, no poder escribir en /usr es irrelevante. Y no
poder escalar privilegios también. Toda la información interesante
está en /home/usuario, y todos los privilegios importantes están
disponibles para usuario (a saber, abrir escucha en puertos, crear y
borrar archivos, etc.)


Parafraseando a xkcd: si un virus entra en mi pc pueden leer mis
mails, tomar mi dinero y hacerse pasar por mi con mis amigos, pero por
lo menos no podrá instalar drivers sin mi autorizacion.
http://xkcd.com/1200/

>
>> Por último, la distinción entre virus y malware es válida. Pero
>> también es cierto que el peligro mas grande para los usuarios hoy son
>> los spyware, troyanos y miners. Y el vector de infección es siempre
>> una acción iniciada por el usuario.
>
>
>  El peligro más grande en Windows.
>

Es posible, pero no por una cuestión técnica.


>  Spyware y miners tienen el problema de que los vectores de transmisión
> comunes en un Unix bien protegido están cerrados. Los troyanos,
> habitualmente requieren una cuenta ssh y que un humano haga un proceso de
> escalado a mano. No son trivialmente automatizables, como sí lo son en
> Windows.

El vector de transmisión es el usuario.

Un sistema es tan seguro como el administrador que lo configuró.
Cuando ese administrador es un usuario con pocos conocimientos
técnicos dispuesto a seguir cualquier tutorial que encuentre para
realizar la tarea X, no importa que sistema operativo tenga debajo.

Creo que la única conclusión lógica es que si bien GNU/Linux es muy
superior a Windows, el motivo no son los virus o la falta de ellos.

El motivo por el que es superior es porque es un sistema operativo
libre. Pero me voy de tema.


PD:
Abusando de tu paciencia, aprovecho para agregar algo que me habia
quedado en el tintero. En el articulo mencionas lo siguiente:
"""
1) El virus entra en el sistema.
2) Localiza el código fuente del kernel. Si no está lo instala él mismo.
3) Configura el kernel para las opciones de hardware que procedan para
la máquina en cuestión.
4) Compila el kernel.
5) Instala el nuevo kernel; modificando LILO o GRUB si es preciso.
6) Reinicia la máquina.
"""

Y considerás que los pasos 2-4 son imposibles y ridículos (con lo cual
coincido plenamente :-) ). Pero te recuerdo que el kernel linux
soporta módulos. Los pasos simplemente serían:
1) El virus entra en el sistema
2) Verifica la version del kernel y si los headers no están
disponibles los descarga de un repositorio público
3) Compila el modulo virusmalisimo.ko
4) Carga el módulo en el kernel

Como ves, el único paso que presenta dificultades es el 4, que
requiere privilegios de root. Como en tu ejemplo estás dando esto por
sentado yo haré lo mismo.