L'overflow del buffer sull'heap vs lo stack

Question

L'overflow del buffer sull'heap vs lo stack

#1 da (2 voti)
#2 da (0 voti)

0

È mia opinione corrente che, al fine di sfruttare con successo una vulnerabilità di overflow del buffer basata su stack, dobbiamo prima sovrascrivere il buffer, sovrascrivendo così il puntatore di ritorno e ottenendo il controllo di EIP. Una volta che controlliamo EIP, possiamo utilizzare un'istruzione JMP ESP per saltare all'inizio del nostro stack, eseguendo il nostro shellcode (assumiamo che DEP o ASLR non siano in vigore solo per semplicità e per ragioni teoriche).

Ora per l'heap, comprendo che gli overflow sono ancora presenti. La mia domanda è: lo sfruttamento di un buffer overflow è diverso dall'heap? Se sì, quali sono i dettagli più fini?

buffer-overflow heap-overflow

posta Henry F 07.04.2018 - 01:25

fonte

2 risposte

0

L'acquisizione della capacità di esecuzione non è in effetti l'unico modo per sfruttare un overflow del buffer. Il bug heartbleed è un recente esempio ben noto di una situazione di tipo di overflow del buffer di heap, in cui tutto ciò che l'utente malintenzionato poteva fare era leggere oltre il buffer. Non scrivere o acquisire capacità di esecuzione. link

risposta data 07.04.2018 - 13:18

fonte

Leggi altre domande sui tag buffer-overflow heap-overflow

Come vengono costruiti gli exploit buffer-overflow per lavorare contro bersagli diversi? Domanda sulla privacy di WiFi?

score 2 · Accepted Answer

Con un overflow dello stack - se continui a straripare - tu trabocchi prima dei vars dei locals, poi registri salvati, poi restituisci l'indirizzo, poi gli argomenti della funzione, poi piomba più in basso nello stack, forse gestori di eccezioni, ecc. Di solito come attaccante si usa effettivamente l'indirizzo di ritorno sovrascritto per saltare da qualche parte interessante.

Con un overflow dell'heap si trabocca ... qualunque cosa si trova oltre il tuo pezzo di memoria. Nelle implementazioni di heap vecchie o errate che potrebbero essere metadati dell'heap che possono darti, ad es. il potere di scrivere cose in memoria (che potresti usare per sovrascrivere un puntatore a funzione). Nelle altre implementazioni dell'heap dovrai progettare un modello di allocazioni e deallocazioni per ottenere l'heap in uno stato in cui vi è un pezzo allocato interessante sul lato destro del tuo pezzo di memoria. Forse un vtable o qualche altro puntatore di funzione.

Gli overflow dell'heap sono altamente specifici per l'implementazione e l'applicazione dell'heap. Su Linux ci sono le tecniche "house of ..." perché glibc malloc è uno scherzo (mi spiace!), Su Windows l'heap è diventato molto ben protetto e ben randomizzato e bisogna sperare che le applicazioni portino le proprie implementazioni di heap insicure a ottieni l'1% di prestazioni in più. Lo fanno spesso.