Cl\u00e1sico de los cl\u00e1sicos donde los haya, y todav\u00eda totalmente en vigencia.<\/p>\n

Mediante esta vulnerabilidad alguien puede llegar a ejecutar el c\u00f3digo que quiera insertando en ciertas partes de la memoria. Vaaaleeee, esto es complicado! \u00bfQui\u00e9n narices va a hacer esto? \u00bfMr. Robot? Pues no. Dejando la teor\u00eda aparte vamos a ver un ejemplo que nos va a poner los pelos de punta, porque vamos empezar a pensar que no tenemos ni idea de cu\u00e1ntos de estos agujeros podemos tener.<\/p>\n

[code language=”c”]
\n#include <stdio.h>
\n#include <strings.h><\/p>\n

int main(int argc, char *argv[]){
\nint puede_pasar = 0;
\nchar password[12];
\nchar passwordGuardado[12] = "SIoNOoES";
\ngets (password);
\nif (strncmp(password, passwordGuardado, 6) == 0){
\npuede_pasar = 1;
\n}
\nif (puede_pasar == 0){
\nprintf("Ehhhh!! \u00bfque haces tu aqui?");
\n} else {
\nprintf("Yeah!!! Hola megasuperUsuario!");
\n}
\n[\/code]<\/p>\n

Estudiemos un poco el c\u00f3digo muy simple, escrito en C. Se trata de una funci\u00f3n, t\u00edpica que recibe par\u00e1metros, compara el password recibido con el password que tiene guardado en el codigo, si coinciden saluda al usuario.<\/p>\n

Nos puede parece que el mayor error es el guardar el password a hierro en el codigo, y la verdad es que no es muy elegante, pero no es el mayor problema. El problema m\u00e1s grande y el agujero que se usa para ejecutar c\u00f3digo malicioso en el sistema es que NO COMPROBAMOS LA LONGITUD DE LA VARIABLE INTRODUCIDA.<\/p>\n

Ahora vamos a ver porque: <\/strong><\/p>\n

Para empezar, diremos que el valor de todas las variables que aparecen se guardan en una zona de la memoria llamada Stack.<\/p>\n

Lo primero que hacemos es guardar el valor “SIoNOoES”<\/em> en la variable passwordGuardado<\/em>, es decir, en el Stack.<\/p>\n

La funci\u00f3n gets<\/em>, lee una cadena que entra el usuario y guarda el valor en la variable password<\/em>, tamb\u00eden en el Stack.<\/p>\n

la funci\u00f3n strncmp<\/em> compara dos strings, en un principio el password que tenemos guardado con el password que ha entrado el usuario, pero realmente compara el contenido de las dos zonas de memoria del stack que ocupan las variables password<\/em> y passwordGuardado<\/em>. Si el contenido es el mismo nos devolver\u00e1 un 0.<\/p>\n

Si las variables son iguales, asignamos un 1 a la variables que nos indica que podemos pasar y saludamos el usuario. Como no pod\u00eda ser de otra manera la variable puede_pasar<\/em>, tambi\u00e9n est\u00e1 en el stack.<\/p>\n

\u00bfQue problema hay?<\/strong><\/p>\n

Bueno, dejando de lado los obvios, como guardar el password (que no se hace nunca) y encima en el codigo, (que eso si que no se hace nunca), hay otro problema un poco mas escondido (aunque tampoco demasiado) un problema de Overflow:<\/p>\n

Casi cualquier password que demos con una longitud mayor de 12 ser\u00e1 v\u00e1lido. El programa intenta guardar el valor de lo introducido en el usuario en la variable password<\/em>, pero en esta variable no cabe todo lo que ponemos, as\u00ed que ni corto ni perezoso contin\u00faa ocupando memoria que no le pertenece, y en este caso la memoria de la variable puede_pasar<\/em>. Es decir, la variable puede_pasar<\/em> tiene asignada una direcci\u00f3n de memoria en el stack, a la que le hemos puesto un 0 al inicio del programa. Pero este valor es sustituido por los caracteres que le sobran a password<\/em>. Como el valor de puede_pasar<\/em> ya no ser\u00e1 un 0, el programa le da la bienvenida al megaSuperUsuario.<\/p>\n

<\/picture>