¿Cómo Escribir Programas Seguros? - Cuidado con los "Buffer Overflow"

Últimamente muy de moda, los "Buffer Overflow" son una de las vulnerabilidades de seguridad más peligrosas que puede tener un programa ya que, por lo general, permiten la ejecución de código arbitrario en el servidor. Las implicaciones son claras, sobre todo si el demonio corre como "root". El típico error de desbordamiento se produce cuando el programa intenta escribir o copiar en un búffer interno más bytes que el tamaño del búffer, y los bytes que sobran machacan la memoria que lo rodea (típicamente el stack). Lo menos que se puede esperar, en esos casos, es que el servicio muera debido a la corrupción de sus estructuras de datos pero, con un poco de suerte, un atacante puede llegar a ejecutar el código que desee.

En lenguajes donde existe implícita una comprobación de límites, como puede ser el ADA, el Módula-2/3, Java o el entrañable BASIC, el riesgo de corromper la memoria es mínimo; al menos mientras no nos dediquemos a jugar con punteros. Pero lenguajes como el C, hoy por hoy tan populares en este mundillo, no disponen de esas verificaciones y es el programador, por tanto, quien debe tener los ojos bien abiertos mientras mueve datos de un lado a otro de la memoria.

Debemos programar defensivamente, por tanto, anticipándonos al atacante. No podemos confiar en conocer la longitud máxima de ninguna estructura que no hayamos definido nosotros mismos, sobre todo si está bajo el control del atacante. Por ejemplo, si nuestro CGI hace algo así:

sprintf(buf,"Bienvenido, usuario %s\n",remote_hostname);

y "remote_hostname" es el nombre de la máquina remota, primero deberíamos comprobar su longitud so pena de que el atacante tenga acceso al DNS e intente desbordar "buf".

Recordad: un poco de paranoia sana no hace mal a nadie. Sólo quita un poco de sueño y nos hace crecer las dioptrías de tanto ver la pantalla, leer documentación técnica y recibir avisos de seguridad.

En general todas las funciones que escriban en memoria sin una acotación de tamaño son peligrosas y deben revisarse cuidadosamente: strcpy(), strcat(), sprintf(), gets()... Muchas de ellas tienen contrapartidas con límite, como strncpy(), pero no siempre son exactamente equivalente, sobre todo en lo que respecta al "\0" de final de cadena. En general considero preferible hacer un chequeo con "strlen()" antes de utilizar esas funciones. O eso o poner "a mano" un "\0" en la máxima longitud permitida de la cadena a copiar.

¿De dónde provienen esos datos tan grandes?. Pues de todas las vías de información que el programa recoge a su alrededos. Hay cuatro puertas de entrada que hay que vigilar con cuidado, fundamentalmente:

• La línea de comandos
• Las variables de entorno
• Los ficheros de datos que lee el programa
• Los comandos remotos que te puede enviar un atacante

A éstas hay que añadir las propias de cada programa, como el resultado de operaciones internas.

Resulta muy conveniente repasar varias veces la comprobación de límites de nuestros programas ya que, en numerosas ocasiones y como es algo que no debería ejecutarse nunca en condiciones de explotación normales, el propio código de chequeo es incorrecto. Debemos recordar, también, que algunas funciones "estándar" pueden padecer de "buffer overflow" de forma interna; uno de los casos más famosos es "syslog()".