Mitos y realidades: Linux y los virus

QUE ES UN VIRUS

Lo primero, que vamos a comenzar definiendo que es un virus. Se trata de un programa que se copia y se ejecuta automáticamente, y que tiene por objeto alterar el normal funcionamiento de un ordenador, sin el permiso o el conocimiento del usuario. Para ellos, los virus reemplazan archivos ejecutables por otros infectados con su código. La definición es estándar, y es una resumen de una linea de la entrada sobre virus que aparece en la Wikipedia.

La parte mas importante de esta definición, y la que diferencia el virus del resto del malware, es que un virus se instala solo, sin el permiso o conocimiento del usuario. si no se instala solo, no es un virus: podría se un rootkit, o un troyano.

Un rootkit es un parche al karnel que permite ocultar determinados procesos a las utilidades de área de usuario. Dicho de otra forma, es una modificación del código fuente del karnel que tiene como objeto que las utilidades que permiten ver que se esta ejecutando en cada momento no visualice un determinado proceso, o un determinado usuario.

Un troyano es análogo: es una modificación al código fuente de un servicio concreto para ocultar determinada actividad fraudulenta. En ambos casos es necesario obtener el código fuente de la versión exacta instalada en la maquina Linux, parchear el código, recompilarlo, obtener privilegios de administrador, instalar el ejecutable parcheado, e inicializar el servicio -en el caso del troyano- o el sistema operativo completo -en el caso del rootkit-. El proceso, como vemos, no es trivial, y nadie puede hacer todo esto "por error". Tanto unos como otros exigen en su instalación que alguien con privilegios de administrador, de forma consciente, ejecute una serie de pasos tomando decisiones de índole técnica. 

Lo cual no es una matiz semántica sin importancia: para que un virus se instale, basta con que ejecutemos un programa infectado como usuario común. Por otro lado, para la instalación de un rootkit o de un troyano es imprescindible que un humano malicioso entre personalmente en la cuenta de root de una maquina, y de forma no autorizada realice una serie de pasos que son potencialmente detectables. Un virus se propaga con rapidez y eficiencia; un rootkit o un troyano necesitan que vayan específicamente por nosotros.

LA TRANSMISIÓN DE LOS VIRUS EN LINUX

El mecanismo de transmisión de un virus, por lo tanto, es lo que realmente lo define como tal, y es la base de la existencia de los mismos. Un sistema operativo es mas sensible a los virus cuanto mas fácil sea desarrollar un mecanismo eficiente y automatizado de transmisión de estos.

Supongamos que tenemos un virus que quiere transmitirse solo. Supongamos que ha sido lanzado por un usuario normal, de forma inocente, al lanzar un programa. Dicho virus tiene exclusivamente dos mecanismos de transmisión:

1. Replicarse tocando la memoria de otros procesos, anclándose a ella en tiempo de ejecución.
2. Abriendo los ejecutables del sistema de ficheros, y añadiendo su código -payload- al ejecutable.

Todos los virus que podemos considerar como tales tienen al menos uno de estos dos mecanismos de transmisión. O los dos. No hay mas mecanismos.

Respecto al primer mecanismo, recordemos la arquitectura de memoria virtual de Linux y como funcionan los procesadores Intel. Estos poseen cuatro anillos, numerados de 0 a 3; a menor numero, mayores los privilegios que tiene el código que se ejecute en dicho anillo. Estos anillos corresponden con estados del procesador, y, por lo tanto, con lo que puede hacer con un sistema estando en un anillo concreto. Linux hace uso del anillo 0 para el karnel, y del anillo 3 para los procesos. No hay código de proceso que se ejecute en anillo 0, y no hay código de karnel que se ejecute en anillos 3. Solo hay un único punto de entrada al karnel desde el anillo 3: la interrupción 80h, que permite saltar del área donde esta el código de usuario al área donde esta el código de karnel.  

El karnel mediante el uso de la memoria virtual hace creer a cada proceso que tiene toda la memoria para el solo. Un proceso -que trabaja en anillo 3- solo puede ver la memoria virtual que le han configurado, por el anillo en el que opera. No es que la memoria de los otros procesos estén protegida; es que para un proceso la memoria de los otros esta fuera del espacio de direcciones. Si un proceso diese una batida a todas las direcciones de memoria, no seria capaz ni de referenciar una dirección de memoria de otros procesos.

¿Por que esto no se puede trampear? Para modificar lo comentado -por ejemplo, generar puntos de entrada en anillo 0, modificar los vectores de interrupciones, modificar la memoria virtual, modificar la LGDT...- solo es posible desde el anillo 0. Es decir, para que in proceso pudiese tocar la memoria de otros procesos o del karnel, debería ser el propio karnel. Y el hecho de que haya un unico punto de entrada y que los parámetros se pasen por registros complica la trampa -de hecho, se pasa por registro hasta lo que se debe hecer, que se implementa luego como un case en la rutina de atención a la interrupción 80h-. 

