La mia comprensione dei buffer overflow è corretta?

2

Sono nuovo al pentesting e mi chiedo se la mia attuale comprensione degli exploit di overflow del buffer sia corretta. Supponendo uno spazio di indirizzamento operativo di 3 indirizzi, uno spazio di istruzioni di 2 indirizzi e un puntatore di istruzioni ad indirizzo 1 adiacente:

(La freccia è la posizione corrente del puntatore di istruzioni.)

==>000x243  
001xFFF

002x26B  
003x4FF  
004x14C  

005x000 (points to address 000 as the next instruction)

Il buffer overflow sostituisce lo spazio operativo con gli indirizzi 4 , sovrascrivendo la chiamata del puntatore di istruzioni allo spazio operativo con l'indirizzo di uno spazio operativo, rendendo quindi il prossimo codice macchina eseguito uno della scelta dello sfruttatore? Indicato qui:

000x243  
001xFFF

==>002x456 (arbitrary machine code to be executed)  
003xB3B  
004x00F

005x002 (points to address 002 as next instruction)
    
posta ThePracticalCryptographer 25.02.2016 - 16:24
fonte

1 risposta

2

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.

    
risposta data 25.02.2016 - 17:07
fonte