Fauna y otras amenazas

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 seguridad^6.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.