Vamos a entrar de lleno en las aplicaciones de usuario y cómo Windows se protege del malware.

7.- Cómo funciona un ejecutable

De nuevo un poco de teoría. Cuando uno ejecuta un programa (y recordemos que los ficheros que conforman el núcleo también lo son), o más bien cuando se carga en memoria previa ejecución, éste queda dividido en al menos tres partes. Estas partes se llaman segmentos, y cada uno tiene una tarea diferente.

Por un lado tenemos el segmento de código, que es donde están las instrucciones que se van a ejecutar.

Otra sección es el segmento de datos, que es donde residen los datos temporales que va a usar la aplicación. Ahí es donde están guardados, por ejemplo la dirección de la página web que vamos a consultar, junto a la propia página web descargada. El núcleo también necesita datos temporales, como la lista de ficheros de un directorio, por poner un ejemplo.

El tercer segmento es la pila. Esto es un poco complicado de explicar, pero es un segmento de datos en el que se guarda el estado intermedio entre una llamada a función y otra. Digamos que el segmento de código realiza una llamada al sistema operativo para abrir un fichero. Entonces se guarda en la pila la dirección de retorno y los registros del procesador, más otras cosas necesarias como las variables locales y lo que la llamada a la rutina del sistema operativo nos va a devolver. Cuando esta termina de ejecutarse, lo que haya allí es el resultado de la operación y lo que es más importante, a dónde retornar en el código ejecutable.

8.- Pila y DEP

Pongamos y supongamos que al navegar por internet, estamos viendo y por lo tanto hemos bajado una supuesta página web maligna. Esa web, el código HTML, sctripts, imágenes, todo, se guarda en el segmento de datos. Y el código del navegador interpreta esos datos para mostrárnoslos en pantalla.

Pero resulta que aprovechando una vulnerabilidad en el código de ese navegador, se ha producido un desbordamiento de buffer en la pila y la URL maligna nos ha cambiado la famosa dirección de retorno, que originalmente apuntaba a otro lado del segmento de código pero que ahora apunta a algo dentro del segmento de datos.

¿Cómo? Pues gracias a una vulnerabilidad no parcheada en el programa, una vulnerabilidad que ha hecho que al teclear algo nosotros, o al recibir un parámetro, se has sobreescrito la pila. Hay verdaderos artistas en esta técnica. Para hacer fácil lo difícil, diremos que la pila crece hacia abajo y que cuando uno hace hueco para un parámetro, este hueco tiene un tamaño que el programador (o el sistema) ha asignado. Por lo tanto, si lo que va a rellenar ese hueco es más largo que el hueco, y no se ha verificado eso, al copiar el relleno en el hueco se sigue copiando fuera del hueco y se sobreescriben otras cosas, entre ellas la dirección de retorno.

Por lo tanto, cuando esa llamada a función retorna, el sistema lee la dirección de retorno modificada, que ahora apunta a un código malicioso almacenado en el segmento de datos (en donde está el supuesto contenido de la página web), y ejecuta ese código en lugar del que debería haber ejecutado en el segmento de código, lo nos lleva a…

¡¡¡MEEEEEEEEEEEC!!! Entonces, si tenemos un procesador moderno con el bit NX activo, salta la alarma y obtenemos un error de DEP. El programa se detiene automáticamente y nos avisa con un cuadro de diálogo.

Si el DEP salta en el Kernel, bueno, pantalla azul al canto y detención inmediata de todo. ¿Cómo puede saltar en el kernel si todo el código se ejecuta en el Anillo 3 que es el lado usuario? Pues hemos instalado un driver no certificado con regalito, o de alguna manera alguien ha conseguido saltarse todas las seguridades del modo usuario y ha conseguido sobreescribir una pila del Anillo 0. Generalmente esto ocurre pasando parámetros inválidos a llamadas de función del núcleo, y en general a fecha de hoy es bastante difícil que algo así se pueda producir.

9.- Trampa para canarios

Hemos comentado que es posible sobreescribir la pila cuando se devuelven o asignan parámetros en una llamada a función. Lo normal es que cualquier llamada con parámetros de tamaño variable en la pila, verifique que el valor devuelto no sea mayor al hueco recibido. Pero pregúntele usted eso a un programador y verá qué le responde.

Además, siempre estamos usando bibliotecas de terceros para construir nuestros programas, y nadie nos garantiza que el programador haya comprobado todas las posibilidades. Además, a veces es imposible.

Sin embargo, Microsoft lleva ya varios años, primero recomendando y luego obligando, a los programadores a implementar este tipo de seguridad, obligando a pasar el tamaño del buffer junto al buffer, o usando objetos seguros.

La última innovación es colocar una semilla aleatoria ante cada llamada de función al lado de la dirección de retorno, componiendo una especie de “certificado” que garantice que esa dirección no se ha modificado una vez introducida allí.

De momento es el último baluarte ante un fallo de seguridad, y creo que a fecha de hoy la única que lo implementa es Microsoft. Ahora parece que Linux se está poniendo las pilas con el runtime de C, cosa que lleva haciendo Microsoft (y siendo criticada por ello) desde por lo menos el 2010. Y Visual Studio 2015, la última versión de la herramienta de desarrollo de Microsoft que todavía está en fase beta, todavía incrementa más ese nivel de seguridad mediante unas técnicas nuevas que no han terminado de explicar del todo bien y que yo, de momento, tampoco entiendo cómo funcionan.