Re: Parameter Overflow Attack?

From: Walter Roberson (roberson@ibd.nrc.ca)
Date: 11/28/02 

From: roberson@ibd.nrc.ca (Walter Roberson)
Date: 28 Nov 2002 19:09:35 GMT

In article <20021128164153.41e80c7b.spamtrap@flash-gordon.me.uk>,
Mark Gordon <spamtrap@flash-gordon.me.uk> wrote:
:Also, the normal C calling conventions are that the parameters are
:pushed on to the stack in reverse order, followed by the return address
:so the called routine would see everything correctly. The caller is then
:normally responsible for removing the parameters from the stack.

I do not think that you are correct that this is
"the normal C calling convention". Real machines are much more
complex, passing some items in registers, worrying about alignments,
having to account for structs, possibly doing varargs differently.
See for example this description of an ABI for SGI -N32 (MIPS cpus):
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Developer/books/Mpro_n32_ABI/sgi_html/ch02.html&srch=calling%20convention

On the SGI MIPS machines, there is no worry about extra arguments
throwing anything off because SGI uses "frames". That is, the value of
the stack pointer is copied *before* any arguments are pushed, and this
value is made available through a register and all arguments are
referenced relative to this register. A frame could potentially record
non-arguments such as debugging-related information, or information
about which registers need to be restored after the call -- the general
scheme allows for any consistant fixed-length of data to proceed the
arguments that got pushed onto the stack.

I would also point out to you that if you look at <varargs.h>
or <stdarg.h> then the code for va_arg(), which {deliberately}
has the side-effect of leaving you ready for the next parameter,
does the adjustment by *adding* the parameter size to the previous
pointer. This only works if the calling convention is that the
arguments are arranged into increasing memory -- which would
imply pushing in normal order if "pushing onto the stack" increases
the stack pointer, and pushing in reverse order if "pushing onto the
stack" decreases the stack pointer. See the code at
http://nemesis.sourceforge.net/browse/h/ix86/stdarg.h.html 

--
100% of all human deaths occur within 10 miles of Earth.

Relevant Pages

  • Re: Parameter Overflow Attack?
    ... :the stack pointer, and pushing in reverse order if "pushing onto the ... has a description of the gcc calling convention for Intel machines. ... I had difficulty finding an explicit statement of this; ...
    (comp.security.misc)
  • Re: heap / stack
    ... >> removed from the stack in reverse order from the order in which they ... let alone specifies that it must work as you ...
    (comp.lang.cpp)
  • Re: user stack question.
    ... On Linux/PowerPC, stack grows down, but gcc allocates locals ... in reverse order (variables declared later in code are higher on ... In order to understand recursion you must first understand recursion. ...
    (comp.unix.solaris)
  • Re: display stack
    ... >> I want to display a stack but keep the elements in the stack as they were. ... I am using the standard library stack. ... displays the elements in reverse order of the original code, ... is there any compiler where this code doesn't compile or does ...
    (comp.lang.cpp)
  • Re: is it possible to create integer-variables withthestandardvalue 0??
    ... kbarthelmess@compuserve.com (Kurt Barthelmess (TeamB)) wrote: ... >>Assuming you mean they are in reverse order ... That's the idea of a stack.. ...
    (borland.public.delphi.language.objectpascal)