A menudo se muestra que es posible pasar por alto los datos no ejecutables mediante ataques de retorno a libc. Es evidente en /bin/sh , pero ¿también es posible invocar un shell remoto?
Las partes universales de un exploit a menudo se llaman "código de shell" porque generalmente hacen exactamente eso: inician un proceso de shell y conectan stdin / stdout a un socket de red.
Este documento puede ser interesante:
Para demostrarlo, realizamos un ataque de retorno a libc de fuerza bruta en la red contra un servidor concurrente de pre-forking para obtener acceso remoto a un shell.
Claro que es posible! ¿Qué pasa con una llamada a system() ? Es posible que la pila en sí no sea ejecutable, pero aún contiene los argumentos y, por lo tanto, se puede hacer cualquier cosa siempre que el proceso explotado se ejecute con los privilegios necesarios.
Creo que si tengo este derecho, estás preguntando:
"¿Cuál es la diferencia entre un retorno a un ataque libc frente a un desbordamiento de búfer estándar y es una vulnerabilidad que implica invocar un shell remoto aún posible?"
La diferencia es sutil. Primero echemos un vistazo a la pila. Avid va a amar este pedazo de código:
int insecure_function(char* source)
{
char buffer[200];
memcpy(buffer, source, strlen(source));
Que es claramente vulnerable a un desbordamiento de búfer. La pila para esta función debería verse así:
Low Address High Address
char buffer --------------------------------- | ret address | char* source
some data 200 sizeof(char)'s long | 0x134543344 | 0x4374234294
Ahora, un desbordamiento de búfer tradicional te permite hacer esto:
Low Address High Address
char buffer --------------------------------- | ret address | char* source
Shell code here ---------- then some padding --- 0x999999999 | 0x4374234294
/\ |
|| |
--------- < the address points to here < -------------
Este es un ejemplo muy simple: sobrescribe la dirección de retorno para que apunte a tu pila. En la práctica eso es bastante difícil, así que terminas usando un NOP Sled que es equivalente a "apuntar en el lugar correcto ".
Por supuesto, todo esto se anula si esa área de pila no es ejecutable porque el procesador no ejecutará esas instrucciones. Excelente!
Bueno, no del todo. No podemos obtener el código de shell propio en la memoria para ejecutar, pero afortunadamente hay muchas bibliotecas en código que harán prácticamente cualquier llamada al sistema. Técnicamente, podríamos elegir cualquier función que nos gustara, por completo, pero la opción más obvia es libc , ya que proporciona todo tipo de funciones. Como abrir conchas. Entonces, en este caso, lo que hacemos es proporcionar nuestro propio marco de pila y dirección de retorno a esa función:
Low Address High Address
char buffer --------------------------------- | ret address | char* source
Arguments - libc uses these! | 0x011010101 | 0x4374234294
|
< off to libc we go ----------------------
Cuando llegamos a libc, el marco de la pila se configura con los argumentos que necesita la función, por lo que podemos hacer cualquier cosa que la función que hemos elegido pueda hacer, por ejemplo. inicie una instancia de /bin/sh con IO redirigido a donde queramos.
Esto es claramente bastante difícil y depende de muchas cosas. ¿Qué tan grande es el búfer? ¿Se manipula después del desbordamiento del búfer (sobrescribiendo sus argumentos)? ¿Te importa que el proceso objetivo (el que se acaba de apilar) se quede arriba o no? Hay muchos problemas en la práctica, pero teóricamente se puede hacer.
Lea otras preguntas en las etiquetas operating-systems exploit buffer-overflow