I am aware that Format String Attacks work by having a vulnerable function which allows the user to read values from the stack using %x and write by using %n.

Since one of the goals of a Format String Attack can be to overwrite the address of a function in the Global Offset Table, I was wondering does StackGuard prevent this?

I know that StackGuard protects save-return addresses of functions to be overwritten, however, will it help against a Format String Attack if that attack aims to change the GOT values?

1 Answer 1


No, StackGuard is not intended to protect against these types of attacks, nor does it in practice.

StackGuard specifically targets buffer overflows. When a buffer on the stack is overwritten, an attacker typically tries to overwrite the saved return address at the top of the stack frame. StackGuard inserts a canary value before the saved return address, and typically checks that it matches the known good canary before returning. If it doesn't match, then there was an overflow attempt and the program should exit.

Format strings are not buffer overflows and usually do not have the same goal. While a buffer overflow blindly "smashes the stack", format string exploits are a bit more precise. If you wanted to change the saved return address and knew the stack address where it's located, you could write directly to that address, leaving the rest of the stack (and canary) intact. This provides greater flexibility for an attacker in many cases, since buffer overflows don't allow you to simply skip over the canary.

StackGuard also has no affect on the GOT overwrite you mentioned, since this doesn't affect the stack at all. The proper mitigation to GOT overwrite is full RELRO (Relocation Read-Only). Due to startup performance costs of full RELRO, most binaries (and gcc defaults) only use partial RELRO. Partial still leaves the .got.plt writable, which is the part used for this type of attack, so it is not effective for preventing format string attacks either.

The -D_FORTIFY_SOURCE=2 option to gcc prevents strings stored in read-write memory from using the %n specifier, preventing an attacker from overwriting memory. It does not prevent read primitives, however, so an attacker may still be able to leak critical data from the stack (e.g. the canary).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .