Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.