En el punto anterior hemos hablado de problemas de seguridad derivados de
errores o descuidos a la hora de programar; sin embargo, no todas las amenazas
lógicas provienen de simples errores: ciertos programas, denominados en su
conjunto malware o software malicioso, son creados con la
intención principal de atacar a la seguridad6.3. En esta sección vamos a
hablar de algunos tipos de malware, sus características y sus
efectos potenciales.
Para prevenir casi todo el software malicioso que pueda afectar a
nuestros sistemas es necesaria una buena concienciación de los usuarios: bajo
ningún concepto han de ejecutar software que no provenga de fuentes
fiables, especialmente programas descargados de páginas underground o
ficheros enviados a través de IRC. Evidentemente, esto se ha de aplicar
- y con más rigor - al administrador de la máquina; si un usuario
ejecuta un programa que contiene un virus o un troyano, es casi imposible que
afecte al resto del sistema: en todo caso el propio usuario, o sus ficheros,
serán los únicos perjudicados. Si es el root quien ejecuta el programa
contaminado, cualquier archivo del sistema puede contagiarse - virus - o las
acciones destructivas del malware - troyano - afectarán sin
límites a todos los recursos del sistema. Aparte de descargar el software de fuentes fiables, es recomendable utilizar las `huellas' de
todos los programas (generalmente resúmenes MD5 de los ficheros) para
verificar que hemos bajado el archivo legítimo; también es preferible
descargar el código fuente y compilar nosotros mismos los programas: aparte
de cuestiones de eficiencia, siempre tenemos la posibilidad de revisar el
código en busca de potenciales problemas de seguridad.
Otra medida de seguridad muy importante es la correcta asignación de la
variable de entorno $PATH, especialmente para el administrador del
sistema. Esta variable está formada por todos los directorios en los que
el shell buscará comandos para ejecutarlos; podemos visualizar su
contenido mediante la siguiente orden:
anita:~# echo $PATH
/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/sbin:
/usr/dt/bin:/usr/openwin/bin:/usr/share/texmf/bin
anita:~#
Cuando un usuario teclea una órden en la línea de comandos, el shell busca en cada uno de estos directorios un ejecutable con el mismo
nombre que el tecleado; si lo encuentra, lo ejecuta sin más, y si no lo
encuentra se produce un mensaje de error (el clásico `command not
found'). Esta búsqueda se realiza en el orden en que aparecen los
directorios del $PATH: si por ejemplo se hubiera tecleado `ls',
en nuestro caso se buscaría en primer lugar /sbin/ls; como -
seguramente - no existirá, se pasará al siguiente directorio de la
variable, esto es, se intentará ejecutar /usr/sbin/ls. Este fichero
tampoco ha de existir, por lo que se intentará de nuevo con /bin/ls,
la ubicación normal del programa, y se ejecutará este fichero.
>Qué problema hay con esta variable? Muy sencillo: para que sea
mínimamente aceptable, ninguno de los directorios del $PATH ha de
poseer permiso de escritura para los usuarios normales; esto incluye
evidentemente directorios como /tmp/, pero también otro que a primera
vista puede no tener mucho sentido: el directorio actual, `.'. Imaginemos
la siguiente situación: el root de un sistema Unix tiene incluido en su
variable $PATH el directorio actual como uno más donde buscar
ejecutables; esto es algo muy habitual por cuestiones de comodidad. Por ejemplo,
la variable de entorno puede tener el siguiente contenido:
anita:~# echo $PATH
.:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/sbin:
/usr/dt/bin:/usr/openwin/bin:/usr/share/texmf/bin
anita:~#
Si este administrador desea comprobar el contenido del directorio /tmp/,
o el de $HOME de alguno de sus usuarios (recordemos, directorios donde
pueden escribir), seguramente irá a dicho directorio y ejecutará un simple
ls. Pero, >qué sucede si el `.' está en primer lugar en la
variable $PATH? El shell buscará en primer lugar en el
directorio actual, por ejemplo /tmp/, de forma que si ahí existe un
ejecutable denominado `ls', se ejecutará sin más: teniendo en
cuenta que cualquiera puede escribir en el directorio, ese programa puede tener
el siguiente contenido:
anita:~# cat /tmp/ls
#!/bin/sh
rm -rf /usr/ &
anita:~#
Como podemos ver, un inocente `ls' puede destruir parte del sistema de
ficheros - o todo -, simplemente porque el administrador no ha tenido la
precaución de eliminar de su $PATH directorios donde los usuarios
puedan escribir.
Seguramente alguien encontrará una solución - falsa - a este problema:
si la cuestión reside en el orden de búsqueda, >por qué no poner el
directorio actual al final del $PATH, depués de todos los directorios
fiables? De esta forma, el programa ./ls no se ejecutará nunca, ya que
antes el shell va a encontrar con toda seguridad al programa
legítimo, /bin/ls. Evidentemente esto es así, pero es fácil
comprobar que el problema persiste: imaginemos que estamos en esa situación,
y ahora tecleamos en /tmp/ la orden lsmore. No ocurrirá
nada anormal, ya que tanto `ls' como `more' son programas que
el shell ejecutará antes de analizar `.'. Pero, >qué
pasaría si nos equivocamos al teclear, y en lugar de `more'
escribimos `moer'? Al fin y al cabo, no es un ejemplo tan rebuscado, esto
seguramente le ha pasado a cualquier usuario de Unix; si esto ocurre así,
el intérprete de órdenes no encontrará ningún programa que se llame
`moer' en el $PATH, por lo que se generará un mensaje de
error...>Ninguno? >Y si un usuario ha creado /tmp/moer, con un
contenido similar al /tmp/ls anterior? De nuevo nos encontramos ante el
mismo problema: una orden tan inocente como esta puede afectar gravemente a la
integridad de nuestras máquinas. Visto esto, parece claro que bajo ningún
concepto se ha de tener un directorio en el que los usuarios puedan escribir,
ni siquiera el directorio actual (`.') en la variable $PATH.
Subsecciones
© 2002 Antonio Villalón Huerta
