SEH sovrascrive i dettagli di attacco

1. Il gestore delle eccezioni non controlla l'integrità dei canarini poiché il codice di controllo è chiamato solo quando la funzione termina. L'utente malintenzionato dovrebbe assicurarsi che prima che il programma raggiunga quel codice, dovrebbe essere lanciata un'eccezione!

2. Senza ulteriori protezioni, il programma continua a eseguire un gestore di eccezioni manipolato perché non sa che è malformato.

3. Il danneggiamento di un canarino non innesca un'eccezione, il programma non saprà che il canarino è cambiato fino al controllo di integrità. Traboccando un buffer, d'altra parte, MIGHT innesca un'eccezione (se, ad esempio, l'autore dell'attacco supera un puntatore e lo indirizza a un'area illeggibile / non scrivibile e quindi tenta di leggere / scrivere con quel puntatore).

4. Supponendo che lo shellcode sia nello stack, non inseriamo l'indirizzo dello shellcode nell'indirizzo del gestore delle eccezioni perché Windows ha un meccanismo di base di difesa che impedisce alle eccezioni di saltare agli indirizzi nello stack. SEH è stato abusato comunemente e ripetutamente, e quindi è stato creato. Pertanto, usiamo pop, pop, ret perché possiamo facilmente trovare questo codice nel segmento di testo (un'area in cui il gestore di eccezioni PU jump passare).

5. Per maggiori dettagli sulle tecniche di mitigazione, leggi:

   • SafeSEH che definisce gli indirizzi esatti che consentono alle eccezioni di passare a loro.
   • SEHOP che verifica l'integrità dell'elenco di gestori di eccezioni.

Ho anche chiesto una domanda sull'argomento, potresti dare un'occhiata a it