[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1454404559.31183.10.camel@gmail.com>
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.
