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

Groups > comp.lang.c > #105365 > unrolled thread

Stackoverflow, and how C uses stack to remember function calls

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 2  [1] 2  Next page →

#105365 — Stackoverflow, and how C uses stack to remember function calls

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!
-- 
Respectfully,

Alla

[toc] | [next] | [standalone]

#105366

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.

[toc] | [prev] | [next] | [standalone]

#105367

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?

[toc] | [prev] | [next] | [standalone]

#105368

On Saturday, March 4, 2017 at 11:59:55 AM UTC, Alla wrote:
> 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?
>
Sorry, type "then come extra bytes", should read "then some extra bytes".

If we write 13 bytes to c, the last byte goes into the first byte of
the function return to address, which is its location in main().

[toc] | [prev] | [next] | [standalone]

#105369

Respectfully,

Alla

On 3/4/17 15:04, Malcolm McLean wrote:
> On Saturday, March 4, 2017 at 11:59:55 AM UTC, Alla wrote:
>> 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?
>>
> Sorry, type "then come extra bytes", should read "then some extra bytes".
No worries ) I also do lots of typos these days )
>
> If we write 13 bytes to c, the last byte goes into the first byte of
> the function return to address, which is its location in main().
>

[toc] | [prev] | [next] | [standalone]

#105467

On Saturday, 4 March 2017 11:53:28 UTC, 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


Not necessarily...

[toc] | [prev] | [next] | [standalone]

#105370

On 04/03/17 12:40, 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!

A good place to look would be the Wikipedia article - which looks like 
the source for your lecturer's example!

<https://en.wikipedia.org/wiki/Stack_buffer_overflow>


There are many other websites that explain the basic idea (though it is 
not always easy to guess which websites might give a good explanation).

<https://arstechnica.com/security/2015/08/how-security-flaws-work-the-buffer-overflow/>

[toc] | [prev] | [next] | [standalone]

#105371

On 3/4/17 15:30, David Brown wrote:
> On 04/03/17 12:40, 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!
>
> A good place to look would be the Wikipedia article - which looks like
> the source for your lecturer's example!
>
> <https://en.wikipedia.org/wiki/Stack_buffer_overflow>
>
>
> There are many other websites that explain the basic idea (though it is
> not always easy to guess which websites might give a good explanation).
>
> <https://arstechnica.com/security/2015/08/how-security-flaws-work-the-buffer-overflow/>
Thank you very much. I will study these materials. Indeed, web is 
inundated with different explanations, but I would rather come here for 
advises and help because I trust this community.


Respectfully,

Alla

[toc] | [prev] | [next] | [standalone]

#105373

On 04/03/17 13:34, Alla wrote:
> On 3/4/17 15:30, David Brown wrote:

>>
>> A good place to look would be the Wikipedia article - which looks like
>> the source for your lecturer's example!
>>
>> <https://en.wikipedia.org/wiki/Stack_buffer_overflow>
>>
>>
>> There are many other websites that explain the basic idea (though it is
>> not always easy to guess which websites might give a good explanation).
>>
>> <https://arstechnica.com/security/2015/08/how-security-flaws-work-the-buffer-overflow/>
>>
> Thank you very much. I will study these materials. Indeed, web is
> inundated with different explanations, but I would rather come here for
> advises and help because I trust this community.
>

I don't mean you should not ask here - merely that there is little need 
for people here to spend time explaining something that is quite well 
explained on sites like these.  Once you have read these pages, if there 
is something that you don't understand, don't agree with, or you want 
more detail, then it makes sense to come back here.  Of course, people 
here might not know relevant details - after all, it's all undefined 
behaviour in C :-)

[toc] | [prev] | [next] | [standalone]

#105374

On 3/4/17 17:23, David Brown wrote:
> On 04/03/17 13:34, Alla wrote:
>> On 3/4/17 15:30, David Brown wrote:
>
>>>
>>> A good place to look would be the Wikipedia article - which looks like
>>> the source for your lecturer's example!
>>>
>>> <https://en.wikipedia.org/wiki/Stack_buffer_overflow>
>>>
>>>
>>> There are many other websites that explain the basic idea (though it is
>>> not always easy to guess which websites might give a good explanation).
>>>
>>> <https://arstechnica.com/security/2015/08/how-security-flaws-work-the-buffer-overflow/>
>>>
>>>
>> Thank you very much. I will study these materials. Indeed, web is
>> inundated with different explanations, but I would rather come here for
>> advises and help because I trust this community.
>>
>
> I don't mean you should not ask here - merely that there is little need
> for people here to spend time explaining something that is quite well
> explained on sites like these.  Once you have read these pages, if there
> is something that you don't understand, don't agree with, or you want
> more detail, then it makes sense to come back here.  Of course, people
> here might not know relevant details - after all, it's all undefined
> behaviour in C :-)
:)
I agree. But only because I asked here I now have a great link, the 
second one (have only skimmed through it, will need to dig a bit 
deeper), which you have kindly provided :) I will be back if I have more 
questions.


