Bufferoverflow in c

**EVOEx** · 12-18-2009

Originally Posted by Elysia

Taking the address of a function without the &.

Hmmm it worked fine for me (Linux, 4.4.1). No, I didn't bother to use good coding style :P. I expected this to work on most systems though. And that is what buffer overflows are about: they don't work everywhere, they are very tightly coupled to architecture.

It should really work without changing ebp. This is what happens:
- The return address is overwritten to the address of main
- Main returns to it's calling function using ret.
- Main is called. True, with a different stack. So it won't recurse an infinite number of times. However, it did manage to run more than 1000 times on my system. But if the stack is different it will be able to recurse less or, maybe, not at all.

**Elysia** · 12-18-2009

It repeated only a few times for me. Yes, it works without the ebp part, but it only loops x times.
With the ebp hack (so it resets the stack), it loops infinitely.

**EVOEx** · 12-18-2009

Originally Posted by Elysia

It repeated only a few times for me. Yes, it works without the ebp part, but it only loops x times.
With the ebp hack (so it resets the stack), it loops infinitely.

Okay, so let's make a better version. This one works for me. And yes, this time I did use "&" to take the address of a function. But no, I didn't bother to cast the pointer to an integer :P.

Code:

#include <stdio.h>

void test(int n)
{
  int a[1];
  int i;
  for(i = 0; i < 5; i++)
    a[i] = n;
}


int main()
{
  printf("Main\n");
  test(&main);
}

**Elysia** · 12-18-2009

It's still wrong... pointer to a function taking no arguments, returning int is not the same as int.
This is bad practice. I would like to see something that works in both C and C++.
But yeah, after a few modifications, it loops until it runs out of stack space:

Code:

#include <stdio.h>

typedef int (main_ptr)();
void test(main_ptr* n)
{
	main_ptr* a[1];
	int i;
	for(i = 0; i < 5; i++)
		a[i] = n;
}


int main()
{
	printf("Main\n");
	test(&main);
}

**whiteflags** · 12-18-2009

The fact is though buffer overflows are never this blatant so a more useful example in C would involve C functions anyway, such as scanf or sprintf, and even those are just the functions you would actually use.

I remember when someone else demonstrated dynamic format strings, might as well use that.

Code:

sprintf(format , "%%%us , %%%us %%%us", lastSize, firstSize, phoneSize);
sprintf(line, format, entries[ foo ].firstName, entries[ foo ].lastName, entries[ foo ].phone);

If any of the sizes overflow, you also potentially have an overflow problem in your string buffers. Isn't that fun? Of course, C++ can have buffer overflows, but unlike Elysia, I don't see much point in an example that works in both languages. You can do things totally differently in C++ so finding a similar error that is equally likely for both languages is hard. Finding an error that works in both languages when you're actually trying is nightmare mode.

**EVOEx** · 12-18-2009

Originally Posted by Elysia

This is bad practice.

Of course it is bad practice. We're talking about a buffer overflow here. That is bad practice per definition.

A function is described by a pointer, it's arguments and a return value. The arguments are pushed on the stack, the pointer is called, and the return value is stored in eax. I think you know that. The code sample I wrote converts this to a pointer. When the called function executes the "ret" instruction it will jump to the address of the function. Of course it doesn't push anything on the stack, so no arguments are added. Finally the return value doesn't matter, as it will actually never return anything.

But saying that a buffer overflow example uses "bad style"... Well... Duh? :P

**Elysia** · 12-19-2009

EVOEx, EVOEx, EVOEx...
Again, a pointer to a function that takes no arguments and returns an int is NOT an int. Their sizes are not guaranteed to be the same.
Compile your example on x64 Windows. It will probably fail in a spectacular way, because a pointer is 8 bytes and int 4 bytes.
Hence, bad style, and possibly even undefined behavior.
Except for the buffer overrun part, of course.

Thread: Bufferoverflow in c

Thread Tools

Search Thread

Display

Similar Threads

C bufferoverflow question. can anyone solve it?

Constructive criticism, suggestions etc