Sto lavorando a un homework problem che richiede la disattivazione della protezione di ottimizzazione del compilatore perché funzioni. Sto usando gcc 4.4.1 su ubuntu linux, ma non riesco a capire quali sono le bandiere giuste. Mi rendo conto che dipende dall'architettura - la mia macchina funziona con un processore Intel a 32 bit.Come disattivare l'ottimizzazione del compilatore gcc per abilitare l'overflow del buffer
Grazie.
Questo è un buon problema. Per risolvere questo problema dovrai anche disabilitare ASLR altrimenti l'indirizzo di g() sarà imprevedibile.
Disabilita ASLR:
sudo bash -c 'echo 0 > /proc/sys/kernel/randomize_va_space'
canarini Disabilita:
gcc overflow.c -o overflow -fno-stack-protector
Dopo canarini e ASLR sono disattivati dovrebbe essere un attacco di dritto in avanti come quelli descritti in Smashing the Stack for Fun and Profit
Qui è un elenco delle funzionalità di sicurezza utilizzate in ubuntu: https://wiki.ubuntu.com/Security/Features Non devi preoccuparti dei bit NX, l'indirizzo di g() sarà sempre in un execu area di memoria della tabella perché si trova all'interno del segmento di memoria TEXT. I bit NX entrano in gioco solo se si sta tentando di eseguire shellcode nello stack o heap, che non è richiesto per questo compito.
Ora vai e biasimi che EIP!
Prova la bandiera -fno-stack-protector.
non citerò l'intera pagina, ma l'intero manuale di ottimizzazione è disponibile qui: http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Optimize-Options.html#Optimize-Options
Dai suoni di esso che si desidera, almeno -O0, il default, e:
- fmudflap -fmudflapth -fmudflapir
Per front-end che lo supportano (C e C++), strumento tutti rischioso puntatore/array dereferenziazione operazioni, alcuni libreria standard funzioni stringa/heap e alcuni altri costrutti associati con test di intervallo/validità . I moduli in tal modo strumentati devono essere immuni ai buffer overflow , all'heap non valido, e ad alcune altre classi di errori di programmazione C/C++ . La strumentazione si basa su una libreria di runtime separata (libmudflap), che verrà collegata in un programma se -fmudflap viene fornito al momento del collegamento. Il comportamento in fase di esecuzione del programma strumentale è controllato dalla variabile di ambiente MUDFLAP_OPTIONS. Vedere env MUDFLAP_OPTIONS = -aiuto a.out per le sue opzioni.
Urm, tutte le delle risposte finora sono state errate con la risposta di Rook essere corretta.
Inserimento:
sudo echo 0 > /proc/sys/kernel/randomize_va_space
Seguito da:
gcc -fno-stack-protector -z execstack -o bug bug.c
Disabilita ASLR, SSP/Propolice e di Ubuntu NoneXec (che è stato posto in 9.10, e abbastanza semplice da aggirare vedere il mprotect(2) tecnica per mappe come eseguibili e jmp) dovrebbero aiutare un po ', tuttavia queste "caratteristiche di sicurezza" non sono affatto infallibili. Senza il flag `-z execstack ', le pagine hanno marcature di stack non eseguibili.
Non hai letto il link ragazzi. Se lo facessi, sapresti che sta cercando di eseguire g(), che è una funzione che viene compilata nel file binario. Questo è un indirizzo di una funzione. I bit NX entrano in gioco quando si tenta di eseguire shellcode nell'heap o nello stack, il suo attacco è molto più semplice. – rook
Concordo sul fatto che tutti gli altri si sbagliano completamente, è ovvio che siamo gli unici 2 che hanno sfruttato un buffer overflow. Comunque continuo a pensare che la mia risposta sia più corretta. – rook
Hmm, ho appena trovato il link - ho pensato che fosse solo un altro generico, hai ragione. Mi scuso. –
So che è un thread vecchio, ma voglio sottolineare che non è necessario disabilitare ASLR per fare un buffer overflow! Sebbene ASLR sia Enabled (kernel_randomize_va_space = 2) non avrà effetto a meno che l'eseguibile compilato non sia PIE, quindi a meno che non abbia compilato il tuo file con -fPIC -pie flag, ASLR non avrà effetto.
Penso che sia sufficiente disabilitare i canarini con -fno-stack-protector. Se si vuole verificare se ASLR funziona o non (codice indipendente di posizione deve essere impostata), uso: indurimento-check executable_name
On distro più recenti (come del 2016), sembra che PIE è abilitato di default in modo da sarà necessario disabilitarlo esplicitamente durante la compilazione.
Ecco un piccolo riassunto di comandi che può essere utile quando si gioca a livello locale con esercizi di tipo buffer overflow in generale:
Disabilita canarino:
gcc vuln.c -o vuln_disable_canary -fno-stack-protector
Disabilita DEP:
gcc vuln.c -o vuln_disable_dep -z execstack
Disattiva PIE:
gcc vuln.c -o vuln_disable_pie -no-pie
Disabilita tutti i meccanismi di protezione di cui sopra (attenzione: solo per test locale):
gcc vuln.c -o vuln_disable_all -fno-stack-protector -z execstack -no-pie
Per le macchine a 32 bit, sarà necessario aggiungere il parametro -m32 pure .
grazie, lo farò solo che :) Oh -? Come faccio a riattivare la protezione a un-merda mia macchina .. La mia ipotesi è sudo echo 1>/proc/sys/kernel/randomize_va_space – sa125
@ sa125 sì, ecco come è riattivato. In effetti questo è il modo in cui accendi e spegni gli altri moduli del kernel mentre il sistema è in esecuzione;) – rook
Sembra che sottolineo che sul mio sistema randomize_va_space è impostato su 2, non su 1, quindi vale la pena controllare in anticipo se si intende riattivarlo. – Rushyo