das ende des buffer overflow?

#16 Also bei mir gibts diese "linux-gate.so" auch aber sie zeigt sich nur im mem und nicht als linked shared-object.
In jedem Fall gibt es sie nicht im file system selbst - so wie ich das jetzt kapiert hab.
Übrigens die ganzen exploits die du oben gelistet hast produzieren bei mir alle segmentation fault.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#17 exploits hab ich glaub ich nicht gepostet, aber zumindest das programm das da ist, dass angeblich jmp esp finden soll macht bei mir auch nur segmention fault. komische sache

#18 Hab mal nen ptrace gemacht hilft das?

http://www.ninth-art.de/files/got_jmpesp-trace.log
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#19 also, hab das programm in suse probiert da funktioniert es, sagt mir JMP %ESP und dann die adresse, aber sonst funktioniert es nicht. wenn jeder suse hätte dann könnte man damit was anfangen

#20

Zitat

b_m_l postete
also, hab das programm in suse probiert da funktioniert es, sagt mir JMP %ESP und dann die adresse, aber sonst funktioniert es nicht. wenn jeder suse hätte dann könnte man damit was anfangen

Entweder das oder SuSE ist schon wieder veraltet und das wurde scho gefixt bzw. abgeändert irgendwie.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#21 So Leute,

also ich hab die Files jetzt auch mal durchgearbeitet und sämtliche Beispiele nachvollzeihen können.

linux-gate.so.1 ist ja eine Library, die vom Kernel (2.6'er) her kommt. Sie nutzt die von Intel
entwickelten sysenter und sysexit befehle, da systemcalls via interrupts langsam sind (und bei
schnelleren Maschienen immer stärker ins gewicht fallen).

Da das ganze unter Linux für jeden Prozess zur verfügung stehen soll haben die Kernelentwickler
'n wenig getrickst und dieses sharedobject an eine feste stelle im Speicher verfrachtet. (Quasi die
vorletzte Seite im Speicher, bei mir an 0xffffe000, bei dir b_m_l nach deinem posting auch an der
stelle, und beim Xepher an: 0xffffffffff600000 (64Bit Checker was? ) )

So, damit haben wir code im Speicher, dessen adresse sich nicht ändert. Izik geht jetzt hin und baut
sich 'n kleines C-tool, das nach bestimmten instruktionen in dem code sucht und als besonder
sinnvoll findet er JMP %ESP. Das ist tatsächlich genail, weil ja hier der Stack angesprungen
wird und wenn da der Shellcode liegt, bäng Ziel erreicht.

Zitat

anstatt ner statischen ret-add würd ich nen JMP ESP befehl nehmen

Nich ganz, du nimmst als Rücksprungaddresse die Adresse, an der sich ein JMP %ESP befindet.

Noch Fragen?

grüße,
frosch03

#22

Zitat

So, damit haben wir code im Speicher, dessen adresse sich nicht ändert. Izik geht jetzt hin und baut
sich 'n kleines C-tool, das nach bestimmten instruktionen in dem code sucht und als besonder
sinnvoll findet er JMP %ESP. Das ist tatsächlich genail, weil ja hier der Stack angesprungen
wird und wenn da der Shellcode liegt, bäng Ziel erreicht.

Jo aber wie oben scho gesagt funktionieren die Tools ja nicht oder?
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#23 Also bei mir funzen die einwandfrei...

Ihr müsst halt die Adresse anpassen von der an gesucht wird. Weil wenn du mit der 0xffffe000
arbeitest, dann wirste irgendwo im Speicher landen, der natürlich nicht dem Prozess gehört, was dann
wieder zu nem segfault führen dürfte...

#24 bei mir nur unter ner etwas älteren suse version, sonst funktioniert da nix, sonst wärs ja so einfach wie es in den tutorials beschrieben ist und ich hätte das problem nicht

#25 Echt verwirrend, ich hab jetzt auf zwei Debian-Rechnern keine Probleme gehabt...

Aber die Idee ist mal echt faszinierend ;-)