Cambio strano dell'indirizzo durante l'overflow del buffer

Question

Cambio strano dell'indirizzo durante l'overflow del buffer

#1 da (5 voti)
#2 da (3 voti)
#3 da (1 voti)

4

Stavo testando un buffer overflow e la seguente cosa strana è accaduta:

L'indirizzodiritornoèa0xbffff7bcchehoscopertodaltest.L'hosostituitoconilvalorechevolevo0xbffff636.

Quandovienechiamatoreturnsembradirigereversounindirizzodiversodaquellochehoaggiunto.Dallatracciaposterioresipuòvederechehatestatotuttigliindirizziaccantoaquello.

Tuttavia,hasostituito0xbffff636con0xbffff71b.Chiaramentenonhacambiatoglialtriindirizzichehaprovatoatornarenellabacktraceda1a6,ma0nonècorretto.Sembrache#0avrebbedovutoessere0xbffff636maèstatomodificato,cometuttiglialtriindirizzidopoiltest.

Qualèunapossibileragionepercuil'indirizzoècambiato?

Modifica/UPDATE

Questomostral'indirizzo0xbffff636chesitrovanelmezzodiunaslittaNOP.Ilbufferè500byte,l'indirizzodiritornoè540offset.

Sono attualmente in un punto di rottura nell'istruzione return, e ciò che è strano è che fare un backtrace al punto mostra che 0xbffff636 è stato provato come punto di ritorno, ma non ho ancora restituito. Quando continuo e restituisco il backtrace si trasforma in backtrace che ho postato originariamente con '0xbff636' diventando '0xbffff71b'. Ho pensato di aggiungere questo.

UPDATE2 Ecco la parte rilevante del codice del libro:

Invecedicontinuare,continuoa"passare" al programma finché non ho abbandonato la funzione recv_line che copiava i dati in un buffer (chiamata richiesta). Questa funzione è tornata a buon fine poiché non ho toccato il suo indirizzo. Ora ho continuato con la funzione di gestore di sopra fino a quando sono arrivato alla fine e questo è quello che ho visto:

Sembra che non trovi 0xbfff636 valido quando lo vede per la prima volta. Ho già fatto overflow in questo ambiente, quindi sono abbastanza sicuro che non ci siano protezioni.

Nota : sto compilando con -g il flag di debug. Corro il processo come sudo. Quindi collegalo al processo in esecuzione con gdb

c buffer-overflow

posta dylan7 07.01.2016 - 06:42

fonte

3 risposte

5

Address Space Layout Randomization (ASLR) e Data Execution Prevention (DEP) sono tecniche utilizzate per impedire lo sfruttamento dei buffer overflow.

ASLR utilizza posizioni di offset casuali in cui un file eseguibile del sistema viene caricato nella memoria.

DEP contrassegna le aree di memoria come eseguibili o non eseguibili e consente di eseguire i dati solo nei percorsi di memoria contrassegnati eseguibili.

Quando i due sono combinati, diventa incredibilmente difficile sfruttare le vulnerabilità nelle applicazioni che utilizzano il codice shell.

Tuttavia, non è impossibile. Ci sono modi in cui queste tecniche possono essere aggirate. Il seguente link è un white paper che spiega una situazione in cui ASLR e DEP sono ignorati: link

risposta data 07.01.2016 - 07:28

fonte

1

Hai iniziato da un'istruzione a metà della pila? Se lo fai, il valore che era già in memoria potrebbe essere restituito se non è stato cancellato come previsto.

Questa è una possibile spiegazione del comportamento.

C'è un brillante esempio di questo nell'ultimo terzo di questo video.

risposta data 07.01.2016 - 09:10

fonte

Leggi altre domande sui tag c buffer-overflow

Tipico attacco XSS della casella di ricerca Come potrebbe honeypot essere vulnerabile?

score 3 · Accepted Answer

Dopo ulteriori indagini è emerso che quando si costruiva il payload usando l'istruzione print di Python un 0a newline veniva aggiunto subito prima dello shellcode e dopo l'ultimo NOP risultante in un codice non estensibile. L'ho capito sperimentando con il programma C del libro che ha creato lo stesso identico payload ma ha funzionato quando l'ho eseguito. Dopo aver usato l'istruzione print di Perl per creare il file payload, non sono stati aggiunti 0a e l'exploit ha avuto successo. Era sottile ma l'ho preso.