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


Groups > comp.lang.c > #105367

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

From Alla <vitale.alla@gmail.com>
Newsgroups comp.lang.c
Subject Re: Stackoverflow, and how C uses stack to remember function calls
Date 2017-03-04 14:58 +0300
Organization A noiseless patient Spider
Message-ID <b2e497d0-e1ae-3d29-a886-80694950c553@gmail.com> (permalink)
References <o9e922$k6i$1@dont-email.me> <19086215-8966-490c-8950-039f6914cdbe@googlegroups.com>

Show all headers | View raw


On 3/4/17 14:53, Malcolm McLean wrote:
> On Saturday, March 4, 2017 at 11:41:51 AM UTC, Alla wrote:
>> Hello!
>>
>> 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));
>> }
>>
>> int main (int argc, char **argv)
>> {
>>     f(argv[1]);
>> }
>>
>> 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?
>>
>> Thank you very much!
>>
>
> The stack looks like this
>
> Return to OS address
> 12 bytes for variable 'c'
> Return to main address
>
> So in normal operation we write 12 or fewer bytes to c,
> and return to main.
>
> With the exploit, we write 12 bytes to c, then come extra bytes,
> corrupting our return address. If we are clever enough, we can
> manipulate that code to jump to an address of our own devising,
> where our own code lives.
>
Thank you for your reply. This is exactly my question: how can someone 
manipulate that code; what is the example of the code that will make the 
main() jump to the address that contains "bad code", based on the 
program above? How is it possible by simply overflowing the memory 
allocated for c?

Back to comp.lang.c | Previous | Next — Previous in thread | Next 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