Steve Grubb wrote:
On Saturday, April 13, 2013 08:36:53 PM Kevin Kofler wrote:
> But it prevents (with probability (256^n-1)/256^n, where n is the size of
> the canary in bytes, which for n=4 is approximately .99999999976717)
> exploiting the overflows to change the return address of any C function.
There is the off chance that an attacker correctly guesses the canary
That's exactly why I wrote that it works with probability .99999999976717
(assuming a 32-bit canary), not 1. :-) Of course, the larger you make the
canary, the closer to 0 the probability of guessing it will be. And of
course, talking about probabilities only makes sense if the way the canary
gets generated can be reasonably considered random and uniformly
One thing that I found in doing a recent study was that there is a
system, scons, where our defaults are not getting used during compile. For
example, the zfs-fuse package uses the scons build system. It did not have
PIE, RELRO, stack protector, or FORTIFY_SOURCE anywhere. Anything else
that uses scons should be inspected for similar problems.
Yes, you need to use something like this:
and RPM_LD_FLAGS should also be handled (it currently isn't in that patch).