c - Buffer overflow works in gdb but not without it -

i on centos 6.4 32 bit , trying cause buffer overflow in program. within gdb works. here output:

[root@localhost bufferoverflow]# gdb stack gnu gdb (gdb) red hat enterprise linux (7.2-60.el6_4.1) copyright (c) 2010 free software foundation, inc. license gplv3+: gnu gpl version 3 or later <http://gnu.org/licenses/gpl.html> free software: free change , redistribute it. there no warranty, extent permitted law.  type "show copying" , "show warranty" details. gdb configured "i686-redhat-linux-gnu". bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... reading symbols /root/bufferoverflow/stack...done. (gdb) r starting program: /root/bufferoverflow/stack process 6003 executing new program: /bin/bash missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.2.i686 sh-4.1# 

however when run program stack on own seg faults. why might be?

exploit development can lead serious headaches if don't adequately account factors introduce non-determinism debugging process. in particular, stack addresses in debugger may not match addresses during normal execution. artifact occurs because operating system loader places both environment variables , program arguments before beginning of stack:

since vulnerable program not take arguments, environment variables culprit. mare sure same in both invocations, in shell , in debugger. end, can wrap invocation in env:

env - /path/to/stack 

and debugger:

env - gdb /path/to/stack ($) show env lines=24 columns=80 

in above example, there 2 environment variables set gdb, can further disable:

unset env lines unset env columns 

now show env should return empty list. @ point, can start debugging process find absolute stack address envision jump (e.g., 0xbffffa8b), , hardcode exploit.

one further subtle important detail: there's difference between calling ./stack , /path/to/stack: since argv[0] holds program how invoked it, need ensure equal invocation strings. that's why used /path/to/stack in above examples , not ./stack , gdb stack.

when learning exploit memory safety vulnerabilities, recommend use wrapper program below, heavy lifting , ensures equal stack offsets:

$ invoke stack         # call executable $ invoke -d stack      # run executable in gdb 

here script:

#!/bin/sh  while getopts "dte:h?" opt ;   case "$opt" in     h|\?)       printf "usage: %s -e key=value prog [args...]\n" $(basename $0)       exit 0       ;;     t)       tty=1       gdb=1       ;;     d)       gdb=1       ;;     e)       env=$optarg       ;;   esac done  shift $(expr $optind - 1) prog=$(readlink -f $1) shift if [ -n "$gdb" ] ;   if [ -n "$tty" ];     touch /tmp/gdb-debug-pty     exec env - $env term=screen pwd=$pwd gdb -tty /tmp/gdb-debug-pty --args $prog "$@"   else     exec env - $env term=screen pwd=$pwd gdb --args $prog "$@"   fi else   exec env - $env term=screen pwd=$pwd $prog "$@" fi