Re: Is this exploitable?

From: sin (sin_at_insolence.net)
Date: 05/23/03

  • Next message: sin: "Re: CORRECTION: vulndev1.c solution (WARNING! QUESTIONS!)" 
    Date: Fri, 23 May 2003 11:00:12 -0500 (CDT)
To: Ingram <Vail@gmx.net>

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    1) you never overwrite a register, so you never 'overwrote' ecx, you may
    have however overwritten a memory address which is later put into ecx.

    2) in a 'normal' stack based overflow, you dont overwrite eip, you
    overwrite an address stored on the stack which is later restored via the
    'ret' instruction. think of ret as an instruction that pops the last
    address on the stack and then jumps to it.

    3) i cant tell anything from that, as to whether its exploitable or not.

    4) ecx is a register, much like the other general registers, it just holds
    an address.

    5) the difference between having an arb value in ecx than eax all depends
    on the code, so it depends on how each register is used in the code.

    the source code or even a dump of the instructions leading up to the
    sigsegv would be helpful in determining whether your chasing smoke in a
    mirror or not.

    perhaps you might find it just as stimulating to play with examples that
    teach the fundamentals?

    Gera has a nice collection of insecure code fragments that you could try
    to exploit that might teach you a little more than you already know?

    http://community.core-sdi.com/~gera/InsecureProgramming/

    j

    "Once set in motion, the process of questioning could come to but one end,
    the erosion of conviction and certitude and collapse into despair" (The
    Specter of the Absurd, 1988).

    On Thu, 22 May 2003, Ingram wrote:

    > Date: Thu, 22 May 2003 16:55:18 +0200 (MEST)
    > From: Ingram <Vail@gmx.net>
    > To: vuln-dev@securityfocus.com
    > Subject: Is this exploitable?
    >
    > hi folks,
    >
    > i recently found a possible vuln binary, which crashes with SIGSEV 11.
    > I think this binary (tool written by a friend of mine) is exploitable, but
    > the overflow is not happening in the register i expect them (or better, i
    > know
    > how to exploit ;)
    >
    > See the gdb dump:
    > ++++++++++++++++++++++++++++++++++++++++++++++++++++++
    > develop# gdb -core delimma.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".
    > Core was generated by `delimma'.
    > Program terminated with signal 11, Segmentation fault.
    > #0 0x280f166b in ?? ()
    > (gdb) i r
    > eax 0xbfbf33cc -1077988404
    > ecx 0x41414141 1094795585
    > edx 0xbfbf21dc -1077992996
    > ebx 0x280fc00c 672120844
    > esp 0xbfbf2158 0xbfbf2158
    > ebp 0xbfbf2180 0xbfbf2180
    > esi 0x280f7233 672100915
    > edi 0x2 2
    > eip 0x280f166b 0x280f166b
    > eflags 0x202 514
    > cs 0x1f 31
    > ss 0x2f 47
    > ds 0x2f 47
    > es 0x2f 47
    > fs 0x2f 47
    > gs 0x2f 47
    > (gdb) bt
    > #0 0x280f166b in ?? ()
    > #1 0x280d6664 in ?? ()
    > #2 0x280d6858 in ?? ()
    > #3 0x280d6d8c in ?? ()
    > #4 0x280d12d9 in ?? ()
    > #5 0x280d11d9 in ?? ()
    > #6 0x804a8c2 in ?? ()
    > #7 0x41414141 in ?? ()
    > Cannot access memory at address 0x41414141.
    > (gdb)
    > ++++++++++++++++++++++++++++++++++++++++++++++++++++++
    >
    > As you can see, the 0x41 have overwritten 'ecx'.
    >
    > My questions:
    >
    > 1) Is this exploitable?
    > 2) What is ecx?
    > 3) Whats the diff between having 0x41 in eax, ebp, eip or ecx? Are they
    > all exploitable?
    > 4) What kind of exploit (if possible) i have to craft to exploit this
    > binary?
    >
    > many thanks in advantage!
    >
    >
    > --
    > +++ GMX - Mail, Messaging & more http://www.gmx.net +++
    > Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
    >
    >
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (FreeBSD)

    iD8DBQE+zkWOoEcehqzkkpgRAl49AJ9bkENmmxjc+FwpYSu/7WqM75eFZACg2LyV
    JRqpBPBdTfn5SCqaMjeFRwE=
    =aV7o
    -----END PGP SIGNATURE-----

  • Next message: sin: "Re: CORRECTION: vulndev1.c solution (WARNING! QUESTIONS!)"

    Relevant Pages

    • Re: Pulling bitFields efficiently from a byte stream
      ... First problem might be that CL is the low byte part of ECX. ... So i guess you need another 32-bit register instead of ECX, ... A reference is like a pointer, so you first have to load the ...
      (comp.lang.asm.x86)
    • Re: Style Guidelines
      ... It is 100% sure that to allways use ECX as a counter is impractical and much to rigid for the real world. ... You dont go pushing and poping for fun, when theres another register available. ... mov ebx D$BackBuffer.AddressTable ... The reason for not using ECX is because all this code developed slowly in jumps yesterday. ...
      (alt.lang.asm)
    • Re: registers and types
      ... each register ends up being a union of a bunch of types, ... Yes, type analysis is an important part of decompilation, and we ... when a live range of a register has a different type to ... last month was stored in register ecx in the original program. ...
      (alt.lang.asm)
    • Re: Calling a "procedure of object" routine w/variable parameters
      ... > through registers EAX, EDX, and ECX, respectively, works great, with ... The default calling convention is 'register' (in older Borland ... EAX, EDX then ECX, and any others on the stack). ...
      (borland.public.delphi.language.basm)
    • Re: User control question
      ... When you create an event handler, you are 'Creating' a method which handles ... in otherwords you register this method address to be fired when a ... > or I can overwrite the relevant virtual method: ...
      (microsoft.public.dotnet.languages.vb)