Pufferüberlauf funktioniert in gdb, aber nicht ohne

Bin ich auf CentOS 6.4 32-bit und versuche, verursachen einen buffer overflow in einem Programm. In GDB funktioniert es. Hier ist die Ausgabe:

[root@localhost bufferoverflow]# gdb stack
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/bufferoverflow/stack...done.
(gdb) r
Starting program: /root/bufferoverflow/stack
process 6003 is executing new program: /bin/bash
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.2.i686
sh-4.1#

Jedoch wenn ich das Programm stack nur auf seine eigene, es seg Fehler. Woran könnte dies liegen?

InformationsquelleAutor der Frage thaweatherman | 2013-07-21

83

Exploit-Entwicklung kann dazu führen, schwere Kopfschmerzen, wenn Sie nicht angemessen Rechnung Faktoren, die für das einführen nicht-Determinismus in der debugging-Prozess. Insbesondere die stack-Adressen im debugger kann nicht mit den Adressen während der normalen Ausführung. Dieses Artefakt tritt auf, weil das Ladeprogramm des Betriebssystems stellen die beiden environment-Variablen und Programm-Argumente vor Anfang des stack:

Seit Ihr anfällig Programm nicht alle Argumente, die Umgebungsvariablen sind wahrscheinlich die Schuldigen. Mare sicher, Sie sind die gleichen in beiden Anrufungen, die in der shell und im debugger. Zu diesem Zweck können Sie wickeln Sie Ihre Anrufung in env:
```
env - /path/to/stack
```
Und mit dem debugger:
```
env - gdb /path/to/stack
($) show env
LINES=24
COLUMNS=80
```
In dem obigen Beispiel gibt es zwei Umgebungsvariablen gesetzt, durch gdb, die weiter können Sie deaktivieren:
```
unset env LINES
unset env COLUMNS
```
Nun show env sollte eine leere Liste zurück. An diesem Punkt, starten Sie den debugging-Prozess zu finden, der absoluten stack-Adresse, die Sie sich vorstellen, um springen zu können (z.B. 0xbffffa8b), und fest in Ihrem nutzen.

Eine weitere subtile, aber wichtige Details: es gibt einen Unterschied zwischen dem Aufruf ./stack und /path/to/stack: seit argv[0] hält das Programm genau, wie Sie es aufgerufen wurde, müssen Sie sicherstellen, dass gleich der Aufruf-strings. Das ist, warum ich verwendet /path/to/stack in den oben genannten Beispielen und nicht nur ./stack und gdb stack.

Beim lernen zu nutzen mit memory-safety-Schwachstellen, empfehle ich die Nutzung der wrapper-Programm darunter, das macht die schwerarbeit und sorgt für gleich-stack-offsets:
```
$ invoke stack         # just call the executable
$ invoke -d stack      # run the executable in GDB
```
Hier ist das Skript:
```
#!/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 "$@"
  else
    exec env - $env TERM=screen PWD=$PWD gdb --args $prog "$@"
  fi
else
  exec env - $env TERM=screen PWD=$PWD $prog "$@"
fi
```
InformationsquelleAutor der Antwort mavam
7

Die Adresse des stack-frame-pointer wenn der code ausgeführt wird in gdb ist anders läuft es in der Regel. So können Sie beschädigt die Adresse zurück, die rechts in den gdb-mode, aber kann es nicht Recht, wenn die Ausführung im normalen Modus. Der Hauptgrund dafür ist, dass die environment-Variablen unterscheiden sich zwischen den zwei situation.

Als dies ist nur eine demo, Sie können ändern Sie die Opfer-code ein und drucken Sie die Adresse des Puffers. Dann ändern Sie Ihre return-Adresse offset+Adresse Puffer.

In Wirklichkeit, jedoch,Sie müssen erraten Sie die return-Adresse hinzufügen NOP sledbevor Sie Ihre bösartigen code. Und können Sie erraten, mehrere Male, um eine korrekte Adresse, da deine Vermutung kann falsch sein.

Hoffe das kann dir helfen.

InformationsquelleAutor der Antwort York
6

Den Grund Ihres buffer overflow funktioniert unter gdb und segfaults anders ist, dass gdb deaktiviert address space layout randomization. Ich glaube, das war standardmäßig aktiviert in gdb version 7.

