PDF de programación - Mitos y realidades: Linux y los virus

reportaje ]

Mitos y realidades:
Linux y los virus
E l debate sobre Linux y los vi-

solo, sin el permiso o conocimiento del
usuario. si no se instala solo, no es un
virus: podría ser un ser un rootkit, o un
troyano.

rus no es algo nuevo. Cada
cierto tiempo vemos un co-

rreo en alguna lista preguntando si
existen virus para Linux; y automá-
ticamente alguien responde afirma-
tivamente y alega que si no son
más populares es porque Linux no
está tan extendido como Windows.
También son frecuentes las notas
de prensa de desarrolladores de
antivirus diciendo que sacan ver-
siones contra los virus de Linux.

Personalmente he tenido alguna que
otra discusión con distintas personas por
correo, o por lista de distribución, respec-
to al tema de si existen o no los virus en
Linux. se trata de un mito, pero es com-
plejo derribar un mito o, mejor dicho, un
bulo, especialmente si está causado por
interés económico. A alguien le interesa
transmitir la idea de que si Linux no tiene
este tipo de problemas, es porque muy
poca gente lo utiliza.

A la hora de publicar este reportaje me

hubiese gustado elaborar un texto defini-
tivo sobre la existencia de virus en Linux.
Desgraciadamente, cuando la supersti-
ción y el interés económico campan a sus
anchas, es difícil construir algo definitivo.
no obstante, intentaremos hacer aquí un
argumentario razonablemente completo
para desarmar los ataques de cualquiera
que quiera discutirlo.

QUÉ ES UN VIRUS
Lo primero, vamos a comenzar definiendo
qué es un virus. se trata de un programa
que se copia y se ejecuta automática-
mente, y que tiene por objeto alterar el
normal funcionamiento de un ordenador,
sin el permiso o el conocimiento del usua-
rio. Para ello, los virus reemplazan archivos
ejecutables por otros infectados con su
código. La definición es estándar, y es un
resumen de una línea de la entrada sobre
virus que aparece en la Wikipedia.

La parte más importante de esta defi-
nición, y la que diferencia el virus del resto
del malware, es que un virus se instala

un rootkit es un parche al kernel 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 kernel que tiene como objeto
que las utilidades que permiten ver qué
se está ejecutando en cada momento no
visualicen un determinado proceso, o un
determinado usuario.

un troyano es análogo: es una mo-

dificación al código fuente de un servicio
concreto para ocultar determinada ac-
tividad fraudulenta. En ambos casos es
necesario obtener el código fuente de la
versión exacta instalada en la máquina
Linux, parchear el código, recompilarlo,
obtener privilegios de administrador, insta-
lar el ejecutable parcheado, e inicializar el
servicio –en el caso del troyano– o el sis-
tema 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 deci-
siones de índole técnica.

Lo cual no es un matiz semántico 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 máquina, y
de forma no automatizada realice una
serie de pasos que son potencialmente
detectables. un virus se propaga con ra-
pidez y eficiencia; un rootkit o un troyano
necesitan que vayan específicamente a
por nosotros.

DAVID SANTO ORCERO
[email protected]

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 más
sensible a los virus cuanto más fácil sea
desarrollar un mecanismo eficiente y au-
tomatizado de transmisión de estos.

supongamos que tenemos un virus

que quiere transmitirse solo. supongamos
que ha sido lanzado por un usuario nor-
mal, de forma inocente, al lanzar un pro-
grama. Dicho virus tiene exclusivamente
dos mecanismos de transmisión:
 replicarse tocando la memoria de otros
procesos, anclándose a ellos en tiempo
de ejecución.

 Abriendo los ejecutables del sistema

de ficheros, y añadiendo su código
–payload– al ejecutable.
Todos los virus que podemos consi-

derar como tales tienen al menos uno de
estos dos mecanismos de transmisión. o
los dos. no hay más mecanismos.

respecto al primer mecanismo, re-
cordemos la arquitectura de memoria
virtual de Linux y cómo funcionan los
procesadores intel. Estos poseen cuatro
anillos, numerados de 0 a 3; a menor nú-
mero, 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
se puede hacer con un sistema estando
en un anillo concreto. Linux hace uso del
anillo 0 para el kernel, 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 kernel que se ejecute en anillo
3. solo hay un único punto de entrada
al kernel desde el anillo 3: la interrupción
80h, que permite saltar del área donde
está el código de usuario al área donde
está el código de kernel.

