PDA

Ver la versión completa : Fallo inentendible de desbordamiento



biyonder
11-09-2009, 13:51
Hola chicos, estoy haciendo pruebas con gcc y gdb en Ubuntu en un código que llama a una función y que declara una cadena de caracteres de 16 bytes (16 letras). El caso es que quiero probar a desbordar la variable y machacar la direccion de retorno de la función a otra parte del código, escribiendo una dirección de dentro del código. El caso es que cuando lo intento me salta un chorro de líneas de que se hubo fallo de segmento y cosas varias de Memory dump. Pero en realidad estoy saltando a una dirección dentro del segmento no?

Un saludo!

PD:Si estoy escribiendo tanto últimamente es porque tenía muchas dudas ene el tintero jaja

j8k6f4v9j
11-09-2009, 19:42
¿Puedes poner el código aquí?


Salu2

biyonder
12-09-2009, 12:35
Si, por supuesto jeje:



#include "milibreria.h"

int check_autethication(char *password){
int auth_f;
char password_buffer[16];

strcpy(password_buffer, password);
if(strcmp(password_buffer, "brillig")==0)
return 1;
else
return 0;
}

int main(int argc, char *argv[]){

if(check_autethication(argv[1])){
printf ("Has conseguido acceder a la zona restringida");
}else
printf ("No puedes entrar aqui");
}

El desbordamiento lo produzco desde la línea de comandos, haciendo uso de perl, y depurando el código veo que una vez llamada a la funcion check_autethication, entre el comienzo de password_buffer y la dirección de retorno hay 24 bytes, con lo cual, miro primero la dirección donde está la instruccion:

printf ("Has conseguido acceder a la zona restringida");

y si la direccion es por ejemplo 0xAAAAAAAA, hago algo tal que así:
user@laptop~#>./programa $(perl -e 'print "\xAA\xAA\xAA\xAA"x10');

pero me da fallo de segmento. Intenté hacer esto mismo en tiempo de depuración pero no sé cómo meter valores hexadecimales en gdb.

----La otra pequeña duda es en estas líneas:

int auth_f;
char password_buffer[16];

según la arquitectura del IA32, las variables se guardan en memoria en orden inverso, es decir, primero password_buffer y luego auth_f(con lo cual podría sobreescribirse por desbordamiento auth_f). El caso es que, ponga las variables en el orden que las ponga, siempre se guarda auth_f encima de password_buffer, haciendo imposible machacar su valor por desbordamiento. Es como un sistema de protección que tiene el compilador. ¿A qué se debe esto?

Gracias, un saludo!

j8k6f4v9j
12-09-2009, 13:59
#include <stdio.h>
#include <string.h>

int check_autethication(char *password){
int auth_f;
char password_buffer[16];

strcpy(password_buffer, password);
if(strcmp(password_buffer, "brillig")==0)
return 1;
else
return 0;
}

int main(int argc, char *argv[]){
if (argc > 1) {
if(check_autethication(argv[1])) printf ("Has conseguido acceder a la zona restringida\n");
else printf ("No puedes entrar aqui\n");
} else printf ("Tienes que introducir un nombre para poder entrar\n");
}

No estabas validando el número de argumentos de entrada, lo que hará que pete el strcpy de check_autethication().

En cuanto al fallo de segmentación, gcc incluye SSP (Stack-Smashing Protector) desde su versión 4.1.
(http://en.wikipedia.org/wiki/Buffer_overflow_protection#GCC_Stack-Smashing_Protector_.28ProPolice.29)


Salu2

biyonder
12-09-2009, 14:34
Si bueno, escribí lo que me acordaba del código, sé que debo ponerlo. Pero ese enlace que me pasaste del GCC 4.X, no lo entiendo muy bien. ¿Es referente a lo de no poder machacar las direcciones de retorno o a la ubicación de las variables locales en la memoria? Un saludo

j8k6f4v9j
12-09-2009, 22:43
Sí.

Reordenación de las variables locales para situar los búferes después de los punteros de forma que se evite la corrupción de punteros que podría ser usada para corromper segmentos de memoria arbitrarios

La copia de punteros en los argumentos de funciones a un area anterior a los búferes de las variables locales para prevenir la corrupción de punteros que podrían ser usada para corromper segmentos de memoria arbitrarios

omisión del código instrumental de algunas funciones para reducir la sobrecarga en el rendimiento.


http://www.trl.ibm.com/projects/security/ssp/