Otros escenarios es el caso de sistemas operativos con cientos de llamados no documentadas al anillo 0, donde esto si es posible -siempre puede quedar una llamada olvidada mal implementada sobre lo que se pueda desarrollar una trampa-, pero en caso de un sistema operativo con un mecanismo de pasos simple, no lo es.

Por ello, la arquitectura de memoria virtual impide este mecanismo de transmisión; ningún proceso -ni siquiera los que tienen privilegios de root- tienen forma de acceder a la memoria de otros. Podriamos argumentar que un proceso puede ver el karnel; lo tiene mapeado a partir de su dirección de memoria lógica    0xC0000000. Pero, por el anillo del procesador en el que se ejecuta, no puede modificarlo; generaría un trap, ya que son zonas de memoria que pertenecen a otro anillo.

La "solución" seria un programa que modificara el código del karnel cuando es un fichero. Pero el hecho de que estos se recompilen, lo hace imposible. No se puede parchear el binario, ya que hay millones de karnels binarios distintos en el mundo. Simplemente con que al recompilarlo le hubiesen puesto o quitado algo al ejecutable del karnel, o le hubiesen cambiado el tamaño de alguna de las etiquetas que identifican la versión de compilación -algo que se hace incluso involuntariamente- el parche binario no se podría aplicar. La alternativa seria descargar el código fuente de Internet, parchearlo, configurarlo para el hardware apropiad, compilarlo, de forma automática. Todo un reto para el campo de la Inteligencia Artificial. 

Como vemos, ni siquiera un virus como root puede saltar esta barrera. La única solución queda es la transmisión entre ficheros ejecutables. Lo que tampoco funciona. 

MITOS Y MENTIRAS 
Encontramos una gran cantidad de mitos, bulos y simplemente mentiras sobre los virus en Linux. Hagamos una relación de los mismos basándonos en una discusión acontecida hace ya tiempo con un representante de una fabricante de antivirus para Linux que se ofendió mucho por un articuló publicado. Aquella discusión es un buen ejemplo de referencia, ya que toca todos los aspectos sobre los virus en Linux. Vamos a repasar todos estos mitos uno a uno según se comentaron en aquella discusión concreta, pero que tantas veces se ha repetido.


Mito1:
"No todos los programas malignos, particularmente los virus, necesitan privilegios de root para infectar, sobre todo en el caso particular de los virus ejecutables (formato ELF) que infectan otros ejecutables". 

• Respuesta:                                                                                                                                           Quien realice semejante afirmacion desconoce como funciona el sistema de privilegios de Unix. para poder afectar a un fichero, un virus necesita el privilegio de lectura -hay que escribirlo para la modificación sea valida- sobre el fichero del ejecutable que quiere ejecutar. Esto es así siempre, sin excepciones. Y en todas y cada una de las distribuciones, los usuarios que no son root no disponen de estos privilegios. Luego simplemente con no ser root, la infección no es posible.

Mito2:

"Tampoco necesitan ser root para entrar en el sistema por via remota, es el caso de Slapper un gusano que explotando una vulnerabilidad en el SSL de Apache (los certificados que permiten comunicación segura), creo su propia red de maquinas Zombie en septiembre de 2002".

• Respuesta:                                                                                                                                                     Ese ejemplo no alude a un virus, sino a un gusano. La diferencia es muy importante: un gusano es un programa que explota un servicio de cara a Internet para transmitirse. No afecta a programas locales. Por ello, solamente afecta a los servidores; no a maquinas particulares. Los gusanos han sido siempre muy pocos y de incidencia ínfima. Los tres realmente importantes nacieron a los 80, una época en la que Internet era inocente, y todo el mundo se fiaba de todo mundo. Recordemos que eran los que afectaban a sendmail, fingerd y rexec. Hoy en día la cosa es mas complicada. Aunque no podemos negar que sigue habiéndolos y que , si no se controlan, son extremadamente peligrosos, Pero ahora, los tiempos de reacción ante los gusanos son muy cortos. Es el caso del Slapper: un gusano creado sobre una vulnerabilidad descubierta -y parcheada- dos meses antes de la aparición del propio gusano. Aun suponiendo que todo el mundo que usara Linux tuviese Apache instalado y funcionado siempre, simplemente con actualizar mensualmente los paquetes hubiese sido mas que suficiente para que nunca se corriera ningún riesgo. Es cierto que el fallo de SSL que origino Slapper era critico -de hecho, el mayor fallo encontrado en toda la historia de SSL2 y SSL3-, y como tal fue solucionado en pocas horas. que dos meses mas tarde de que se encontrara y se solucionara dicho problema, alguien hiciera un gusano sobre un error ya corregido,y que ese sea el ejemplo mas potente que se puede dar como vulnerabilidad, cuando menos tranquiliza.