La arquitectura de Unix en general y de Linux en
Sumario Par
particular no hace factible la dispersión de un virus

26

número 90

www.studiopress.es

El kernel mediante el uso de la memo-
ria virtual hace creer a cada proceso que
tiene toda la memoria para él solo. un pro-
ceso –que trabaja en anillo 3– solo puede
ver la memoria virtual que le han confi-
gurado, por el anillo en el que opera. no
es que la memoria de los otros procesos
esté protegida; es que para un proceso
la memoria de los otros está fuera del es-
pacio de direcciones. si un proceso diese
una batida a todas las direcciones de me-
moria, no sería capaz ni de referenciar una
dirección de memoria de otro proceso.

¿Por qué esto no se puede trampear?

Para modificar lo comentado –por ejem-
plo, 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 un proceso pudiese
tocar la memoria de otros procesos o del
kernel, debería ser el propio kernel. y el
hecho de que haya un único punto de en-
trada y que los parámetros se pasen por
registros complica la trampa –de hecho,
se pasa por registro hasta lo que se debe
hacer, que se implementa luego como un
case en la rutina de atención a la interrup-
ción 80h–.

otro escenario es el caso de sistemas

operativos con cientos de llamadas no
documentadas al anillo 0, donde esto sí

es posible –siempre puede quedar una
llamada olvidada mal implementada sobre
la que se pueda desarrollar una trampa–,
pero en caso de un sistema operativo con
un mecanismo de paso tan simple, no lo
es.

Por ello, la arquitectura de memoria
virtual impide este mecanismo de trans-
misión; ningún proceso –ni siquiera los
que tienen privilegios de root– tienen
forma de acceder a la memoria de otros.
Podríamos argumentar que un proceso
puede ver el kernel; lo tiene mapeado a
partir de su dirección de memoria lógica
0xC0000000. Pero, por el anillo del pro-
cesador 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” sería un programa que

modificara el código del kernel cuando es
un fichero. Pero el hecho de que estos se
recompilen, lo hace imposible. no se pue-
de parchear el binario, ya que hay millones
de kernels binarios distintos en el mundo.
simplemente con que al recompilarlo le
hubiesen puesto o quitado algo al ejecu-
table del kernel, 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 al-

Mi experiencia como administrador 
En más de diez años que llevo administrando Linux, con instalaciones en
cientos de máquinas de centros de cálculo, laboratorios de alumnos, em-
presas, etc.
 Nunca me ha "entrado" un virus
 Nunca he conocido a alguien que le haya ocurrido
 Nunca he conocido a alguien que haya conocido a alguien que le haya

ocurrido

Conozco a más gente que ha visto al monstruo del Lago Ness a que haya
visto virus para Linux.
Personalmente, reconozco que he sido un temerario, y he lanzado varios
programas que los autoprocramados “especialistas” denominan “virus pa-
ra Linux” -en adelante, los denominaré virus, para no hacer pedante el tex-
to-, desde mi cuenta habitual contra mi máquina, para ver si es posible un
virus: tanto el virus bash que circula por ahí -y que, por cierto, no me infectó
ningún fichero-, como un virus que se hizo muy famoso, y salió en la pren-
sa. Intenté instalarmelo; y después de veinte minutos de trabajo, me rendí
cuando vi que entre sus exigencias estaba tener el directorio tmp en una
partición del tipo MSDOS. Personalmente, no conozco a nadie que cree
una partición específica para tmp y la formatee en FAT.
De hecho, algunos supuestos virus que he probado para Linux necesi-
tan un nivel de conocimientos altos y la clave de root para ser instalados.
Podríamos calificar, cuanto menos, de “cutre” un virus si necesita nuestra
intervención activa para que nos infecte la máquina. Además, en algún ca-
so requieren amplios conocimientos de UNIX y la clave de root; lo que está
bastante lejos de la instalación automática que se le supone.

Linux y Los virus

REPORTAJE

ternativa sería descargar el código fuente
de internet, parchearlo, configurarlo para
el hardware apropiado, compilarlo, ins-
talarlo y reiniciar la máquina. Todo esto lo
debería