Direcciones conectadas entre sí y relativas en shellcode

3

Esta pregunta se encuentra principalmente en el contexto de la ejecución de comandos arbitrarios en un desbordamiento de búfer (por ejemplo, una pila).

Recientemente leí en algún lugar que las direcciones cableadas (absolutas) no son buenas para shellcode, por ejemplo. usando / bin / sh por ejemplo. El problema es que significa que el código no es independiente de la posición.

Sin embargo, no entiendo por qué las direcciones cableadas no serían preferibles a las relativas. ¿Las direcciones cableadas no significarían que las bibliotecas / llamadas deseadas utilizadas en el ataque sean accesibles desde donde sea que se encuentre el código (es decir, es independiente de la posición) donde las direcciones relativas significan que el código debe estar en el lugar correcto en relación con la llamada? / p>     

pregunta Sean Frötkék 18.05.2017 - 11:58
fuente

2 respuestas

1

Las direcciones relativas siempre tendrán una ventaja sobre las codificadas, ¿por qué? déjame explicarte:

  • Digamos que ejecuta la aplicación nuevamente después de salir o reiniciar, puede que no se carguen en las mismas direcciones en la memoria
  • ASLR - Distribución aleatoria del diseño del espacio de direcciones: una característica de seguridad en Sistemas OS que nunca cargarán el ejecutable en el mismo espacio ... esto significará que las direcciones serán diferentes cada vez, por lo tanto, las direcciones codificadas no funcionarán y tendrá que cambiarlo Cada vez que es realmente cojo y solo funciona.
  • Diga, desea saltar a una dirección específica, en lugar de jmp [dirección] Siempre sería bueno estar relacionado con algún registro como jmp ecx + 8 y esto no cambiará incluso si las direcciones cambian.
respondido por el Nipun Jaswal 18.05.2017 - 12:27
fuente
1

Hay dos tipos de problemas que creo que podrías estar confundiendo. Una es la dirección de las funciones a las que llama su código de shell que proporciona la aplicación vulnerable o las bibliotecas cargadas, y la otra es saltos absolutos frente a los saltos relativos dentro de su código de cáscara.

Llamadas de biblioteca

Supongamos, por un segundo, que está intentando un exploit de estilo de retorno a libc en un simple binario. Así que quieres la dirección de system para muchas de estas hazañas. Construyamos un pequeño binario que imprima la dirección de system .

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
  printf("system @%p\n", system);
  return 0;
}

Compila y ejecuta esto varias veces:

% gcc -o getsystem getsystem.c
% ./getsystem
system @0x7fdc54419d40
% ./getsystem
system @0x7fbc15b61d40
% ./getsystem
system @0x7fbeacfb6d40

Observe que cada vez que se ejecuta, la dirección de system ha cambiado. Esto se debe a una mitigación de seguridad moderna llamada ASLR: la biblioteca C se carga en una dirección base diferente, por lo que system se cargará en una dirección diferente. En consecuencia, su código de shell debe ubicar primero libc, luego llamar a system en una dirección relativa al inicio de la biblioteca. (Llamada la "dirección base").

Saltos

En shellcode más complejo, es posible que necesites hacer un jmp o call dentro de la propia carga útil. En tales casos, usted debe tener saltos y llamadas relativas, porque no sabe la dirección exacta donde se cargará su código de shell. En lugar de decir "saltar a 0x0804abcd ", debería tener "saltar 5 bytes hacia adelante". Esto es lo que se entiende por "Código independiente de la posición": puede funcionar cuando se carga en cualquier posición, y no solo en una dirección de inicio fija.

Debido a que Shellcode generalmente se carga en la pila o en el montón, los cuales están sujetos a varias manipulaciones (ASLR, otros datos que usan la pila / pila, subprocesos, etc.), es imposible predecir una dirección absoluta donde su Shellcode tierra.

    
respondido por el David 13.01.2018 - 23:07
fuente

Lea otras preguntas en las etiquetas