Respectfully,

Alla

[toc] | [prev] | [next] | [standalone]

#105376

And advanced, but somewhat outdated explanation can be found at..

http://phrack.org/issues/49/14.html

[toc] | [prev] | [next] | [standalone]

#105379

On 3/4/17 17:23, David Brown wrote:
> On 04/03/17 13:34, Alla wrote:
>> On 3/4/17 15:30, David Brown wrote:
>
>>>
>>> A good place to look would be the Wikipedia article - which looks like
>>> the source for your lecturer's example!
>>>
>>> <https://en.wikipedia.org/wiki/Stack_buffer_overflow>
>>>
>>>
>>> There are many other websites that explain the basic idea (though it is
>>> not always easy to guess which websites might give a good explanation).
>>>
>>> <https://arstechnica.com/security/2015/08/how-security-flaws-work-the-buffer-overflow/>
>>>
>>>
>> Thank you very much. I will study these materials. Indeed, web is
>> inundated with different explanations, but I would rather come here for
>> advises and help because I trust this community.
>>
>
> I don't mean you should not ask here - merely that there is little need
> for people here to spend time explaining something that is quite well
> explained on sites like these.  Once you have read these pages, if there
> is something that you don't understand, don't agree with, or you want
> more detail, then it makes sense to come back here.  Of course, people
> here might not know relevant details - after all, it's all undefined
> behaviour in C :-)
>
>
Offtopic: secret message :-)
I think I found my mistake :-) I hope!

Respectfully,

Alla

[toc] | [prev] | [next] | [standalone]

#105378

On 03/04/2017 06:40 AM, Alla wrote:
...
> (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

This is detail about how C is typically implemented. There's no 
requirement in the standard that it be implemented that way. On the 
platforms where it's used for C, it's also used, one way or another, by 
most of the other programming languages.

There's also nothing particularly secret about it - it's pretty widely 
known among people who work with assembly language.

Finally, and most importantly, it's not the "address of the previous 
function" that is stored on the stack, it is specifically the address of 
the instruction in the calling function that should be executed after 
the called function returns. This isn't arbitrary documentation of some 
kind - returning from the called function involves having control jump 
to the specified address, so it can start executing the instructions 
stored at that address.
...
> 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?

It's very simple, and you've already mentioned it, but you don't seem to 
have understood the implications of what you said above. Buffer 
overwrites can allow the place on the stack where the return address is 
stored, to be replaced by a different address. When the called function 
returns, control jumps to the replacement address rather than the 
original one.

[toc] | [prev] | [next] | [standalone]

#105380

On 3/4/17 19:18, James R. Kuyper wrote:
> On 03/04/2017 06:40 AM, Alla wrote:
> ...
>> (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
>
> This is detail about how C is typically implemented. There's no
> requirement in the standard that it be implemented that way. On the
> platforms where it's used for C, it's also used, one way or another, by
> most of the other programming languages.
>
> There's also nothing particularly secret about it - it's pretty widely
> known among people who work with assembly language.
>
> Finally, and most importantly, it's not the "address of the previous
> function" that is stored on the stack, it is specifically the address of
> the instruction in the calling function that should be executed after
> the called function returns. This isn't arbitrary documentation of some
> kind - returning from the called function involves having control jump
> to the specified address, so it can start executing the instructions
> stored at that address.
> ...
>> 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?
>
> It's very simple, and you've already mentioned it, but you don't seem to
> have understood the implications of what you said above. Buffer
> overwrites can allow the place on the stack where the return address is
> stored, to be replaced by a different address. When the called function
> returns, control jumps to the replacement address rather than the
> original one.
>
Thank you very much for your explanations. I see. Also David has 
provided a great link, where the whole process is explained with numbers 
and pictures. It's much more clear now.

Offtopic: please, let me know if this reply is posted only in the group, 
and that I haven't sent a copy by email. Thank you!

Respectfully,

Alla

[toc] | [prev] | [next] | [standalone]

#105382

On 03/04/2017 12:10 PM, Alla wrote:
...
> Offtopic: please, let me know if this reply is posted only in the group,
> and that I haven't sent a copy by email. Thank you!

I've only seen this in the group - it has not (yet?) appeared in my inbox.

[toc] | [prev] | [next] | [standalone]

#105383

On 3/4/17 21:18, James R. Kuyper wrote:
> On 03/04/2017 12:10 PM, Alla wrote:
> ...
>> Offtopic: please, let me know if this reply is posted only in the group,
>> and that I haven't sent a copy by email. Thank you!
>
> I've only seen this in the group - it has not (yet?) appeared in my inbox.
>
Good ) No, it won't appear in your inbox; I have made a mistake by 
"pushing the wrong button" in a few previous replies. Solved now )

