Di solito, no, gli exploit di overflow del buffer non riguardano il codice di sovrascrittura. Ma ci sono problemi di definizione.
Un exploit di overflow del buffer (del tipo "write") sfrutta una situazione in cui il sistema di destinazione può essere creato per scrivere più dati di quelli nell'area in cui scrive, sovrascrivendo ciò che era nella RAM accanto al buffer, con dati che possono essere più o meno controllati dall'attaccante. La classica tecnica di exploit è quella di localizzare in quel dato sovrascritto un puntatore al codice che sarà, a un certo punto, seguito dall'applicazione di destinazione. Pertanto, l'utente malintenzionato può far deragliare l'applicazione e ricevere istruzioni di esecuzione che si trovano altrove nella RAM.
Mentre il codice è in RAM, la maggior parte se non tutto è in sezioni di sola lettura; il sistema operativo utilizza la MMU della piattaforma per contrassegnare tali sezioni in quanto tali e qualsiasi tentativo di scrittura su codice attiverà un'eccezione da il kernel del sistema operativo. Inoltre, in un tipico sistema, le sezioni di codice e le sezioni di dati sono piuttosto distanti nello spazio degli indirizzi, rendendo difficile il tentativo di scavalcarlo.
Una situazione molto classica è quando il buffer overflown è in pila (in gergo C, è una "variabile locale"), perché lo stack include anche dei puntatori al codice, cioè il pointer di istruzioni salvato . Quando viene immessa una funzione, il puntatore dell'istruzione viene salvato nello stack, in modo che quando la funzione ritorna, l'esecuzione può tornare al sito di chiamata. Questo puntatore dell'istruzione salvato è quindi un puntatore di codice che verrà seguito in qualche punto dell'esecuzione, quindi è un obiettivo primario per gli overflow.
Un altro caso piuttosto comune è relativo all'utilizzo di vtables in lingue che supportano uno stile di sviluppo orientato agli oggetti (tipicamente C ++, ma anche "C orientata agli oggetti"). Gli vtables sono tabelle nella RAM, piene di indicatori di funzioni, che vengono seguite quando i metodi vengono richiamati. Tali indicatori sono buoni obiettivi per gli exploit di overflow (il PS3 jailbreak funzionava in questo modo).
Ora ci sono linguaggi che non sono stati compilati per le istruzioni non elaborate, ma per un formato speciale chiamato codice filettato . Il codice threadato è fondamentalmente una lunga successione di puntatori al codice (ad altri codici thread o a sequenze di istruzioni native). Questo è tipico delle lingue che accettano il codice di costruzione in fase di esecuzione, ovvero cose che vengono spesso descritte come "interpreti". Un overflow del buffer in quel contesto potrebbe portare a una sovrascrittura del codice (threaded), perché, dal punto di vista del kernel e della CPU, il codice thread è dati. Questa è la parte in cui i dettagli della definizione possono morderti.
Si noti che tutto quanto sopra riguarda un overflow in cui i dati sono scritti in un buffer e oltre quel buffer. Ci sono anche "read" overflow (forse il termine "overrun" sarebbe più appropriato), in cui i dati vengono letti oltre un buffer di origine (e presumibilmente scritti in un altro buffer). Ciò può portare alla perdita di segreti e anche all'applicazione che lavora su dati incoerenti. Le conseguenze variano notevolmente, a seconda di cosa l'applicazione fa con i dati. Questo può essere molto scomodo, ovvero molto conveniente per un utente malintenzionato, se l'overflow è tale che l'utente malintenzionato ottiene parti di chiavi crittografiche o altri dati sensibili.