SEGURIDAD EN UNIX Y REDES

74CAPÍTULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOSincluye evidentemente directorios como /tmp/, pero también otro que a primera vista puede notener mucho sentido: el directorio actual, ‘.’. Imaginemos la siguiente situación: el root de unsistema Unix tiene incluido en su variable $PATH el directorio actual como uno más donde buscarejecutables; esto es algo muy habitual por cuestiones de comodidad. Por ejemplo, la variable deentorno 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/binanita:~#Si este administrador desea comprobar el contenido del directorio /tmp/, o el de $HOME de algunode sus usuarios (recordemos, directorios donde pueden escribir), seguramente irá a dicho directorioy 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 cualquierapuede escribir en el directorio, ese programa puede tener el siguiente contenido:anita:~# cat /tmp/ls#!/bin/shrm -rf /usr/ &anita:~#Como podemos ver, un inocente ‘ls’ puede destruir parte del sistema de ficheros – o todo –, simplementeporque el administrador no ha tenido la precaución de eliminar de su $PATH directoriosdonde los usuarios puedan escribir.Seguramente alguien encontrará una solución – falsa – a este problema: si la cuestión reside enel orden de búsqueda, ¿por qué no poner el directorio actual al final del $PATH, depués de todoslos directorios fiables? De esta forma, el programa ./ls no se ejecutará nunca, ya que antes el shellva a encontrar con toda seguridad al programa legítimo, /bin/ls. Evidentemente esto es así, peroes fácil comprobar que el problema persiste: imaginemos que estamos en esa situación, y ahoratecleamos en /tmp/ la orden ls|more. 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 equivocamosal 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 similaral /tmp/ls anterior? De nuevo nos encontramos ante el mismo problema: una orden tan inocentecomo esta puede afectar gravemente a la integridad de nuestras máquinas. Visto esto, parece claroque bajo ningún concepto se ha de tener un directorio en el que los usuarios puedan escribir, nisiquiera el directorio actual (‘.’) en la variable $PATH.5.4.1 VirusUn virus es una secuencia de código que se inserta en un fichero ejecutable denominado host, deforma que al ejecutar el programa también se ejecuta el virus; generalmente esta ejecución implicala copia del código viral – o una modificación del mismo – en otros programas. El virus necesitaobligatoriamente un programa donde insertarse para poderse ejecutar, por lo que no se puede considerarun programa o proceso independiente.Durante años, un debate típico entre la comunidad de la seguridad informática es la existenciade virus en Unix ([Rad92], [Rad93], [Rad95]. . . ). ¿Existen virus en este entorno, o por el contrarioson un producto de otros sistemas en los que el concepto de seguridad se pierde? Realmenteexisten virus sobre plataformas Unix capaces de reproducirse e infectar ficheros, tanto ELF comoshellscripts: ya en 1983 Fred Cohen diseñó un virus que se ejecutaba con éxito sobre Unix en una