Soy nuevo en explotaciones basadas en el manejo de excepciones estructuradas.
¿Por qué no ponemos nuestra dirección de devolución directamente en el controlador SE para saltar a nuestro código de shell? (sin SEH seguro)
¿Alguien puede explicar la razón del uso de pop pop ret?
Leí algo que decía que SEH pasa por alto ASLR y DEP, pero ¿cómo?
Nuestro shellcode estará ubicado en la pila y, dado que la pila seguirá siendo no ejecutable, ¿cómo se omite el DEP?
Usar SEH para lograr derrotas de explotación, ni DEP ni ASLR.
En particular, DEP mitigará la ejecución del código de shell fuera de la página de memoria de la pila que, en última instancia, fue lo que un exploit basado en SEH está tratando de lograr.
Sin un módulo que no sea ASLR en el espaciado del proceso que se utiliza para ubicar la clave de explotaciones de SEH POP POP RET , ASLR permanece para impedir aún más la explotación.
Como sugirió Van Jone en su comentario, ROP (y una filtración de información para el descubrimiento de la dirección base del módulo) son necesarios para la derrota de DEP y ASLR.
Suponiendo que el código de shell está en la pila, no colocamos la dirección del código de shell en la dirección del controlador de excepciones (lo que llamó "dirección de retorno") porque Windows tiene un mecanismo de defensa básico que evita que las excepciones salten a direcciones en la pila. SEH fue abusada comúnmente y repetidamente, y así fue creada. Hoy en día, SafeSEH define las direcciones exactas que permiten que las excepciones salten a ellas y, por lo tanto, con SafeSEH el ataque no funcionará.
Usamos pop, pop, ret porque podemos encontrar fácilmente este código en el segmento de texto. Como expliqué anteriormente, no podemos saltar a la dirección en la pila, pero podemos saltar al segmento de Texto. pop, pop, ret salta a la dirección del siguiente registro de SEH, ya que en el momento en que el controlador de excepciones comienza a ejecutarse, ESP está a 8 bytes. Tenga en cuenta que controlamos este valor.
En winDBG:
0:000> !exchain
*0012ffb0*: seh_overflow!ILT+85(__except_handler4)+0 (0041105a)
0012ffe0: kernel32!ValidateLocale+2b0 (7c839ac0)
Invalid exception stack at ffffffff
0:000> g
(614.f68): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
:
0:000> dd esp L4
0012f6f8 7c9032a8 0012f7e0 *0012ffb0* 0012f7fc
También hice una pregunta sobre el tema, es posible que desee echar un vistazo a lo
Lea otras preguntas en las etiquetas exploit buffer-overflow aslr dep