das ende des buffer overflow?

#1 ich hab ein problem mit dem buffer overflow, ich denke er ist nicht mehr oder nur noch sehr schwer "exploitable". kleine beschreibung: bei buffer overflows kann ich die rücksprungadresse nicht mehr richtig bestimmen weil mein shellcode bzw die NOPS immer woanders im speicher liegen, nicht mehr immer an der selben stelle wie früher (sicherheitsgründe?? ich rede grad von LINUX) gibts ne möglichkeit die rücksprungadresse nicht mit einem speicherbereich zu überschreiben wo mein shellcode liegt sondern so was wie ein JMP ESP befehl? in windows benutz ich den OLLYDBG debugger mit dem OLLYUNI.dll plugin und der sucht mir dann JMP ESP bzw CALL ESP adressen raus, gibts sowas auch für linux?

verbesserung:
so, jetzt hab ich schon
http://www.milw0rm.com/papers/55
und
http://packetstorm.linuxsecurity.com/0608-exploits/exp_jmp_rand.pl.txt
gefunden, aber funzt beides nicht, auf den speicherbereich kann nie zugegriffen werden. help

#2 Hi,

hey, voll cool, endlich mal eine echt spannende Frage

> ich denke er ist nicht mehr oder nur noch sehr schwer "exploitable".
Glaub ich garnicht mal. Man hört doch ständig von bo-lücken die exploitbar sind. Ich denke solange
es Leute gibt, die in C programmieren, wird es auch immer bo's geben ...

> weil mein shellcode bzw die NOPS immer woanders im speicher liegen,
Also meine letzten versuche mit bo's waren aber relativ erfolgreich. Und wenn ich mich noch recht
entsinne war die Speicheradresse nach einem kompilieren immer die selbe...

> nicht mehr immer an der selben stelle wie früher (sicherheitsgründe?? ich rede grad von LINUX)
Vielleicht hat dein gcc ne buffer-overflow-protection eincompiliert? (sofern es sich um gcc handelt)

> gibts ne möglichkeit die rücksprungadresse nicht mit einem speicherbereich zu überschreiben wo
> mein shellcode liegt sondern so was wie ein JMP ESP befehl?
Nicht wirklich. Das Prinzip ist ja, dass dein Programm mit call blub ein unterprogramm
aufruft. Damit nach der abarbeitung des Unterprogramms wieder zurückgekehrt werden kann
führt das Unterprogramm als letzten Befehl ret aus. Hierbei werden 4Byte vom Stack genommen
und als die Adresse interpretiert, nach der vorher der call blub ausgeführt wurde.

Wenn du jetzt die Rücksprungadresse manipulieren kannst, dann jumpt dein Programm an eine von
dir vorgegeben Stelle zurück, an der z.B. dein Code steht und führt den dann aus. Natürlich kannst
du jetzt anstelle einer Rücksprungadresse auch einen Assemblerbefehl auf den Stack ablegen.
Aber auch dieser wird dann als Adresse interpretiert und die zeigt dann wohl irgendwo ins
Nirvana (Also no way)

> in windows benutz ich den OLLYDBG debugger mit dem OLLYUNI.dll plugin und der sucht mir
> dann JMP ESP bzw CALL ESP adressen raus, gibts sowas auch für linux?
gdb kann das bestimmt... Einfach mal n wenig in den Manuals stöbern

grüße,
frosch03

#3 aaaaaaalso: erstmal danke dass es jemanden gibt der da bissl was weiß und sogar drauf antwortet ich hab die gleichen tests auf alten linux versionen (suse redhat knoppix ...) probiert da funktioniert das auch, einmal den "gefährdeten server" kompiliert, lag der shellcode und die NOPS immer an der selben stelle, einfach die rücksprungadresse dann in die NOPS gerichtet und dann wars fertig, aber bei neuen linux varianten (ich hab fedora core und das neue suse getestet) funktioniert das nicht mehr, und dass mit dem JMP ESP anstatt ner statischen ret-address muss ja auch funzen, gugg dir mal die beiden links an die ich dir gepostet habe. da soll man ja einfach mit dem "ldd vuln_prog" die adresse von linux-gate.so.1 (ich glaub so ein neues sicherheitsmodul) rausfinden und da drina nach JMP ESP suchen, aber bei mir ändert sich komischerweise auch jedesmal die adresse von linux-gate.so.1 was bedeutet nach JMP ESP zu suchen ist mal wieder sinnlos noch paar ideen?

#4 Ich steck nicht wirklich hinter Buffer Overflows, aber die neueren Linux-Distributionen verfügen über eine Menge Speicherschutzmechanismen:


Irgendwas davon wird deine Versuche verhindern. Fragt sich nun natürlich nur noch warum du das überhaupt machen willst
__________
Bitte keine Anfragen per PM, diese werden nicht beantwortet.

#5 sieht ja fies aus, so wie es aussieht wird der bof wirklich ausgerottet, man kann ihn noch durchführen um das serverprogramm zu crashen, aber code ausführen wird bald unmöglich sein, ich wills einfach nur wissen um auf dem neuesten stand zu bleiben, ist ein hobby von mir

#6 Ich kann dir dann folgenden Artikel an's Herz legen aus dem auch die Tabelle stammt:
http://www.heise.de/kiosk/archiv/ct/06/17/208/

Leider kostenpflichtig, aber ich denke die 60 Cent lohnen sich.
__________
Bitte keine Anfragen per PM, diese werden nicht beantwortet.

#7 Solange es unsaubere Programmierer gibt, gibt es auch buffer overflows.
Und das hat mit C nicht viel zu tun das kann einem auch bei einer anderen Programmiersprache (C++, C#?) passieren.
Allerdings soweit ich weiß sind die Linuxe die momentan aktuell sind ziemlich gut dagegen gerüßtet der letzte fatale buffer overflow an den ich mich erinnern kann war ptrace() im Linux 2.4er kernel soweit ich weiss.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#8 Das scheint ja wirklich spannend zu werden

Zitat

bei neuen linux varianten (ich hab fedora core und das neue suse getestet) funktioniert das nicht mehr

Interesant währe es jetzt zu wissen, was sich da verändert hat, wie z.B. gcc-versionsnummern.
Auch interesant währe es zu wissen, welcher der Sicherheitsmechanismen da jetzt dann greift.
Spontan würde ich auf die StackCanaries tippen, aber das ist nur ne ahnung.

Ich bin mir übrigens sicher, dass der BufferOverflow so schnell nicht aussterben wird. Natürlich hat
das nicht nur mit C zu tun. Allerdings sind BufferOverflows wohl eher ein Problem von bestimmten Programmiersprachen, zu denen C++ sicher zähl. Das ganze fällt einem erst auf wenn man sich klar macht, dass es Sprachen gibt, in denen man keine BufferOverflows provozieren kann.
(so z.B. dylan, haskell oder ml).
Den Programmieren kann man meiner Meinung nach nur bedingt Vorwürfe machen. Klar es gibt
Sachen, die sind grob fahrlässig (wie z.B. 'n strcpy(x, y); bei dem das y nicht überprüft wurde).
Allerdings ist es mittlerweile wohl auch grob fahrlässig noch in C zu coden (*schonmalduckt*)

Ich werd dann mal deine Links mal genauer studieren. Klingen beide recht spannend, aber kosten
sicher auch ein wenig Zeit. Morgen hab ich die gelesen und weiß sicher mehr...

grüße,
frosch03

freu mich schon auf weitere spannende diskussionen

#9 dass das mit c/c++ speziell nicht zu tun hat weiß ich auch, ist mir ja egal in welcher sprache der exploit bzw das programm geschrieben ist solange ich es danach mit nem debugger ansehen kann. es geht mir nur darum, dass sich das programm jedesmal in nem anderen speicherbereich aufhält (wie schon öfter erwähnt) und anstatt ner statischen ret-add würd ich nen JMP ESP befehl nehmen, die artikel sind echt gut die ich oben gepostet hab und die idee darin auch aber sie funzen nicht. zum beispiel steht da:

root@magicbox:~# ldd /bin/ls ; ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/tls/librt.so.1 (0xb7fce000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7e9e000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7e8c000)
/lib/ld-linux.so.2 (0xb7fe2000)
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/tls/librt.so.1 (0xb7ee5000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7db5000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7da3000)
/lib/ld-linux.so.2 (0xb7ef9000)

und dann die adresse von linux-gate.so.1 (der schutzmechanismus?) soll immer gleich bleiben und die anderen ändern sich und deshalb dann über diese "feste adresse" einen JMP ESP rausfinden, aber bei mir bleiben alle anderen gleich und nur linux-gate.so.1 ändert sich. bitte mal ausprobieren wer grad ein neues linux drauf hat, dauert ja nur 2 sekunden

#10 Bitte schön -
Host OS ist ein Gentoo Linux auf dem neusten Stand (update interval: jeden Samstag)
Kernel ist im Moment: 2.6.17-beyond3-chimaere (beyond basiert fast komplett auf ck-sources)

therion@chimaere ~ % ldd /bin/ls ; ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x00002afe54143000)
libacl.so.1 => /lib/libacl.so.1 (0x00002afe5424b000)
libc.so.6 => /lib/libc.so.6 (0x00002afe54352000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002afe5458b000)
/lib64/ld-linux-x86-64.so.2 (0x00002afe54027000)
libattr.so.1 => /lib/libattr.so.1 (0x00002afe546a0000)
librt.so.1 => /lib/librt.so.1 (0x00002b67d0650000)
libacl.so.1 => /lib/libacl.so.1 (0x00002b67d0758000)
libc.so.6 => /lib/libc.so.6 (0x00002b67d085f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b67d0a98000)
/lib64/ld-linux-x86-64.so.2 (0x00002b67d0534000)
libattr.so.1 => /lib/libattr.so.1 (0x00002b67d0bad000)

therion@chimaere ~ % locate linux-gate.so
therion@chimaere ~ % locate linux-gate.so.1
therion@chimaere ~ %
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#11 Hier noch vom Server - selbe OS, selber update interval wie oben nur stable und 32-bit
Kernel ist: 2.6.11-hardened-r15-coruscant (mit grsec)

therion@coruscant ~ % ldd /bin/ls ; ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x40018000)
libacl.so.1 => /lib/libacl.so.1 (0x40021000)
libc.so.6 => /lib/libc.so.6 (0x4002a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40143000)
/lib/ld-linux.so.2 (0x40000000)
libattr.so.1 => /lib/libattr.so.1 (0x40155000)
librt.so.1 => /lib/librt.so.1 (0x40018000)
libacl.so.1 => /lib/libacl.so.1 (0x40021000)
libc.so.6 => /lib/libc.so.6 (0x4002a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40143000)
/lib/ld-linux.so.2 (0x40000000)
libattr.so.1 => /lib/libattr.so.1 (0x40155000)

