Re: [kernel-hardening] Re: [RFC PATCH 1/2] SROP Mitigation: Architecture independent code for signal cookies

[Daniel Micay <danielmicay@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

> Maybe secret is a bad term. It's supposed to be something userland
> can't guess 
> without doing a bunch of tricks. It's essentially supposed to work
> like a stack
> canary to protect against stack based buffer overflows. If someone
> can leak the
> stack canary in a stack based overflow, then do the overflow they can
> overcome 
> stack canaries as a mitigation. The same is true here. If someone can
> generate a
> signal, leak the signal cookie, then leak the address of the signal
> cookie, then
> undo the hash, then they can beat this mitigation. But we're arguing
> if someone
> can do everything we've said above they have already have nearly full
> control of
> a userland process and they won't really need SROP.
> 
> Essentially the signal cookie is just a way for the kernel to know if
> the 
> sigreturn it's handling is in response to a legitimate signal that
> the kernel 
> previously delivered without having to save a ton of state in
> current, or 
> elsewhere. 

Stack canary checking has a tiny performance budget though. It would be
interesting to know how SipHash fared in a case like this. It could be
specialized for fixed-size keys and potentially used elsewhere. Seems
like it would be more than fast enough.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]