Ho preso in considerazione il problema fondamentale dello stack overflow, dalla classica iniezione di codice shell che non funziona con NX bit al nuovo gadget ROP.
La prima domanda che ho avuto riguarda le CPU con registri di diramazione. Sembra che fare uno qualsiasi di questi tipi di attacchi su una CPU che tiene traccia di rami in uno "stack" di registri di diramazione, come ad esempio Itanium, sarebbe difficile se possibile. Ovviamente ci sono altri attacchi che non richiedono la sovrascrittura dell'IP di ritorno, ma la combinazione di registri di diramazione e bit NX non preclude un'enorme quantità di attacchi? In questo caso, perché le persone non considerano l'utilizzo di architetture di processori che utilizzano registri di diramazione per i propri dispositivi periferici?
Come domanda successiva, perché Intel / AMD non introduce una modalità operativa in cui la serie di istruzioni CALL / RET viene verificata e applicata? Sembra che il vero problema sia che la CPU lascia il tracking degli IP di ritorno nella cura del processo, in pila. Sarebbe una pessima interruzione di compatibilità semplicemente non spingere l'IP di ritorno nello stack, o persino spingere qualche valore casuale, ma perché non offrire una modalità in cui la CPU su CALL spinge l'IP di ritorno nello stack AND su una CPU backing store gestito per questo processo / thread / contesto. Queste pagine sarebbero totalmente off limits per il processo tranne attraverso CALL e RET. Quando viene eseguito RET, l'indirizzo prelevato dallo stack viene confrontato con l'indirizzo nella memoria secondaria e, se non sono uguali, si interrompono. Ovviamente questo sarebbe più lento, ma per le parti di applicazioni sensibili alla sicurezza, come quelle che gestiscono input esterni, l'applicazione potrebbe impostare il flag / modalità sicura scegliendo di sacrificare le prestazioni per la sicurezza.
Questo concetto ha senso? In realtà attenuerebbe gli attacchi orientati all'IP di ritorno?