Lo sviluppo degli exploit può causare seri mal di testa se non si tiene adeguatamente conto dei fattori che introducono e non determinismo nel processo di debug. In particolare, gli indirizzi di stack nel debugger potrebbero non corrispondere agli indirizzi durante l'esecuzione normale. Questo artefatto si verifica perché il caricatore del sistema operativo pone entrambe le variabili di ambiente e argomenti del programma prima dell'inizio dello stack:
Dal momento che il programma vulnerabile non prende alcun argomento, le variabili di ambiente sono probabilmente il colpevole . Mare sicuri che siano uguali in entrambe le invocazioni, nella shell e nel debugger. A tal fine, si può avvolgere la vostra invocazione in env:
env - /path/to/stack
E con il debugger:
env - gdb /path/to/stack
($) show env
LINES=24
COLUMNS=80
Nell'esempio di cui sopra, ci sono due variabili d'ambiente fissati dalla gdb, che si può ulteriormente disabilitare :
unset env LINES
unset env COLUMNS
Ora show env dovrebbe restituire una lista vuota. A questo punto, puoi avviare il processo di debug per trovare l'indirizzo di stack assoluto che intendi passare (ad es., 0xbffffa8b) e inserirlo nel tuo exploit.
Un altro sottile ma importante dettaglio: c'è una differenza tra chiamare ./stack e /path/to/stack: dal argv[0] tiene il programma esattamente come è stato richiamato, è necessario garantire le stringhe uguali invocazione. Ecco perché ho utilizzato /path/to/stack negli esempi precedenti e non solo ./stack e gdb stack.
Quando imparare a sfruttare con vulnerabilità di sicurezza memoria, vi consiglio di utilizzare il programma involucro sotto, che fa il lavoro pesante e garantisce offset uguali pila:
$ invoke stack # just call the executable
$ invoke -d stack # run the executable in GDB
Ecco lo script:
#!/bin/sh
while getopts "dte:h?" opt ; do
case "$opt" in
h|\?)
printf "usage: %s -e KEY=VALUE prog [args...]\n" $(basename $0)
exit 0
;;
t)
tty=1
gdb=1
;;
d)
gdb=1
;;
e)
env=$OPTARG
;;
esac
done
shift $(expr $OPTIND - 1)
prog=$(readlink -f $1)
shift
if [ -n "$gdb" ] ; then
if [ -n "$tty" ]; then
touch /tmp/gdb-debug-pty
exec env - $env TERM=screen PWD=$PWD gdb -tty /tmp/gdb-debug-pty --args $prog "[email protected]"
else
exec env - $env TERM=screen PWD=$PWD gdb --args $prog "[email protected]"
fi
else
exec env - $env TERM=screen PWD=$PWD $prog "[email protected]"
fi
'seg faults' è dovuto al buffer overflow, hai fatto, correggi, quando esegui il tuo codice OS invia SIGSEGV al tuo processo (= programma in esecuzione) sulla violazione della memoria che ti dà errore di segmentazione del messaggio - questo segnale è dovuto a te sta facendo un accesso non valido alla memoria valida. (Immagino tu stia cercando di scrivere/modificare su '" constantstring "' alla fine) –
... Lo so. Dovrebbe eseguire una shell. In GDB esegue la shell. Quando eseguo il programma al di fuori di GDB, non gira la shell, quindi il numero predefinito – thaweatherman
è dovuto al fatto che quando si esegue il codice al di fuori di GDB esso - Comportamento non definito in C standard. Mentre GDB gestisce il segnale SIGSEGV in modo che possa darti il punto di errore di segmentazione –