Domanda:
Dovrei preoccuparmi ancora di insegnare il buffer overflow?
Fixee
2011-03-01 09:42:06 UTC
view on stackexchange narkive permalink

Gli studenti sono scettici sul fatto che disattivare gli stack non eseguibili, disattivare i canarini e disattivare ASLR rappresenti un ambiente realistico. Se PaX, DEP, W ^ X e così via sono efficaci per fermare gli exploit del buffer overflow, c'è ancora valore nell'apprenderli?

@Fixee Sarò brutalmente onesto qui, se davvero metti in dubbio l'idea di insegnare i buffer overflow, non credo che dovresti "insegnare" a una classe sulla sicurezza. Considerando che sono uno degli exploit di sicurezza più basilari e universali, i buffer overflow dovrebbero essere parte integrante della comprensione e dell'insegnamento come attaccare QUALSIASI sistema.
@mrnap Insegno overflow del buffer e scrittura di shellcode da 13 anni. Come la maggior parte delle persone nell'arena della sicurezza sa, questa era una volta la vulnerabilità n. 1 (5-10 anni fa) e da allora è stata soppiantata da altre vulnerabilità. Ho posto la domanda sopra per sondare i professionisti sul valore continuo dell'insegnamento di queste tecniche (che richiede molto tempo) quando altri argomenti stanno diventando più rilevanti. Mi critichi anche per aver fatto la domanda: credimi, se non metto costantemente in discussione l'impatto di ciò che insegno, allora non sto facendo il mio lavoro.
@Fixee Capisco il tuo punto, ma penso ancora al mio punto originale che sono un aspetto fondamentale degli stand di sfruttamento. Chiunque sia aggiornato e legga qualsiasi cosa sul settore o comprenda la sicurezza in modo fondamentale capisce che i BOs esisteranno finché esisterà una cattiva codifica. Penso che dalla cacofonia di Sì 'seguire questo sarebbe abbastanza evidente.
@mrnap Abbiamo 10 settimane per tenere un corso di sicurezza
@mrnap, se la risposta chiara è un clamoroso "SÌ" o no, è * sempre * una domanda legittima da porre. In effetti, qualcuno che * non * mette costantemente in discussione l'attuale saggezza convenzionale è quello che non dovrebbe tenere un corso sulla sicurezza. Come tutti sappiamo, mettere in discussione le ipotesi è uno dei migliori strumenti nella nostra cassetta degli attrezzi e il più delle volte porta alla scoperta di vulnerabilità.
@avid ha detto bene! @mrnap, si prega di notare anche l'ottimo consiglio nelle nostre faq: * Sii gentile. Tratta gli altri con lo stesso rispetto con cui vorresti che trattassero te. * :)
Da quando il sistema operativo della tua auto utilizza PaX?Quando è stata l'ultima volta che hai visto un firmware NIC con W ^ X?Hai mai visto un router MIPS32 con DEP?Sebbene desktop e server di grandi dimensioni possano avere queste protezioni, ** non tutti i dispositivi moderni lo fanno. **
Otto risposte:
ReinstateMonica Larry Osterman
2011-03-01 12:47:53 UTC
view on stackexchange narkive permalink

