why dosent buffer gets overflowed

[raashid bhatt]

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void func(char *p)
{
char i[5];
strcpy(i, p);
}

int main(int argc, char **argv)
{

func("AAAAAAAAAA"); // i have supplied 2 X 5 char to it
system("pause");
return 0;
}

[Richard Heathfield]

raashid bhatt said:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void func(char *p)
{
char i[5];
strcpy(i, p);

Subject line: "why dosent buffer gets overflowed"

What makes you think the buffer isn't being overflowed?

}

int main(int argc, char **argv)
{

func("AAAAAAAAAA"); // i have supplied 2 X 5 char to it

Then you're trying to store more data in the array than it has room for,
and you don't provide any safeguards against that, so you're overflowing
that buffer, and the result is that the program exhibits undefined
behaviour - i.e. the rules of C don't tell you what will happen.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[raashid bhatt]

On Aug 21, 10:45*pm, Richard Heathfield <[e-mail]:

raashid bhatt said:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void func(char *p)
{
char i[5];
strcpy(i, p);

Subject line: "why dosent buffer gets overflowed"

What makes you think the buffer isn't being overflowed?

}

int main(int argc, char **argv)
{

func("AAAAAAAAAA"); // i have supplied 2 X 5 char to it

Then you're trying to store more data in the array than it has room for,
and you don't provide any safeguards against that, so you're overflowing
that buffer, and the result is that the program exhibits undefined
behaviour - i.e. the rules of C don't tell you what will happen.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

i am using a debugger to track EIP but its this program exits nornally

[Richard Heathfield]

raashid bhatt said:

On Aug 21, 10:45 pm, Richard Heathfield <[e-mail]:

>raashid bhatt said:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void func(char *p)
{
char i[5];
strcpy(i, p);

Subject line: "why dosent buffer gets overflowed"

What makes you think the buffer isn't being overflowed?

}

int main(int argc, char **argv)
{

func("AAAAAAAAAA"); // i have supplied 2 X 5 char to it

Then you're trying to store more data in the array than it has room for,
and you don't provide any safeguards against that, so you're overflowing
that buffer, and the result is that the program exhibits undefined
behaviour - i.e. the rules of C don't tell you what will happen.

i am using a debugger to track EIP but its this program exits nornally

Fine. That's one legal outcome of undefined behaviour caused by overflowing
a buffer. There's nothing in the rules that says the program must crash.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jens Thoms Toerring]

raashid bhatt <ra**********@gmail.comwrote:

On Aug 21, 10:45Â*pm, Richard Heathfield <[e-mail]:

raashid bhatt said:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void func(char *p)
{
char i[5];
strcpy(i, p);

Subject line: "why dosent buffer gets overflowed"

What makes you think the buffer isn't being overflowed?

}

int main(int argc, char **argv)
{

func("AAAAAAAAAA"); // i have supplied 2 X 5 char to it

You actually supply 11 characters here, don't forget about the
trailing '\0' character!

Then you're trying to store more data in the array than it has room for,
and you don't provide any safeguards against that, so you're overflowing
that buffer, and the result is that the program exhibits undefined
behaviour - i.e. the rules of C don't tell you what will happen.

i am using a debugger to track EIP but its this program exits nornally

Looks as if you have read that using a buffer overrun it's possible
to change the flow of control of a program. But it's luckily not
that simple - you need to understand rather well how things work on
a certain architecture to write a program that exploits a buffer
overrun to achieve that effect (if it's possible at all and which
then only works on the target architecture). In general you can't
predict what happens as the result of a buffer overrun, at least
as far as guarantees go the C language make, it's just undefined
behaviour as Richard pointed out, so it would also be an allowed
result that running the program sets your computer on fire.

Just for fun try to replace your function func() with this:

void func( char *p )
{
int i = 0;
char i[ 5 ];
int j = 0;

printf( "Before strcpy(): i = %d, j = %d\n", i, j )
strcpy( i, p );
printf( "After strcpy(): i = %d, j = %d\n", i, j )
}

It may or may not print out different values for i or j. But if
it does that doesn't mean that it will do the same on a different
machine.
Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[William Pursell]

I think we've had this discussion enough on
other threads, but gets() is always a potential
source of buffer overflow. ;)

--
William Pursell

[James Kuyper]

raashid bhatt wrote:

On Aug 21, 10:45 pm, Richard Heathfield <[e-mail]:

>raashid bhatt said:

>>#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void func(char *p)
{
char i[5];
strcpy(i, p);

Subject line: "why dosent buffer gets overflowed"

What makes you think the buffer isn't being overflowed?

....

i am using a debugger to track EIP but its this program exits nornally

So, why does that make you think that the buffer isn't being overflowed?

[raashid bhatt]

On Aug 22, 3:31*am, James Kuyper <[e-mail]:

raashid bhatt wrote:

On Aug 21, 10:45 pm, Richard Heathfield <[e-mail]:

raashid bhatt said:

>#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void func(char *p)
{
char i[5];
strcpy(i, p);
Subject line: "why dosent buffer gets overflowed"

What makes you think the buffer isn't being overflowed?

...

i am using a debugger to track EIP but its this program exits nornally

So, why does that make you think that the buffer isn't being overflowed?

i mean if buffer gets overflowed then EIP should contains my A's and
as per as definition of EIP (pointer to code) which contains A's
should cause the program to crash

[Richard Heathfield]

raashid bhatt said:

On Aug 22, 3:31 am, James Kuyper <[e-mail]:

>raashid bhatt wrote:

On Aug 21, 10:45 pm, Richard Heathfield <[e-mail]:

<snip>

>>

>What makes you think the buffer isn't being overflowed?

...

i am using a debugger to track EIP but its this program exits nornally

So, why does that make you think that the buffer isn't being overflowed?

i mean if buffer gets overflowed then EIP should contains my A's and
as per as definition of EIP (pointer to code) which contains A's
should cause the program to crash

Wrong. If the buffer is overflowed, then the C Standard imposes NO
REQUIREMENTS on what should happen - that's what "undefined behaviour"
means. The "it should do this" behaviour you describe is one possibility,
but only one among infinitely many. The program is *not* required to
behave as you expect. What happens is outside the control of the C
language. Your implementation can do anything it likes.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

raashid bhatt wrote:

On Aug 22, 3:31 am, James Kuyper <[e-mail]:

>raashid bhatt wrote:

>>On Aug 21, 10:45 pm, Richard Heathfield <[e-mail]>
wrote:
raashid bhatt said:

>>>>#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void func(char *p)
{
char i[5];
strcpy(i, p);
Subject line: "why dosent buffer gets overflowed"

>>>What makes you think the buffer isn't being overflowed?

...

>>i am using a debugger to track EIP but its this program exits
nornally

So, why does that make you think that the buffer isn't being
overflowed?

i mean if buffer gets overflowed then EIP should contains my A's and

EIP is a register, it's unlikely to be full of As (or 0x41s).

as per as definition of EIP (pointer to code) which contains A's
should cause the program to crash

Since you have a debugger you might like to investigate exactly where those
extra 5 As end up, if anywhere, and what that memory would otherwise have
been used for. Then you can find out why your program doesn't crash.

--
Bartc

[Richard Tobin]

In article <df**********************************@t1g2000pra.g ooglegroups.com>,
raashid bhatt <ra**********@gmail.comwrote:

>i mean if buffer gets overflowed then EIP should contains my A's

Why do you think that? When the buffer overflows, the characters
will go into whatever happens to follow the buffer. That may not be
anything important.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[vippstar]

On Aug 22, 5:32 pm, [e-mail] (Richard Tobin) wrote:

In article <[e-mail]>,
raashid bhatt <[e-mail]:

i mean if buffer gets overflowed then EIP should contains my A's

Why do you think that? When the buffer overflows, the characters
will go into whatever happens to follow the buffer. That may not be
anything important.

They don't need to. When the buffer "overflows", what really happends
is that undefined behavior is invoked. Once that happends, that's it.
You can't predict the behavior.

[Kenny McCormack]

In article <ea**********************************@w7g2000hsa.g ooglegroups.com>,
<vi******@gmail.comwrote:

>On Aug 22, 5:32 pm, [e-mail] (Richard Tobin) wrote:

>In article <[e-mail]>,
raashid bhatt <[e-mail]:

>i mean if buffer gets overflowed then EIP should contains my A's

Why do you think that? When the buffer overflows, the characters
will go into whatever happens to follow the buffer. That may not be
anything important.

They don't need to. When the buffer "overflows", what really happends
is that undefined behavior is invoked. Once that happends, that's it.
You can't predict the behavior.

While this is true in the totally artificial CLC/C-Standard sense, it is
not true in the real world.

HTH - no thanks necessary for this obvious correction to your otherwise
stirling post.

[Richard Tobin]

In article <ea**********************************@w7g2000hsa.g ooglegroups.com>,
<vi******@gmail.comwrote:

>i mean if buffer gets overflowed then EIP should contains my A's

>Why do you think that? When the buffer overflows, the characters
will go into whatever happens to follow the buffer. That may not be
anything important.

>They don't need to. When the buffer "overflows", what really happends
is that undefined behavior is invoked. Once that happends, that's it.

Child: [tries to stick his finger in an electric socket]
Parent: Don't do that, it violates safety regulation EIC/3/981b.
Onlooker: The electricity might kill you. Even if it doesn't
this time, it might next time.
Parent: That's not required. What really happens is that you
violate safety regulation EIC/3/981b.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[cr88192]

"raashid bhatt" <ra**********@gmail.comwrote in message
news:df**********************************@t1g2000p ra.googlegroups.com...
On Aug 22, 3:31 am, James Kuyper <[e-mail]:

raashid bhatt wrote:

On Aug 21, 10:45 pm, Richard Heathfield <[e-mail]:

raashid bhatt said:

>#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void func(char *p)
{
char i[5];
strcpy(i, p);
Subject line: "why dosent buffer gets overflowed"

<snip>

i mean if buffer gets overflowed then EIP should contains my A's and
as per as definition of EIP (pointer to code) which contains A's
should cause the program to crash

however...

you need to keep track of the memory layout as well, and although on x86
(implied by reference to EIP) the buffer may overflow and thrash the return
address, one needs to take into account certain things, like exactly how
much is on the stack, how the compiler has organized it, ...

now, as it so happens, you may well have only partially overwritten EBP
here, which will not change the return address, but it may (depending on
compiler and settings) crash if you try to use local variables...
of course, since these kinds of things usually have nefarious uses, I will
refrain from describing the details too much further...

[cr88192]

"William Pursell" <bi**********@gmail.comwrote in message
news:f3**********************************@x41g2000 hsb.googlegroups.com...

>
I think we've had this discussion enough on
other threads, but gets() is always a potential
source of buffer overflow. ;)

or, alternatively:
"I wants it bigger buffer";
"why I take this it not gets bigger";
he takes more, and then overflows just prior to crashing...

--
William Pursell