Se sono corretto, a causa di ASLR, cariciamo libc in qualche indirizzo casuale. E poi, per far sì che ciò avvenga senza consentire permessi di scrittura delle pagine di testo nella memoria, usiamo plt / got. Ora posso semplicemente tornare a una funzione di libc @ plt che è ben nota prima dell'esecuzione del programma e praticamente ignorarla. Quindi return-to-plt rende l'intero concetto inutile?
Sì, se PIE è disabilitato. Si dice spesso che l'efficacia di ASLR è notevolmente ridotto per le applicazioni che non sono compilate con il supporto PIE (Position Independent Code). Quando PIE non viene utilizzato, il programma deve fare affidamento su un fixed PLT , creato durante il collegamento, per risolvere gli indirizzi delle funzioni nelle librerie condivise. Quando viene utilizzato ASLR e PIE è abilitato, gli attacchi di riutilizzo del codice in generale sono attenuati, anche se le infoleaks sono ancora così ubiquitarie che ASLR può essere spesso sconfitto con attacchi sidechannel , rendendolo quasi inutile contro il codice maligno locale e limitando la sua efficacia agli attacchi sulla rete e exploit scriptless . Ci sono molti altri motivi per cui ASLR senza PIE è più debole e perché viene usata meno casualizzazione, poiché è spiegato in un'altra risposta .
tornare a plt e tornare a libc sono attacchi leggermente diversi.
Ritorna a libc
Uno dei modi per prevenire l'overflow del buffer consiste nell'utilizzare uno stack non eseguibile. Per creare stack non eseguibili, da CPU e amp; livello di sistema usano qualcosa chiamato bit NX. Se il bit NX è impostato, quell'indirizzo di memoria non è eseguibile. Anche se eseguiamo un overflow del buffer e sovrascriviamo lo stack per reindirizzare il puntatore di ritorno allo stack in cui risiede il nostro codice shell, il codice shell non verrebbe eseguito perché sarebbe in stack, che è una sezione di memoria non eseguibile.
Questo è il momento in cui usiamo return to libc attack per generare una shell. Invece di usare l'approccio classico per sovrascrivere l'indirizzo di ritorno per l'indirizzo del codice shell, usiamo l'indirizzo della chiamata a libc system ().
Ritorna a PLT
ASLR o randomizzazione del layout di spazio degli indirizzi è un altro metodo per controllare i buffer overflow. Come ho detto nella sezione precedente, le persone ignorano NX trovando gli eseguibili caricati nella memoria da system.like libc. Ciò è stato possibile perché è stato facile identificare la posizione degli eseguibili caricati dal sistema. ASLR ha randomizzato l'indirizzo di questi eseguibili e quindi ridotto la probabilità di generare una shell reindirizzandoli.
Il motivo per cui questo attacco è possibile è che negli eseguibili con librerie collegate dinamicamente l'indirizzo della funzione libc può essere ottenuto da PLT e GOT. L'indirizzo PLT non è casuale e ciò rende l'attacco facile.