I'm learning about buffer overflows, and I get the idea of fat pointer, but what I don't quite get is how are they a good protection? If you were able to modify the pointer so it points to another address, wouldn't you be able to modify the obj base and obj end section of the fat pointer so that the pointer still seems valid?


Buffer overflows aren't about setting the pointer to point to another arbitrary address.

A buffer overflow happens when an input causes your program to performs a seemingly-correct operation (e.g. "increment(): move the pointer forward 256 bytes") too many times, so that the pointer moves out of the intended data structure / array, and into another object.

A "fat pointer" contains information about the data structure / array size. This means increment() can have safety checks in its code, to make sure the pointer is within the appropriate bounds. You still need safety checks somewhere in your code, but this lets you centralise it.

  • Thank you I forgot about the basic buffer overflow and it's true that in this case it will help. Couldn't there be a case however where in memory you have a buffer followed by a pointer, and by overflowing the buffer you could set the pointer to a chosen address? In this case would the fat pointer help? – Pixel Apr 3 '17 at 16:38
  • 8
    @Pixel If you're doing this, you're probably doing it wrong. If you're not working with the sort of system that Mel, the realest programmer of all used (hint: you're not), you shouldn't be doing this. – wizzwizz4 Apr 3 '17 at 20:41
  • 15
    @Pixel There is no magical data structure that can survive having its values overwritten - the point is to never get to that point! Instead, you would use a fat pointer (or other forms of overflow protection) on the code that was dealing with the preceding buffer, so the memory following it is safe. Trying to create data structures to protect against being overwritten by overflows is like pre-emptively bandaging up your foot... because you're about to shoot yourself in it. :p – cloudfeet Apr 3 '17 at 22:49
  • 3
    @Pixel, the "fat pointer" isn't the one that comes after the buffer: It's the one that the code uses to fill the buffer. The fat pointer is what stops the code from filling beyond the buffer's end and overwriting the other pointer. – Solomon Slow Apr 4 '17 at 5:15

It seems like you think of the type of bufferoverflow which usually happens on the heap. There typically the allocated memory chunks are stored as elements, with metadata, which include pointers to the next and previous element, in doubly linked lists. In theory by overflowing the buffer you'd be able to overwrite the metadata of the next memory chunk and if that one is freed you could be able to overwrite a function pointer, leading to arbitrary code execution. For more information on exploitation see this website

Fat pointers could protect you from this: By simply checking for each operation on the array like reading from or writing to the location, internally a bounds check, wether the given offset/index is valid, will be done and if and only if the bounds check is passed the operation will be executed. (Like @cloudfeet already said.) This means you will not be able to write after the bounds of your memory and therefore are unable to overwrite things like the metadata of the next memory chunk or a pointer on the stack.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.