RE: Administrivia: List Announcement

From: andrewgat_private
Date: Tue May 13 2003 - 21:53:56 PDT

  • Next message: Frank Knobbe: "Re: Buffer overflow in Microsoft ftp.exe"

    > On Tue, 13 May 2003, Cameron Brown wrote:
    >
    >> If I supply an argv[1] of > 252 bytes, then byte 253 may (depending on
    >> many factors) overwrite the first byte of buf2.  This is going to be
    >> (I think) part of the size of the malloc'd buf2.  What interesting
    >> things can happen when you then free() an incorrectly-sized buf2 (or
    >> otherwise operate on buf2 if this were a real program) is something I
    >> am anxious to learn from others on this list!
    >
    > 	Hmmm, for me it seg faults on free(buf1). I am running on Linux
    > BTW, here is some output from gdb:
    >
    > [shafik@localhost VULNDEV]$ ./a.out `perl -e 'print "A"x2000'` `perl -e
    > 'print "B"x2000'` Segmentation fault (core dumped)
    > [shafik@localhost VULNDEV]$ gdb ./a.out ./core
    > GNU gdb Red Hat Linux (5.2-2)
    > Copyright 2002 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-redhat-linux"...
    > Core was generated by `./a.out
    > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.
    > Program terminated with signal 11, Segmentation fault.
    > Reading symbols from /lib/libc.so.6...done.
    > Loaded symbols for /lib/libc.so.6
    > Reading symbols from /lib/ld-linux.so.2...done.
    > Loaded symbols for /lib/ld-linux.so.2
    > #0  0x400aa1e6 in chunk_free (ar_ptr=0x4015bc80, p=0x8049770) at
    > malloc.c:3242
    > 3242    malloc.c: No such file or directory.
    >        in malloc.c
    > (gdb) up
    > #1  0x400a9fc0 in __libc_free (mem=0x8049778) at malloc.c:3154
    > 3154    in malloc.c
    > (gdb) up
    > #2  0x080485b3 in main (argc=3, argv=0xbfffe9d4) at vulndev-1.c:26 26
    >            free(buf1);
    > (gdb)
    >
    
    From memory (I don't have the code, and I don't have a box to do a test on
    atm) you should be able to do x/3i and it would be something like
    
    mov %edx, %
    mov % , %edx(0xc)
    
    or so. If it before that, and its near an and, it means that one of the
    uint's where you are pointing to doesn't have the lowest three bits off.
    (ie,, 0xfffffffc would be acceptable to that code)
    
    
    > --
    > Those who dream by day are cognizant of many things which escape those
    > who dream only by night. -Edgar Allan Poe
    
    Thanks,
    Andrew Griffiths
    



    This archive was generated by hypermail 2b30 : Tue May 13 2003 - 21:38:22 PDT