Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #105388

Re: Stackoverflow, and how C uses stack to remember function calls

Show key headers only | View raw

Alla <vitale.alla@gmail.com> writes:
> One of the lectures touched upon the following:
>
> Before writing my question, I would like to say that I might have not 
> correctly written down the material, so it might sound incorrect, to say 
> the least; therefore, please, correct what I will write now and help me 
> to understand how it works, maybe with the help of some functions 
> (please, nothing too fancy and complicated). Please, read to the end 
> before answering because it might not be clear what I would like to ask 
> about and thus to understand.
>
> Below is an example a completely incorrect code that doesn't perform any 
> error checking, and used for illustration purpose. This program will 
> "blindly" copy one string into another. If the length of bar exceeds the 
> length of c, then something longer than allocated memory on stack will 
> creep into c's return address space (almost quoting), and worse yet
> (here starts the part I would like your help on) as C language secretly 
> uses stack also to remember when the function is called and what is the 
> address of the previous function called, a "bad guy" can "jump back" to 
> that function using swap() (not in the code below) in the main(), and 
> this swap() not only swaps local variables/arguments, but also make 
> main() return back to the function to execute it; thus a computer 
> blindly assumes that bytes in that "address" part are the address to 
> which it should return. Therefore, these bytes might be some other, 
> rogue address, which the "bad guy" wants the program to go to - sort of 
> tricking the system. And this is done by copying more elements into the 
> c array.
>
> #include <stdio.h>
> #include <string.h>
>
> void f(char *bar)
> {
>     char c[12];
>     strncpy(c, bar, strlen(bar));
> }

The use of strncpy() here is a distraction from the main point.
The whole point of strncpy vs. the simpler strcpy is that you can
tell it how many bytes to copy -- but the number of byte that would
be copied by strcpy() is strlen(bar)+1.  Using sizeof c as the number
of bytes would make some sense.  Using strlen(bar)+1 would make the
call equivalent to the simpler strcpy(c, bar).  Using strlen(bar)
means that the target array will probably not contain a properly
null-terminated string, which is an added complication that has
nothing to do with the issue being demonstrated.

And there are other problems with strncpy, which I've written about
here: http://en.cppreference.com/w/c/language/operator_precedence

> int main (int argc, char **argv)
> {
>     f(argv[1]);
> }

No check that there's actually an argument to copy, another irrelevant
distraction.

> How does this "redirection" happen, and what is actually happening 
> underneath the hood? As I understand it, when the program is compiled, 
> first a memory for
> int main() with its local variables is allocated on the stack; if we 
> assume that a stack is a vertically placed rectangle, then the memory 
> block for the main function will be at the bottom. Next, as main() 
> contains a call to function f(), the memory for f and its local 
> variables is allocated "above" the memory for main(). When the program 
> is executed, once f() is called and finished its job, the memory on 
> stack is "cleared". So how that redirection can happen?

The C standard doesn't even mention a "stack", but the semantics of
function calls are such that they allocate memory in a stack-like
(last-in first-out) manner.  Memory is needed to store local
variables (including parameters) and metadata such as the return
address.  There is no specification of exactly how and where this
storage is allocated.  On some systems, some of this information
might be stored in registers rather than on the "stack" (though
register contents will eventually have to be spilled to memory,
because registers are a scarce resource).

The manner in which this information is stored is typically defined
by the ABI (Application Binary interface) for a given system.

*If* the return address for the call to f() happens to be stored
just after the array object c in memory, then yes, calling f() with
a pointer to a string that's too long to fit in c could overwrite
the return address and cause control to "return" to code of the
attacker's choice.

People who exploit this kind of thing are depending on low-level
details of specific implementations, not on anything specified
by the C standard.  As in any other kind of programming, there's
nothing wrong with depending on system-specific details if you need
to do so; not all code can be portable.

Incidentally, I don't think this kind of exploit is what would
normally be called a "stack overflow".  It overflows the end of the
array object to overwrite other data, but it doesn't go beyond the
top of the stack.  The term "stack overflow" normally refers to a
situation where the attempt to allocate memory for a new function
call fails because not enough memory is available.  This exploit
isn't about running out of available memory.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 14:40 +0300
  Re: Stackoverflow, and how C uses stack to remember function calls Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-04 03:53 -0800
    Re: Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 14:58 +0300
      Re: Stackoverflow, and how C uses stack to remember function calls Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-04 04:04 -0800
        Re: Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 15:12 +0300
    Re: Stackoverflow, and how C uses stack to remember function calls mark.bluemel@gmail.com - 2017-03-06 00:41 -0800
  Re: Stackoverflow, and how C uses stack to remember function calls David Brown <david.brown@hesbynett.no> - 2017-03-04 13:30 +0100
    Re: Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 15:34 +0300
      Re: Stackoverflow, and how C uses stack to remember function calls David Brown <david.brown@hesbynett.no> - 2017-03-04 15:23 +0100
        Re: Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 18:22 +0300
          Re: Stackoverflow, and how C uses stack to remember function calls Chad <cdalten@gmail.com> - 2017-03-04 07:53 -0800
        Re: Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 19:29 +0300
  Re: Stackoverflow, and how C uses stack to remember function calls "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-04 11:18 -0500
    Re: Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 20:10 +0300
      Re: Stackoverflow, and how C uses stack to remember function calls "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-04 13:18 -0500
        Re: Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 22:43 +0300
    Re: Stackoverflow, and how C uses stack to remember function calls supercat@casperkitty.com - 2017-03-04 14:33 -0800
      Re: Stackoverflow, and how C uses stack to remember function calls Ian Collins <ian-news@hotmail.com> - 2017-03-05 11:50 +1300
        Re: Stackoverflow, and how C uses stack to remember function calls supercat@casperkitty.com - 2017-03-05 11:12 -0800
          Re: Stackoverflow, and how C uses stack to remember function calls Ian Collins <ian-news@hotmail.com> - 2017-03-06 17:11 +1300
            Re: Stackoverflow, and how C uses stack to remember function calls supercat@casperkitty.com - 2017-03-06 07:23 -0800
              Re: Stackoverflow, and how C uses stack to remember function calls David Brown <david.brown@hesbynett.no> - 2017-03-06 17:22 +0100
                Re: Stackoverflow, and how C uses stack to remember function calls scott@slp53.sl.home (Scott Lurndal) - 2017-03-06 16:40 +0000
                Re: Stackoverflow, and how C uses stack to remember function calls jm.bourguet@gmail.com - 2017-03-06 09:04 -0800
                Re: Stackoverflow, and how C uses stack to remember function calls scott@slp53.sl.home (Scott Lurndal) - 2017-03-06 17:18 +0000
                Re: Stackoverflow, and how C uses stack to remember function calls Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-06 11:22 -0700
                Re: Stackoverflow, and how C uses stack to remember function calls luser droog <luser.droog@gmail.com> - 2017-03-06 09:58 -0800
                Re: Stackoverflow, and how C uses stack to remember function calls luser droog <luser.droog@gmail.com> - 2017-03-06 10:04 -0800
  Re: Stackoverflow, and how C uses stack to remember function calls Barry Schwarz <schwarzb@dqel.com> - 2017-03-04 09:33 -0800
    Re: Stackoverflow, and how C uses stack to remember function calls Alla <vitale.alla@gmail.com> - 2017-03-04 22:46 +0300
  Re: Stackoverflow, and how C uses stack to remember function calls Keith Thompson <kst-u@mib.org> - 2017-03-04 12:25 -0800

csiph-web