Mi chiedevo perché archiviare l'intero programma in ROM non impedisca gli attacchi di overflow del buffer e return-to-libc?
Il codice è ancora caricato in RAM prima dell'esecuzione che lo rende vulnerabile all'attacco del flusso di controllo? (se questo è il caso, perché le pagine di codice non sono contrassegnate come di sola lettura da MMU?)
Oup, ci sono diversi punti nella tua domanda ...
Perché il codice per libc di altri programmi non è memorizzato nella ROM?
Per definizione la ROM è di sola lettura, ciò significa che sarebbe impossibile aggiornare libc né alcun programma se è stato memorizzato nella ROM
Perché le code page non sono contrassegnate come di sola lettura a livello MMU?
Loro sono contrassegnati come di sola lettura. Sfortunatamente non ha senso contro gli attacchi buffer-overflow, return-to-libc
Che cosa rende possibili questi attacchi?
L'indirizzo di ritorno non è memorizzato nel codice, ma nello stack. Tutte le lingue correnti (Fortran 4 ... oltre la metà degli anni '60) memorizzano anche le variabili locali nello stack per consentire il multithreading e la ricorsione. Ciò significa che un programma non ha una protezione speciale per lo stack e se si esegue il overflow di un buffer locale, si potrebbe teoricamente riscrivere l'indirizzo di ritorno e in quel modo eseguire codice arbitrario di libc.
È necessario notare che la maggior parte dei compilatori attuali implementano speciali protezioni dello stack per mitigare tali minacce.
La sezione di testo dei file eseguibili (dove risiede il tuo codice) deve essere contrassegnata come eseguibile. Non sei in grado di eseguire nessuna delle istruzioni nel tuo codice altrimenti.
Esistono mitigazioni di riutilizzo del codice (ROP) e puoi trovare ulteriori informazioni sull'implementazione di grsec su: link
Leggi altre domande sui tag buffer-overflow