Date: Tue, 02 Feb 2016 04:15:59 -0500 From: Daniel Micay <danielmicay@...il.com> To: kernel-hardening@...ts.openwall.com, Rasmus Villemoes <linux@...musvillemoes.dk> Cc: abhiram@...utah.edu Subject: Re: Re: [RFC PATCH 1/2] SROP Mitigation: Architecture independent code for signal cookies > 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. Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.