Consequences of this buffer overflow?

Question

So here I believe I have a small buffer overflow problem I found when reviewing someone else\'s code. It immediately struck me as incorrect, and potentially dangerous, but a

Answer 1

You assessment is correct, except that the springf will put 28 characters in the buffer counting the end-of-string NUL at the end (That's why you needed the misplaced "+1" in the first place)

Note that in my experiences, if something fails outside of a debugger, but works with stepping through in the debugger, in 100% of the time, you've overrun a local buffer. Debuggers push a lot more onto the stack, so it's less likely the something important was overwritten.

Answer 2

I tried it with heap allocations, variables are not continuous in memory in this case. That is why it is hard to make buffer overflow in this case.

Buy try it with stack overflow

#include "stdio.h"
#include "string.h"

int main()
{
     unsigned int  y      = (0xFFFFFFFF);
     char buffer[strlen("This string is 27 char long" + 1)];
      unsigned int  x      = (0xFFFFFFFF);
      sprintf(buffer, "This string is 27 char long");

      printf("X (%#x) is %#x, Y (%#x) is %#x, buffer '%s' (%#x) \n", &x, x,&y, y, buffer, buffer);
      return 0;
  }

You will see that Y is corrupted.

Answer 3

Correct statement. Since you are passing address of the second character of the string to strlen(), you are getting the length one character less as a result. Aside from that, the main problem is with sprintf(), that's one of the reasons that it's not safe.

Even this compiles and executes (may also crash).

    char* x = new char;
    sprintf(x, "This is way longer than one character");
    printf("%s", x);

In order to avoid this dangerous issue, you should use safe versions of this function like snprintf() or asprintf() under GCC or sprintf_s() under MSVC.

As references, please have a look at The GNU C Library documentation in this regard and also security note of MSDN's sprintf() article.

Answer 4

The problem is that you are writing somewhere in the memory, but not on the stack. Therefore, it's hard to actually see what's wrong. If you want to see the damages, try allocating the string on the stack

char buffer[strlen("This string is 27 char long" + 1)];

and the write past it. Other variables will be written, you can also add some code to be executed if you really know how the binary works.

To exploit a buffer overflow like that, you need to write the data you want, then find a way to "jump" to this data to be executed.

Answer 5

You are correct that pointer arithmetic in this example would produce an incorrect (shorter) length passed to new. The most probable reason why you are not able to make this crash is because there is some uncertainty as to how much buffer space is actually provided by the memory allocation.

The library is allowed to provide a larger buffer than was requested. Furthermore, it is also possible that whatever follows your buffer is prefixed by an allocation header that is subject to machine word alignment rules. This means there could be up to three padding bytes (depending on platform) before the very next allocation header.

Even if you overwrote the next allocation header (which is used to manage the allocated memory blocks) it would not manifest itself as a problem until the owner of that next block attempted to return it to the heap.