Sie können dies überprüfen, indem Sie folgenden Befehl ausführen:
```
show disable-randomization
```
Und legen Sie es mit
```
set disable-randomization on
```
oder
```
set disable-randomization off
```
InformationsquelleAutor der Antwort LogicG8
4

Hier ist ein einfacher Weg, läuft Ihr Programm mit identischen stacks in das terminal und in gdb:

Erstens, stellen Sie sicher, dass Ihr Programm wird kompiliert ohne stack-Schutz,

gcc -m32 -fno-stack-protector -z execstack -o shelltest shelltest.c -g

und und ASLR ist deaktiviert:

echo 0 > /proc/sys/kernel/randomize_va_space

HINWEIS: der Standardwert auf meinem Rechner war 2, Hinweis Ihr, bevor das verändern.

Dann läuft dein Programm so (terminal und gdb jeweils):
```
env -i PWD="/root/Documents/MSec" SHELL="/bin/bash" SHLVL=0 /root/Documents/MSec/shelltest
env -i PWD="/root/Documents/MSec" SHELL="/bin/bash" SHLVL=0 gdb /root/Documents/MSec/shelltest
```
Innerhalb gdbstellen Sie sicher, dass unset LINES und COLUMNS.

Hinweis: ich habe diese Umgebungsvariablen durch Herumspielen mit einer Testprogramm.

Jene zwei ausgeführt wird, geben Sie identische Zeiger an der stack-Spitze, so dass keine Notwendigkeit für remote-script-Spielereien, wenn man versucht Sie zu nutzen, einen binäre Remote gehostete.

InformationsquelleAutor der Antwort Aralox
2

Ich habe versucht die Lösung hier akzeptiert und Es funktioniert nicht (für mich). Ich wusste, dass gdb Hinzugefügt von Umgebungsvariablen und für, dass Grund der stack-Adresse nicht übereinstimmen, aber auch das entfernen dieser Variablen kann ich nicht arbeiten, mein nutzen, ohne gdb (ich habe auch versucht das Skript geschrieben in dem akzeptierten Lösung).

Aber auf der Suche im web fand ich ein Skript, dass die Arbeit für mich: https://github.com/hellman/fixenv/blob/master/r.sh

Die Nutzung ist im Grunde das gleiche, dass Skript in der akzeptierten Lösung:
- r.sh gdb ./Programm [Argumente] um das Programm in gdb
- r.sh ./Programm [Argumente], um das Programm auszuführen ohne gdb
Und dieses Skript funktioniert für mich.

InformationsquelleAutor der Antwort RdlP
0

Eines der wichtigsten Dinge, die gdb hat, dass nicht passieren außerhalb gdb ist null Speicher. Mehr als wahrscheinlich irgendwo in den code, den Sie sind nicht Initialisierung von Speicher und es wird immer Müll Werte. Gdb löscht automatisch alle Speicher, die Sie zuordnen, versteckt diese Arten von Fehlern.

Beispiel: die folgenden arbeiten sollten im gdb, nicht aber die außerhalb:
```
int main(){
    int **temp = (int**)malloc(2*sizeof(int*)); //temp[0] and temp[1] are NULL in gdb, but not outside
    if (temp[0] != NULL){
        *temp[0] = 1; //segfault outside of gdb
    }
    return 0;
}
```
Versuchen Sie, Ihr Programm unter valgrind, um zu sehen, wenn es erkennen kann, dieses Problem.

InformationsquelleAutor der Antwort chacham15
0

Bin ich auf CentOS 6.4 32-bit und versuche, verursachen einen buffer overflow in einem Programm... Aber wenn ich das Programm stack nur auf seine eigene, es seg Fehler.

Sollten Sie auch dafür sorgen FORTIFY_SOURCE nicht beeinflussen Ihre Ergebnisse. Der seg fault klingt wie FORTIFY_SOURCE könnte das Problem sein, weil FORTIFY_SOURCE einfügen "sicherer" - Funktion aufruft, zum Schutz gegen einige Typen von buffer-overflows. Wenn der compiler ableiten kann, Ziel-Puffer-Größen, die Größe überprüft, und abort() heißt, auf eine Verletzung (D. H., Ihre seg-fault).

Ausschalten FORTIFY_SOURCE für die Prüfung, sollten Sie das kompilieren mit -U_FORTIFY_SOURCE oder -D_FORTIFY_SOURCE=0.

InformationsquelleAutor der Antwort jww

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.