SEH sobrescribe los detalles del ataque

1. El controlador de excepciones no verifica la integridad de los canarios, ya que solo se llama al código de verificación cuando la función termina. El atacante debería asegurarse de que antes de que el programa llegue a ese código, ¡se debe lanzar una excepción!

2. Sin más protecciones, el programa continúa ejecutando un controlador de excepciones manipulado porque no sabe que está mal formado.

3. La corrupción de un canario no activará una excepción, el programa no sabrá que el canario ha cambiado hasta que se verifique la integridad. Desbordando un búfer, por otro lado, MIGHT desencadena una excepción (si, por ejemplo, el atacante supera un puntero y lo señala a un área que es ilegible / no se puede escribir y luego intenta leer / escribir con ese puntero).

4. 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 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. Por lo tanto, usamos pop, pop, ret porque podemos encontrar fácilmente este código en el segmento de texto (un área en la que el controlador de excepciones PUEDE saltar).

5. Para obtener más detalles sobre las técnicas de mitigación, lea acerca de:

   • SafeSEH que define las direcciones exactas que permiten a las excepciones saltar a ellas.
   • SEHOP que verifica la integridad de la lista de manejadores de excepciones.

También hice una pregunta sobre el tema, es posible que desee echar un vistazo a lo