I would like to know if it is possible to read (or write) the canary values from %gs register.

If "yes", how; and if "no", why?

Also, I have been reading somewhere that the canary values are stored in some sort of TLS (I suppose it to be the "Thread Local Storage").

Can someone please shed some light on it?

  • Read them from what? On what platform (at a guess, Windows on x86_32 since you mention TLS and %gs)? Oct 8, 2013 at 12:01
  • I'm working on linux. Oct 8, 2013 at 13:20

2 Answers 2


Threads share the same address space and code. However, for a variable in thread-local storage, each thread must have its own value; so the variable cannot be simply stored at a fixed address. There must be some indirection.

On 32-bit x86 CPU, with Linux, thread-local variables are accessed through the %gs segment register, which was hitherto unused by application code. Segments are a remnant of older times; Linux has always defined all segments to start at address 0 and extend over four gigabytes, allowing code to forget them completely. However, they are still there, and one of them (%gs) was revived to support thread-local storage. Indeed, all threads share the same memory, but each thread has its own set of register values.

The canary is a slot on the stack. Its purpose is to be overwritten when an overflow occurs, and the overflow is likely to impact the return address: the value which is written in the slot must be read back unchanged at the end of the function. That specific value is randomly chosen at the start of each thread, and each thread has its own; this means thread-local storage, so the canary value for a thread can be read by that thread at some fixed place relatively to %gs, as known by that thread.

  • Assuming, I'm an attacker and the stack is executable. I can easily read the canary value, overwrite the return address and place the canary value back on the stack as it was before. This would defeat canary protection. Right ? is there any better protection available ? Oct 8, 2013 at 13:23
  • 3
    Usually, the goal of the attacker is to get his code executed. His method to achieve execution is to overflow a buffer and overwrite the return address on the stack, so that execution jumps into his code when the function returns. However, the function will check the canary value before doing that jump. Sure, attacker's code can read and write the canary value, but only if it gets executed, so there's a chicken-and-egg problem here: the attacker cannot "read the canary" unless he can execute his own code, and he needs to read the canary so that he may execute his own code.
    – Tom Leek
    Oct 8, 2013 at 13:33

If your ultimate goal is to defeat the stack canary defense, there are other ways of changing the program control flow without even overwriting the canary value on the stack.

One such way of doing this is by exploiting the format string vulnerability in the program. The advantage of using a format string exploit is that (i) there's no need smash the stack, and (ii) it avoids defense such as stack canaries!

You can reed more about Exploiting Format String Vulnerabilities here.

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.