Re: exploiting a binary if %edi can be overwritten?

[<andrewg () d2 net au>]

> > Possibly, but doubtful given what i shown. Depending on the assembly
> > of what would give us later on, it may allow it.
> .
> .
> .
> > With that, want to try gdb mybinary mybinary.core and do something
> > like x/10i ?
>
>
> Ok, here's the gdb mybinary mybinary.core:
>
> > gdb mybinary mybinary.core
> GNU gdb 4.18 (FreeBSD)
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details. This GDB was configured as "i386-unknown-freebsd"...
> (no debugging symbols found)...
> Core was generated by `mybinary'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/local/lib/libvga.so.1...
> (no debugging symbols found)...done.
> Reading symbols from /usr/local/lib/libvgagl.so.1...
> (no debugging symbols found)...done.
> Reading symbols from /usr/lib/libc.so.4...(no debugging symbols
> found)...done.
> Reading symbols from /usr/lib/libm.so.2...(no debugging symbols
> found)...done.
> Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols
> found)...
> done.
> #0  0x2813ecfa in vfprintf () from /usr/lib/libc.so.4
> (gdb) x/10i
> 0x0:    Cannot access memory at address 0x0.
> (gdb) x/10i $pc
> 0x2813ecfa <vfprintf+3990>:     repnz scas %es:(%edi),%al
> 0x2813ecfc <vfprintf+3992>:     mov    %ecx,%eax
> 0x2813ecfe <vfprintf+3994>:     not    %eax
> 0x2813ed00 <vfprintf+3996>:     lea    0xffffffff(%eax),%edi

The above command iirc at&t syntax correctly, will destroy %edi.

> 0x2813ed03 <vfprintf+3999>:     jmp    0x2813f0e6 <vfprintf+4994>
> 0x2813ed08 <vfprintf+4004>:     orb    $0x10,0xfffffe00(%ebp)
> 0x2813ed0f <vfprintf+4011>:     mov    0xfffffe00(%ebp),%edx
> 0x2813ed15 <vfprintf+4017>:     test   $0x20,%dl
> 0x2813ed18 <vfprintf+4020>:     je     0x2813ed74 <vfprintf+4112>
> 0x2813ed1a <vfprintf+4022>:     cmpl   $0x0,0xfffffe24(%ebp)
> (gdb)
>
> > What happens if you overwrite 10000 bytes instead?
>
> The same, no changes in regs or asm output.

How about info registers edi and eax?

[ snip ]

> open("/dev/mem", O_RDWR)                = 4
> fcntl(0, F_GETFD)                       = 0
> fcntl(1, F_GETFD)                       = 0
> fcntl(2, F_GETFD)                       = 0
> fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(5, 0), ...}) = 0
> ioctl(0, VT_GETMODE, 0xbfbfd288)        = -1 ENOTTY (Inappropriate
> ioctl for device)
> open("/dev/mem", O_RDONLY)              = 6
> __sysctl([hw.pagesize], 2, "\0\20\0\0", [4], NULL, 0) = 0
> break(0x80a5000)                        = 0
> mmap(0x80a3000, 4096, PROT_READ, MAP_SHARED|MAP_FIXED, 6, 0xc0000)
> 0x80a3000 close(6)                                = 0
> break(0x80a7000)                        = 0

[ snip ]

> and finally ltrace:
> > ltrace ./mybinary `perl -e 'print "A" x 10000'`
>
> atexit(0x28054e2c)                                = 0
> atexit(0x0804f694)                                = 0
> vga_init(2, 0xbfbfd4c0, 0xbfbfd4cc, 0x28068300, 0xbfbfd36c[svgalib:
> allocated virtual console #9]
> ) = 0
> sscanf(0xbfbfd5af, 0x0804f928, 0x0809d540, 0x0809d644, 0) = 1
> fprintf(0x2814fe90, "\nusage: %s [<options>] <host>:<"...,
> "EOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFEOFE
OFEOFEOFEOFEOFEOFEOFEOF".
> .. <unfinished ...>
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++

Hmm, since edi is killed above, it doesn't look that exploitable. Since you
can modify edi though, it kindof suggests you have overwritten other
information. What does a backtrace (bt) under gdb look like?

Possibly though given the ltrace, you may need to match the sscanf() call,
so that the 4rd arg is written to. (That could be the reason for the
EOF's). A x/s 0x0804f928 should suffice.

I also notice that libvga is used, and that /dev/mem is open; this itself
leads to an exploitable condition, because you can now modify kernel memory
with what you want. libvga will also attempt to drop privs for you, iirc.

(From memory, under linux for the kernel, you get the virtual address of
the kernel (maybe via /proc/ksyms), and 0x00ffffff the address to get the
physical address.)

Some distros don't set CLOSE ON EXEC when they open /dev/mem, which makes
it easier to exploit b/c you can start programs targetting that open fd,
rather than shellcoding it.

> still thanks a lot to anyone helping me with that topic!

No problems.

> regards
> avel
>
> --
> +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
> Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

Hope this helps,
Andrew Griffiths