The described stack protection is quite Propolice-like and I think that
a similar attack would work on OpenBSD: corrupt a value in the stack,
use it to gain control in the executing function and its antecedents but
never return as that would activate the stack canary checks.
For this to work, an attacker would need to find 1) a function with a
stack-based overflow that 2) has a stack-allocated variable that is
amenable to their purpose. I'm sure these exist, but I have no idea how
common they are. Note that the attacks in the paper make use of the
stack layout used by C++ method calls which makes things quite a bit for
the attacker.
The thing that struck me most from the paper was how close Microsoft has
come to implementing a good set of protections and how they have managed
to screw them up by failing to turn them on everywhere. What use if DEP
or DLL load address randomisation if it isn't turned on everywhere? What
is the point of those (really good) heap consistency checks if you don't
abort() when they fail?