therion@coruscant ~ % locate linux-gate.so
therion@coruscant ~ % locate linux-gate.so.1
therion@coruscant ~ %

Wie man sehen kann weisen keiner meiner Maschinen diese linux-gate.so auf
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#12 thx, ändert sich ja auch immer, aber nützt mir nicht viel da es ja um linux-gate.so.1 hauptsächlich geht, die sollte statisch sein, gibts keine andere möglichkeiten an JMP %ESP adressen zu kommen? wie macht das denn das olyuni plugin unter windows

#13

Zitat

b_m_l postete
thx, ändert sich ja auch immer, aber nützt mir nicht viel da es ja um linux-gate.so.1 hauptsächlich geht, die sollte statisch sein, gibts keine andere möglichkeiten an JMP %ESP adressen zu kommen? wie macht das denn das olyuni plugin unter windows

In Welchen Linuxen kommt den die linux-gate.so vor und warum nicht bei mir?
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#14 therion@chimaere ~ % cat /proc/self/maps
00400000-00405000 r-xp 00000000 08:02 46453 /bin/cat
00504000-00505000 rw-p 00004000 08:02 46453 /bin/cat
00505000-00526000 rw-p 00505000 00:00 0 [heap]
2b0bd1dfe000-2b0bd1e19000 r-xp 00000000 08:02 93203 /lib64/ld-2.4.so
2b0bd1e19000-2b0bd1e1a000 rw-p 2b0bd1e19000 00:00 0
2b0bd1e1a000-2b0bd1e1b000 r--p 00000000 08:07 458202 /usr/lib64/locale/de_DE.utf8/LC_IDENTIFICATION
2b0bd1e1b000-2b0bd1e22000 r--s 00000000 08:07 1192428 /usr/lib64/gconv/gconv-modules.cache
2b0bd1e22000-2b0bd1e23000 r--p 00000000 08:07 458201 /usr/lib64/locale/de_DE.utf8/LC_MEASUREMENT
2b0bd1e23000-2b0bd1e24000 r--p 00000000 08:07 458200 /usr/lib64/locale/de_DE.utf8/LC_TELEPHONE
2b0bd1e24000-2b0bd1e25000 r--p 00000000 08:07 458199 /usr/lib64/locale/de_DE.utf8/LC_ADDRESS
2b0bd1e25000-2b0bd1e26000 r--p 00000000 08:07 458198 /usr/lib64/locale/de_DE.utf8/LC_NAME
2b0bd1e26000-2b0bd1e27000 r--p 00000000 08:07 458197 /usr/lib64/locale/de_DE.utf8/LC_PAPER
2b0bd1e27000-2b0bd1e28000 r--p 00000000 08:07 458196 /usr/lib64/locale/de_DE.utf8/LC_MESSAGES/SYS_LC_MESSAGES
2b0bd1e28000-2b0bd1e29000 r--p 00000000 08:07 458194 /usr/lib64/locale/de_DE.utf8/LC_MONETARY
2b0bd1e3f000-2b0bd1e40000 rw-p 2b0bd1e3f000 00:00 0
2b0bd1e40000-2b0bd1f17000 r--p 00000000 08:07 458153 /usr/lib64/locale/de_DE.utf8/LC_COLLATE
2b0bd1f17000-2b0bd1f18000 r--p 00000000 08:07 458193 /usr/lib64/locale/de_DE.utf8/LC_TIME
2b0bd1f18000-2b0bd1f19000 r--p 0001a000 08:02 93203 /lib64/ld-2.4.so
2b0bd1f19000-2b0bd1f1a000 rw-p 0001b000 08:02 93203 /lib64/ld-2.4.so
2b0bd1f1a000-2b0bd2049000 r-xp 00000000 08:02 93326 /lib64/libc-2.4.so
2b0bd2049000-2b0bd2148000 ---p 0012f000 08:02 93326 /lib64/libc-2.4.so
2b0bd2148000-2b0bd214c000 r--p 0012e000 08:02 93326 /lib64/libc-2.4.so
2b0bd214c000-2b0bd214d000 rw-p 00132000 08:02 93326 /lib64/libc-2.4.so
2b0bd214d000-2b0bd2153000 rw-p 2b0bd214d000 00:00 0
2b0bd2153000-2b0bd2154000 r--p 00000000 08:07 458192 /usr/lib64/locale/de_DE.utf8/LC_NUMERIC
2b0bd2154000-2b0bd218f000 r--p 00000000 08:07 458191 /usr/lib64/locale/de_DE.utf8/LC_CTYPE
7fffd8c96000-7fffd8cac000 rw-p 7fffd8c96000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]

Hab wohl doch eine (die vdso ist es) das sagt jedenfalls:
http://www.trilithium.com/johan/2005/08/linux-gate/
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#15 ich hab das neue fedora und da kommts vor (und ändert sich) und ich hab jetzt SUSE ausprobiert, da kommts auch vor und bleibt sogar konstant, in der arbeit habe ich eine weiß-nicht-was distribution die ganz neu ist und da kommts auch vor und ändert sich