Assolutamente. ASLR e DEP sono misure di difesa in profondità. Esistono exploit che possono aggirare ciascuno di essi (per un esempio reale, guarda l'exploit Pwn2Own di Peter Vreugdenhil che ha usato contro IE).

Tutto ciò che serve bypass ASLR per Windows è una vulnerabilità di divulgazione di informazioni che ti consentirà di conoscere l'indirizzo di base di una DLL caricata nel processo (questa è stata la prima vuln che Vreugdenhil ha sfruttato). Da questo, puoi usare un attacco ret-to-libc per chiamare qualsiasi funzione in quella DLL.

La linea di fondo: gli overflow di stack (e heap) sono ancora assolutamente rilevanti oggi. Sono più difficili da sfruttare rispetto al passato, ma sono comunque rilevanti.

Per completare, in alcuni contesti specifici i buffer overflow possono essere più facili da sfruttare a causa di [perdite di layout della memoria, ad es. nei kernel] (http://security.stackexchange.com/questions/69054/does-kaslr-really-provide-more-security-against-exploits). Heartbleed è stato anche causato da un buffer overflow, e questo accadrà di nuovo perché scriviamo ancora e continueremo a scrivere codice di basso livello per interfacce hardware e librerie OS ...
AviD
2011-03-01 17:58:13 UTC
view on stackexchange narkive permalink

Oltre alle eccellenti risposte concise di @ Larry e @ SteveS, desidero sottolineare un punto molto importante:

Gli studenti sono scettici sul fatto che disattivare stack non eseguibili, disattivare canarini e trasformare off ASLR rappresenta un ambiente realistico.

Si spera 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 li supportano, ci sono sempre prodotti di scarsa qualità che richiedono la disattivazione, versioni precedenti del sistema operativo e anche solo cattive configurazioni errate.
Ancora molto realistico, purtroppo.

Oltre a tutto ciò, altri 2 commenti da un punto di vista educativo:
1. qualcuno deve costruire quelle difese, giusto?
2. Anche se ipoteticamente avessero ragione - hai solo bisogno di puntatori in C / C ++ non significa che uno sviluppatore Java non dovrebbe imparare come funzionano queste cose, all'interno del computer, giusto?

+1 per # 2. Sicuramente un'aggiunta tanto necessaria.
Thomas Pornin
2011-03-01 18:30:03 UTC
view on stackexchange narkive permalink

Sì. A parte i sistemi in cui i buffer overflow portano a exploit di successo, le spiegazioni complete sui buffer overflow sono sempre un ottimo modo per dimostrare come dovresti pensare alla sicurezza. Invece di concentrarti su come dovrebbe funzionare l'applicazione, guarda cosa si può fare per far deragliare l'applicazione.

Inoltre, indipendentemente dall'esecuzione dello stack e dal numero di canarini urlanti che installi, un buffer overflow è un bug . Tutte queste funzionalità di sicurezza alterano semplicemente le conseguenze del bug: invece di una shell remota, "semplicemente" si ottiene un arresto anomalo dell'applicazione. Non preoccuparsi dei crash delle applicazioni (in particolare i crash che possono essere attivati ​​da remoto) è, nella migliore delle ipotesi, una programmazione molto sciatta. Non sul mio orologio!

Per completezza, stack e canarini non eseguibili non prevengono i buffer overflow; hanno semplicemente disattivato alcuni dei modi semplici 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à predisporre un salto in un codice di libreria, ad esempio l'implementazione di execve () nella libreria standard ). Il canary impedisce che l'indirizzo di ritorno venga utilizzato se un buffer dello stack è stato sovraccaricato (supponendo che l'overflow sia "semplice": un blocco di dati contiguo). Ma l'overflow può anche sovrascrivere alcuni altri dati, inclusi i puntatori a funzione (in particolare nel contesto di C ++).

Ottimo post, pochi punti extra: 1. Le persone devono imparare a scrivere codice con meno bug, non fare affidamento ciecamente su mitigazioni (come l'autore ha correttamente indicato, i buffer overflow basati sullo stack non sono stati eliminati, ma solo resi più difficili). 2. Come dovrebbero capire cosa fanno DEP, ASLR, se non capiscono gli attacchi che hanno reso necessarie queste protezioni in primo luogo? 3. La ricerca di bug li rende un programmatore migliore, poiché si fidano di meno di se stessi e del sistema, quindi prestano attenzione ai comportamenti che si verificano non solo quando le cose funzionano correttamente, ma anche quando vanno male.
Steve
2011-03-01 11:11:43 UTC
view on stackexchange narkive permalink

Assolutamente. Non dovrebbe essere sufficiente che sappiano che queste sono soluzioni al problema, dovrebbero sapere come e perché sono soluzioni al problema.

Inoltre, non tutte le piattaforme supportano queste tecnologie.

Jeremy Powell
2011-04-09 10:14:56 UTC
view on stackexchange narkive permalink

Ci sono già ottime risposte qui, quindi non cercherò di ricoprirle di nuovo. Tuttavia, poiché stiamo parlando di meccanismi che impediscono l'overflow del buffer, vorrei sottolineare qualcosa che potresti voler trasmettere ai tuoi studenti:

Solo perché un programma è scritto in Java fa non significa che non ci sono overflow del buffer. La Java Virtual Machine stessa non è implementata in Java; è implementato in (probabilmente) C o C ++, che sono altrettanto inclini a buffer overflow come qualsiasi altro programma.

Inoltre ci sono molte implementazioni della JVM. Per ognuno che aggiusti, ce ne sono altri dieci che sono probabilmente ancora vulnerabili.

Spero di non essere inciampato per tutta la mia scatola di sapone .... :-)

SunnyNewb
2012-07-06 16:15:49 UTC
view on stackexchange narkive permalink

Vorrei rispondere dal punto di vista di uno studente che ha recentemente iniziato a conoscere in modo approfondito gli attacchi di buffer overflow. Anch'io avevo le stesse preoccupazioni e dubitavo dei vantaggi di conoscere gli attacchi di buffer overflow, ma considerando quanto ho imparato per arrivare alla sostanza, sono molto contento di aver scelto di farlo.

Finora ho dovuto:

  1. Imparare l'assemblaggio x86, principalmente basato su Ubuntu
  2. Imparare un po 'di programmazione C
  3. Diventa un ninja con gdb
  4. Comprendere il codice della shell
  5. Cerca tutti i forum sulla sicurezza IT che posso e impara il processo per rendere più sicuri software / sistemi operativi

Queste abilità sono molto trasferibile e non ho rimpianti. Sfortunatamente, non ho nessuno che me lo insegni. Ho dovuto risolvere il problema con tutorial video 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 fungere da trampolino di lancio per conoscere minacce più complesse o contemporanee.

pierce
2012-07-07 11:20:06 UTC
view on stackexchange narkive permalink

No, non insegnare agli overflow del buffer. Insegna la corruzione della memoria. Insegna le primitive dell'exploit. Sì, hanno bisogno di conoscere anche la storia, ma non dovrebbe occupare più della metà della lezione. Dico che quando si tratta di compiti a casa effettivi, dai loro delle sfide che hanno tutte le protezioni della memoria abilitate, ma forse rendi il server vulnerabile più debole, con alcune rivelazioni di memoria che danno suggerimenti su vari offset.

Dovrebbero anche capire che molte protezioni della memoria sono per lo più espedienti, e spesso gli "offset casuali" non sono così casuali come potresti pensare che siano. Dovrebbero imparare a riconoscere i bug e usare i bug che hanno per colpire le cose che sanno, in modo che possano ottenere ciò che vogliono.

Dovrebbero pensare piuttosto in termini di sovrascrittura dei puntatori a funzione rispetto agli indirizzi di ritorno e saltare in un codice eseguibile noto (ret2libc, ROP) invece di saltare nello shellcode nello stack / heap.

Todd-ProNoob
2012-07-06 21:53:24 UTC
view on stackexchange narkive permalink

Essendo uno studente universitario appena uscito da un corso di c ++, sì, lo so che non è la stessa cosa .., ma il mio professore si è assicurato di dare maggiore enfasi all'insegnamento sui buffer overflow e su come prevenirli, e ti incoraggio davvero a continuare a insegnare sui buffer overflow in qualsiasi corso in cui insegni a programmare. Non può danneggiarli farlo.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...