* Jeff Law via Gcc: >> (1) We don't make any effort to hide the address of the canary value >> (typically &__stack_chk_guard, although some targets support >> alternatives). It's not obvious what “hiding” this address >> would actually mean in practice, since it would often be easily >> predictable from other non-secret addresses.
> Well, isn't that only when the target doesn't support storing the > guard in thread local storage?? ie, I don't think you can get it > consistently this way. The downside of the reference canary in the TCB is that the TCB is writable and (in glibc) on the stack. So if you overflow goes far enough, you can overwrite both the canary and the reference. With a bit more toolchain support, we could have a randomness relocation (processed by the dynamic loader) and put the reference value into .data.relro. Sure, its address maybe easier to guess, but you can easily have several canaries, and the overflow-into-the-TCB trick will no longer work. I think this is what OpenBSD did at some point. But targets that do not have convenient PC-relative addressing probably want to keep using the TCB approach. Thanks, Florian
