¿Cómo se usan los desbordamientos de buffer para explotar las computadoras?

Question

¿Cómo se usan buffer overflows para explotar las computadoras?

¿Cómo se puede ejecutar código arbitrario simplemente causando desbordamientos stack o heap?

Entiendo que las partes de la memoria de programas se sobrescriben, pero no veo cómo esto lleva a uno a ejecutar su propio código. Además, ¿el código malicioso de terceros debe escribirse en el lenguaje ensamblador de procesadores de destino?

Answer 1

Este es el documento más ampliamente conocido sobre el tema: Smashing the Stack for Fun and Profit

Sin embargo, '' desbordamientos de pila no tienen nada que ver con desbordamientos de búfer. Los desbordamientos de pila generalmente son solo un caso de error en el código incorrecto que no puede explotarse para nada fuera de un bloqueo (DoS).

Editar: También ha preguntado acerca de los desbordamientos de pila. Este es un buen documento sobre el tema: http://www.w00w00.org/files/articles/heaptut.txt

Answer 2

La pila contiene datos y dirección de retorno cuando se salta a una subrutina. Si logras poner una dirección específica en la pila donde está la dirección de retorno, puedes forzar a la CPU a saltar a una ubicación de memoria particular, en la que colocas tu propio código. Eso es para desbordamientos de búfer. El desbordamiento del montón es un poco diferente y más difícil de explotar.

Los desbordamientos de pila son solo una indicación de que se ha agotado el espacio de pila (que generalmente es más limitado, especialmente en el kernel).

Answer 3

El enfoque normal es que tiene un lugar en la memoria del código malicioso. Luego, crea un desbordamiento de búfer: la magia aquí no es hacerlo simplemente desbordamiento, pero como ya lo mencionó, ciertas partes de la memoria del programa se sobrescriben. Como la pila contiene no solo las variables, sino también cuando una función se llama dirección de retorno, se intenta sobrescribir esta con la dirección de su código malicioso. Cuando la función con el desbordamiento del búfer vuelve a su llamador, la función no vuelve a su llamador original sino a la subrutina maliciosa. Como el código ahora ejecutado tiene usualmente los privilegios del código de llamada, uno trata de encontrar/crear estos desbordamientos en el código que tiene un permiso más alto que el código maligno (de lo contrario, puede hacerlo llamando directamente a la rutina del mal).

Answer 4

Prácticamente todos los procesadores modernos al llamar a una subrutina, empuja la dirección de retorno en la misma área que los datos locales (pila). Para las rutinas que no verifican el límite superior de una variable (en particular, la función strcpy), puede producirse una redirección de direcciones de instrucción (desbordamiento de búfer).

void make(char *me) 
{ 
    char sandwich[4]; // local data, this is in stack. the buffer for data is too small 
    strcpy(sandwich, me); 
    puts(sandwich); 

    // implicit "return;" the return instruction(RET on Intel) instructs the processor to implicitly pop an address from stack then resume execution on that address 
} 

void main() 
{ 
    // calling a subroutine (CALL on Intel) implicitly instructs the processor to push the next instruction's address(getchar line) on stack before jumping to make. 
    make("Love Not War"); 
    getchar(); 

    puts("This will not execute. The address to next instruction(getchar) gets overwritten with Not War"); 

} 

"Además, ¿el código malicioso de la tercera parte debe estar escrito en el lenguaje ensamblador de procesadores de destino?" Sí

El desbordamiento de la pila puede ocurrir por un programa que se esté ejecutando normalmente, por ejemplo, las rutinas recursivas (función que se llama a sí misma) con una condición de terminación ignorada. El área de pila se llenará con numerosas variables locales en la pila más las direcciones de retorno.

Answer 5

Imagine dos casas en la calle. Una es la casa de tu amigo y otra es la casa de su malvado vecino paranoico tres puertas más abajo. El vecino paranoico malvado nunca entra o sale, y su lugar está cerrado con llave.

Ahora, su amigo es un amigo tan bueno y confiable, que le permitirá almacenar cualquier cosa en su lugar, colocando cajas una tras otra, comenzando en una pared. De hecho, es tan buen amigo que va a seguir poniendo cajas una tras otra, sin verificar si golpeó la pared, hasta que se mantienen en el aire y finalmente pasan a través de otras dos casas en la calle y hacia adentro. la casa del vecino paranoico malvado. Pero tu amigo confía en que no harás eso porque le gustas (y es un poco ingenuo).

Así que tienes la oportunidad de poner algo en la casa del vecino malvado paranoico explotando a tu amigo de confianza.

---

Reemplazar los siguientes términos y verá la analogía a un ataque de desbordamiento de búfer:

• "casa de un amigo" -> "una parte de un programa que no se compruebe desbordamiento de búfer "
• " la casa de su vecino paranoico malvado "->" otra parte de un programa que se supone que es seguro "
• " boxes "->" argumentos/parámetros para el programa que no verifica para desbordamiento de búfer "

Esto solo tiene éxito si alguien descubre dónde está el área segura de la memoria, y qué tendría que pasar como argumento para el programa en cuestión, que terminaría en el área segura, para tener el efecto deseado . (si se trata de datos, o código que hace que se ejecute el código del explotador)