Warum bekomme ich "Nicht finden können gebunden der aktuellen Funktion", wenn ich das überschreiben der ret-Adresse eines verwundbaren Programm?
Ich soll ausgenutzt werden, um einen stack-basierten buffer-overflow für Bildung verwendet.
Es ist eine typische Funktion mit einem parameter aufgerufen von main, die als Eingabe vom Programm einen lokalen Puffer, in dem die parameter gespeichert. Gegeben eine Eingabe, so dass nops+shellcode+address_shellcode
werde ich ausnutzen.
Nach dem Debuggen mit gdb fand ich die Adresse der shell-code, da es als parameter übergeben, und direkt nach der strcpy
ich untersuchen Sie den Stapel und die $ebp+8
was ist der return-Adresse wurde erfolgreich überschrieben mit der Adresse des shell-code. So habe ich, was ich will. Aber wenn ich vorwärts ging, die Ausführung, die ich habe:
->shellcode_address in ?? ()
dann
Cannot find bound of current function
Die Rückkehr-Adresse hat den Wert, den ich haben möchte. Irgendwelche Ideen, was ist passiert?
Auch wenn ich es ausführen bekam ich einen "segmentation fault" und habe ich es kompilieren mit -g -fno-stack-protector
. Warum?
Wie könnte ich hinzufügen debug-info für die nop-Anweisung, gefolgt von NOPs für andere und am Ende mit shellcode?
Ich weiß nicht genau, wie gdb arbeiten, aber ich erwarte Sie nicht. der gdb sucht die Adresse des instruction-pointer in seiner großen, alten Tisch von debug-Informationen an, dass es geladen wurde von der ausführbaren Dateien, die Sie kennt. Aber der instruction pointer auf dem stack, es ist nicht abgedeckt durch diesen debug-info. Vielleicht in der Theorie, die Sie synthetisieren könnte, einige ZWERG-Daten um die aktuelle stack-Adresse, und laden Sie diese in den gdb, aber ich habe keine Ahnung, wie.
Ich denke nicht so. Es eine einfache stack-basierten Pufferüberlauf ausnutzen. Mir fehlen sth else
InformationsquelleAutor curious | 2012-01-05
Du musst angemeldet sein, um einen Kommentar abzugeben.
Den debugger hat Kenntnisse darüber, wo der code für die Funktionen in Ihrem Programm beginnen und enden, entweder weil diese Informationen werden im debug-Daten oder weil es nutzt alle äußeren Zeichen sichtbar in die executable rudimentäre Informationen.
Wenn der stack ist in einem einwandfreiem Zustand, enthält die Rücksprungadresse zur aufrufenden Funktion und irgendwo oben, dass eine Rückkehr-Adresse auf eine höhere Ebene aufrufende Funktion, und so weiter. Während der Ausführung der verschiedenen debugger-Befehle, verwendet er diese Rückkehr-Adressen (und andere Daten auf dem stack und in den Zustand des Prozesses) zeigen Sie die Namen dieser Funktionen. Dies erfordert einen Blick in die return-Adresse in der debugger-wissen darüber, wo die Funktionen sind.
Sobald Sie ein Pufferüberlauf und korrupten stack, die richtige Absender-Adresse ist zerstört. Stattdessen haben Sie eine andere Adresse (eine, die auf Ihrem shellcode, wenn Sie Ihren nutzen hat). Wenn der debugger versucht, herauszufinden, welche Funktion diese Adresse ist in, es schlägt fehl, da die Adresse nicht in eine der Funktionen in Ihrem Programm.
Wenn dieser Fehler Auftritt, wird der debugger druckt die Fehlermeldung, die Sie sehen.
In der Regel kann der debugger immer noch grundlegende Funktionen auszuführen: Es kann Ihnen zeigen, Register und Speicher in Ihrem Programm, kann es immer noch single-step und Breakpoint setzen, und so weiter. Es werden Schwierigkeiten haben, Dinge zu tun, die erfordern komplizierte interpretation: Es kann nicht herausfinden, wo stack-frames, es kann nicht auf lokale Variablen, die mit Namen, und so weiter.
InformationsquelleAutor Eric Postpischil
Vorausgesetzt, Ihre Linux-Distribution ist die aktuelle, und arbeiten Sie an einer x86ish Architektur, können Sie nicht mehr ausführen shell-code von user-space-Speicher (dies gilt auch für andere Architekturen, bin ich gerade nicht so vertraut mit Ihnen). Es gibt eine Reihe von Gründen, in deinem Fall wahrscheinlich die Einstellung für die nx-bit. Gehen Sie zu Ihrer Sicherheit von Linux man-pages, und Sie werden sehen, eine große Anzahl von security-Maßnahmen standardmäßig aktiviert; und google "smashing the stack for fun 2011" für mögliche Wege, um es. Kompilieren mit "- fno-stack-protector " nur bedeutet, nicht, um ein canary-Wert; aber das ist nicht genug. Wenn Sie dies tun wollen für didaktische Zwecke, schlage ich vor, die Installation einer VM wie virtualbox, und eine alte Distribution auf.
InformationsquelleAutor gnometorule
Du bist der Ausführung von code auf dem stack, und Fragen, GDB, welche Funktion Sie sind.
Offensichtlich GDB ist verwirrt, weil Sie nicht in jeder Funktion. Es zeigt also die Adresse von "??"
Haben Sie zum kompilieren mit -no-stack-protector, weil stack-protector schützt Sie vor genau das, was Sie zu tun versuchen.
Ich sage nicht, dass es keine Möglichkeit gibt, diese zu umgehen, aber es braucht mehr Anstrengung und ein gutes Verständnis der Schutz-Mechanismus.
Sobald Sie haben sich die return-Adresse auf den shellcode, und die Rückkehr Betrieb dorthin gesprungen sind, sind Sie in der shellcode, der nicht in irgendeiner Funktion. Ich dachte, Sie wurden gefragt, warum Sie brauchen, um zu kompilieren mit no-stack-protector und beantwortet.
Es gibt keinen anderen Weg, soweit ich weiß laichen die shell andere als überschreiben der ret-Adresse mit der Adresse des shellcode vorhergehenden NOPs für Anweisungen.Bin ich falsch?
Es gibt viele Möglichkeiten. Variieren Sie die Position der shellcode - stack, auf dem heap oder sogar verwenden Sie vorhandene libc-code ("jump to libc"). Sie können auch verschiedene Methoden verwenden, um zu springen, um es zu überrennen einen Funktionszeiger, der VFT (in C++), malloc Kontroll-Strukturen. Und der code, den Sie springen können sehr unterschiedlich sein. Und eine ernsthafte hacker könnte noch viel viel mehr.
Ich wollte es nur als input-argument der prog was wäre der parameter auf die anfällige Funktion
InformationsquelleAutor ugoren
Wahrscheinlich haben Sie ein Pufferüberlauf-problem irgendwo in der Funktion
(oder so ähnlich). Es überschreibt den aktuellen stack-frame der Funktion
mit irrelevanten Daten, und zerstört die Rückkehr-Adresse, die
normalerweise gespeichert wird es unter anderem. Das Ergebnis ist, dass der code "zurück"
zu einigen unvorhersehbaren Speicherort und kann nicht herausfinden, wo es ist es wieder.
Dies ist, was die Fehlermeldung verursacht.
InformationsquelleAutor Viswesn