Respectfully,

Alla

[toc] | [prev] | [next] | [standalone]

#105392

On Saturday, March 4, 2017 at 10:18:20 AM UTC-6, James R. Kuyper wrote:
> This is detail about how C is typically implemented. There's no 
> requirement in the standard that it be implemented that way. On the 
> platforms where it's used for C, it's also used, one way or another, by 
> most of the other programming languages.

The pattern was established as common on C compilers before the C89 Standard
was published, and on many platforms C compilers would use the pattern if
practical, so that functions written with different compilers could call
each other.  It was never established as a part of an uppercase-S "Standard"
but in an era where compiler simplicity and interoperability were more
important than maximum compiled-code efficiency it worked well.

[toc] | [prev] | [next] | [standalone]

#105396

On 03/ 5/17 11:33 AM, supercat@casperkitty.com wrote:
> On Saturday, March 4, 2017 at 10:18:20 AM UTC-6, James R. Kuyper wrote:
>> This is detail about how C is typically implemented. There's no
>> requirement in the standard that it be implemented that way. On the
>> platforms where it's used for C, it's also used, one way or another, by
>> most of the other programming languages.
>
> The pattern was established as common on C compilers before the C89 Standard
> was published, and on many platforms C compilers would use the pattern if
> practical, so that functions written with different compilers could call
> each other.  It was never established as a part of an uppercase-S "Standard"
> but in an era where compiler simplicity and interoperability were more
> important than maximum compiled-code efficiency it worked well.

The pattern in question is the platform ABI, which has nothing to do 
with the C standard, or what came before.

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#105447

On Saturday, March 4, 2017 at 4:50:58 PM UTC-6, Ian Collins wrote:
> On 03/ 5/17 11:33 AM, supercat wrote:
> > The pattern was established as common on C compilers before the C89 Standard
> > was published, and on many platforms C compilers would use the pattern if
> > practical, so that functions written with different compilers could call
> > each other.  It was never established as a part of an uppercase-S "Standard"
> > but in an era where compiler simplicity and interoperability were more
> > important than maximum compiled-code efficiency it worked well.
> 
> The pattern in question is the platform ABI, which has nothing to do 
> with the C standard, or what came before.

Ever since C became popular, it has become commonplace for entities defining
new platforms to define an ABI which should be used by C compilers.  In the
days before C became popular on microcomputers, however, many platforms
either didn't have any "standard" way of passing parameters or else they
used a convention (sometimes called the "Pascal convention") where the code
that calls a function would push arguments on the stack and then make a
function call, and the called function would remove those arguments from the
stack.  The 8088 used in the IBM PC includes a special instruction to
facilitate using the Pascal, and the Macintosh used the Pascal convention for
almost all of its Toolbox routines even though the 68000 had no special
support for it.

The big weakness of the Pascal convention, from a C perspective, is that it
requires that called functions know how many arguments callers passed, but
some functions might not know.  Some code relied upon the fact that any
extra arguments passed to functions printf would be ignored; in the days
before prototypes, there was (from the caller's point of view) nothing
special about such functions, and the only way to make them work was to
require that callers perform their own stack cleanup after all function
calls.

Consequently, when C compilers were written for microprocessors, they used
a calling convention which in many cases was different from anything which
had been used before on those platforms.  Certainly there may have been
platforms for which the convention used by C compilers predated the compilers
in question, but in the early days of C, the C compilers used a calling
convention which existed purely for their benefit.

[toc] | [prev] | [next] | [standalone]

#105461

On 03/ 6/17 08:12 AM, supercat@casperkitty.com wrote:
> On Saturday, March 4, 2017 at 4:50:58 PM UTC-6, Ian Collins wrote:
>> On 03/ 5/17 11:33 AM, supercat wrote:
>>> The pattern was established as common on C compilers before the C89 Standard
>>> was published, and on many platforms C compilers would use the pattern if
>>> practical, so that functions written with different compilers could call
>>> each other.  It was never established as a part of an uppercase-S "Standard"
>>> but in an era where compiler simplicity and interoperability were more
>>> important than maximum compiled-code efficiency it worked well.
>>
>> The pattern in question is the platform ABI, which has nothing to do
>> with the C standard, or what came before.
>
> Ever since C became popular, it has become commonplace for entities defining
> new platforms to define an ABI which should be used by C compilers.

<snip>

I still don't see how any of this is related to the OP, or the mythical 
past you keep referring to....

-- 
Ian

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web