3 ms·

Nice write up. Some little tips: - you’re on 64-bit, so you probably want x/gx (or x/16gx, etc.) to print out 64-bit words (the g means “giant”). That’ll make

Nice write up. Some little tips: - you’re on 64-bit, so you probably want x/gx (or x/16gx, etc.) to print out 64-bit words (the g means “giant”). That’ll make the addresses on the stack more useful. (x/ax works too, and will attempt to resolve addresses to symbols if possible, at the cost of making the output not aligned in columns). - the stack overflow is detected by using a canary value, basically a random series of bytes sitting after the string on the stack (your canary for example is 0x00 0x80 0xf7 0x8a 0x8a 0xbb 0x58 0xb6). This gets checked at the end of the function; on a mismatch, the function calls __stack_chk_fail which prints an error and aborts the program. The canary is pretty clever: it starts with a null byte so that it won’t be leaked by normal string functions, and the true canary is stored somewhere else in memory (not th stack) so it can’t be easily leaked or corrupted.

moonchild 5y ago
> The canary is pretty clever: it starts with a null byte so that it won’t be leaked by normal string functions Doesn't that also mean it won't be overwritten by string functions, masking certain bugs? Would it be better to make the nul byte the second one, so that only one byte can be leaked, but certain program bugs that wouldn't otherwise will be exposed?
- toast0 5y ago
  strcpy and friends don't check for a null byte in the destination to find the end of the buffer, that wouldn't work very well because often you want to copy into a buffer that has been initialized as all zeros. Or copy a new string into a buffer that already has a shorter string, etc.
- mukesh610 5y ago
  While that's a better way to do that, if the canary had a null at the beginning it would effectively render string off-by-one errors useless, since now they can't even be exploited to crash a program. Again, this should not be used as an excuse to ignore string off-by-one errors since these errors might be triggered in other architectures where the canary isn't guaranteed to start with a null.
saagarjha 5y ago
> the true canary is stored somewhere else in memory Specifically, on x86-64 Linux it's stored at fs:0x28.

moonchild 5y ago

> The canary is pretty clever: it starts with a null byte so that it won’t be leaked by normal string functions Doesn't that also mean it won't be overwritten by string functions, masking certain bugs? Would it be better to make the nul byte the second one, so that only one byte can be leaked, but certain program bugs that wouldn't otherwise will be exposed?

toast0 5y ago
strcpy and friends don't check for a null byte in the destination to find the end of the buffer, that wouldn't work very well because often you want to copy into a buffer that has been initialized as all zeros. Or copy a new string into a buffer that already has a shorter string, etc.
mukesh610 5y ago
While that's a better way to do that, if the canary had a null at the beginning it would effectively render string off-by-one errors useless, since now they can't even be exploited to crash a program. Again, this should not be used as an excuse to ignore string off-by-one errors since these errors might be triggered in other architectures where the canary isn't guaranteed to start with a null.

saagarjha 5y ago

> the true canary is stored somewhere else in memory Specifically, on x86-64 Linux it's stored at fs:0x28.