Gli studenti sono scettici sul fatto che spegnere stack non eseguibili, spegnere i canarini e disattivare ASLR rappresenta un ambiente realistico. Se PaX, DEP, W ^ X, ecc. Sono efficaci nell'arrestare gli exploit di overflow del buffer, c'è ancora un valore nell'apprenderli?
Assolutamente. ASLR e DEP sono misure di difesa in profondità. Esistono degli exploit che possono ignorare ciascuno di essi (per un esempio del mondo reale, guarda L'exploit di Pwn2Own di Peter Vreugdenhil che ha usato contro IE ).
Tutto ciò che serve per aggirare ASLR per Windows è una vulnerabilità legata all'intercettazione di informazioni che consente di conoscere l'indirizzo di base di una DLL caricata nel processo (che è stato il primo virus che Vreugdenhil ha sfruttato). Da ciò, puoi utilizzare un attacco ret-to-libc per chiamare qualsiasi funzione in quella DLL.
La linea di fondo: gli overflow dello stack (e dell'heap) sono assolutamente pertinenti ancora oggi. Sono più difficili da sfruttare rispetto a prima, ma sono ancora pertinenti.
Oltre alle eccellenti risposte sintetiche di @ Larry e @ SteveS, voglio sottolineare un punto molto importante:
The students are skeptical that turning off non-executable stacks, turning off canaries and turning off ASLR represents a realistic environment.
Speriamo che questo sia vero per i sistemi dei tuoi studenti.
Nel resto del mondo, tuttavia, questo è ancora molto comune, sfortunatamente. Oltre alle piattaforme che non supportano queste, ci sono sempre prodotti di scarsa qualità che richiedono la chiusura di queste, versioni precedenti del sistema operativo e anche solo cattive configurazioni errate.
Ancora molto realistico, purtroppo.
In cima a tutto, altri 2 commenti di un pov educativo:
1. qualcuno deve costruire quelle difese, giusto?
2. Anche se ipoteticamente avessero ragione - you only need pointers in C/C++ non significa che uno sviluppatore Java non dovrebbe imparare come queste cose funzionano, all'interno del computer, giusto?
Sì. A parte i sistemi in cui gli overflow del buffer portano a exploit di successo, le spiegazioni complete sui buffer overflow sono sempre un ottimo modo per dimostrare come si dovrebbe pensare alla sicurezza. Invece di concentrarti su come l'applicazione dovrebbe funzionare, vedi cosa si può fare per far deragliare l'applicazione.
Inoltre, indipendentemente dall'esecuzione dello stack e dal numero di canarelli urlanti installati, un overflow del buffer è un bug. Tutte queste funzionalità di sicurezza modificano semplicemente le conseguenze del bug: invece di una shell remota, si "ottiene" immediatamente un arresto anomalo dell'applicazione. La mancata attenzione ai crash dell'applicazione (in particolare i crash che possono essere attivati in remoto) è, nella migliore delle ipotesi, una programmazione molto sciatta. Non sul mio orologio!
Per completezza, stack e canarini non eseguibili non impediscono i buffer overflow; hanno semplicemente interrotto alcuni dei semplici modi per sfruttare i buffer overflow. Il tradizionale overflow del buffer consiste nel sostituire l'indirizzo di ritorno con un puntatore a codice dannoso che viene caricato come parte dei dati che hanno superato il buffer; il codice dannoso viene eseguito quando la funzione ritorna. Lo stack non eseguibile significa che l'attaccante non sarà in grado di posizionare il suo codice nello stack (dovrà organizzare un salto in qualche codice di libreria, ad esempio l'implementazione execve() nella libreria standard). Il canarino impedisce l'uso dell'indirizzo di ritorno se uno stack buffer è stato overflow (supponendo che l'overflow sia "semplice": una porzione contigua di dati). Ma l'overflow potrebbe anche sovrascrivere altri dati, inclusi i puntatori di funzione (in particolare nel contesto di C ++).
Assolutamente. Non dovrebbe essere sufficiente sapere che queste sono soluzioni al problema, dovrebbero sapere come e perché sono soluzioni al problema.
Inoltre, non tutte le piattaforme supportano queste tecnologie.
Ci sono già ottime risposte qui, quindi non cercherò di ricopiarle. Tuttavia, dal momento che stiamo parlando di meccanismi che impediscono l'overflow del buffer, vorrei sottolineare qualcosa che vorresti trasmettere ai tuoi studenti:
Solo perché un programma è scritto in Java non significa che non ci sono buffer overflow. La Java Virtual Machine stessa non è implementata in Java; è implementato in (probabilmente) C o C ++, che sono altrettanto inclini a bufferare gli overflow come qualsiasi altro programma.
Inoltre, ci sono molte implementazioni della JVM . Per tutti quelli che risolvi, ce ne sono altri dieci che sono probabilmente ancora vulnerabili.
Spero di non aver appena fatto il giro della mia scatola di sapone ....: -)
Mi piacerebbe rispondere dal punto di vista di uno studente che ha recentemente iniziato a conoscere approfonditamente gli attacchi di overflow del buffer. Anch'io ho avuto le stesse preoccupazioni e ho avuto dubbi sui vantaggi dell'apprendimento sugli attacchi di overflow del buffer, ma considerando quanto ho imparato ad usarlo, sono molto contento di aver scelto di farlo.
Finora ho dovuto:
Queste abilità sono molto trasferibili e non ho rimpianti. Sfortunatamente, non ho qualcuno che mi insegni questo. Ho dovuto risolvere il problema con video tutorial e codici di esempio per il progetto del mio Master. Gli attacchi di overflow del buffer possono essere meno preoccupanti per la sicurezza IT rispetto a 5-10 anni fa, ma possono sicuramente servire come trampolino di lancio per conoscere le minacce più complesse o attuali.
No, non insegnare overflow del buffer. Insegna la corruzione della memoria. Insegna ai primitivi dello sfruttamento. Sì, hanno anche bisogno di conoscere la storia, ma non dovrebbero occupare più della metà della classe. Dico quando si tratta di compiti veri, dare loro sfide che hanno tutte le protezioni della memoria abilitate, ma forse rendere il server vulnerabile più debole, con alcune rivelazioni di memoria che danno suggerimenti su vari offset.
Devono anche capire che molte protezioni di memoria sono per lo più espedienti e spesso le "correzioni casuali" non sono così casuali come si potrebbe pensare. Dovrebbero imparare a riconoscere i bug e usare i bug che hanno per colpire le cose che conoscono, in modo che possano arrivare alle cose che vogliono.
Dovrebbero pensare in termini di sovrascrittura dei puntatori di funzione piuttosto che degli indirizzi di ritorno e saltare nel codice eseguibile noto (ret2libc, ROP) piuttosto che saltare nello shellcode / stack.
Essendo uno studente universitario appena uscito da un corso di c ++, sì, so che non è lo stesso ..., ma il mio professore ha fatto in modo di dare maggiore enfasi sull'insegnamento dei buffer overflow e su come prevenirli, e ti incoraggio davvero a continua a insegnare su buffer overflow in qualsiasi corso tu insegni a programmare. Non può nuocergli a farlo.
Leggi altre domande sui tag source-code attacks user-education appsec buffer-overflow