From: Scotty Bauer <sbauer@eng.utah.edu>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
kernel-hardening@lists.openwall.com
Cc: abhiram@cs.utah.edu
Subject: [kernel-hardening] Re: [RFC PATCH 1/2] SROP Mitigation: Architecture independent code for signal cookies
Date: Mon, 1 Feb 2016 16:19:10 -0700 [thread overview]
Message-ID: <56AFE7EE.30100@eng.utah.edu> (raw)
In-Reply-To: <87twlsaw92.fsf@rasmusvillemoes.dk>
On 02/01/2016 03:42 PM, Rasmus Villemoes wrote:
> On Sun, Jan 24 2016, Scott Bauer <sbauer@eng.utah.edu> wrote:
>
>> This patch adds a per-process secret to the task struct which
>> will be used during signal delivery and during a sigreturn.
>> Also, logic is added in signal.c to generate, place, extract,
>> clear and verify the signal cookie.
>>
>>
>> +static unsigned long gen_sigcookie(unsigned long __user *location)
>> +{
>> +
>> + unsigned long sig_cookie;
>> +
>> + sig_cookie = (unsigned long) location ^ current->sig_cookie;
>> +
>> + sig_cookie = hash_long(sig_cookie, sizeof(sig_cookie) * BITS_PER_BYTE);
>> +
>> + return sig_cookie;
>> +}
>
> Is current->sig_cookie supposed to be secret, as in unknown to
> userspace? If so, this won't work, as hash_long (with BIT_PER_LONG as
> nbits parameter) is invertible (since we've just multiplied by an odd
> number and right-shifted by 0). Maybe xoring with some global secret
> afterwards would fix this, though I'm not sure.
>
> Rasmus
>
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.
next prev parent reply other threads:[~2016-02-01 23:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1453622354-50686-1-git-send-email-sbauer@eng.utah.edu>
2016-01-24 7:59 ` [kernel-hardening] [RFC PATCH 1/2] SROP Mitigation: Architecture independent code for signal cookies Scott Bauer
2016-01-28 23:25 ` Kees Cook
2016-01-29 21:26 ` Scotty Bauer
2016-02-01 22:42 ` [kernel-hardening] " Rasmus Villemoes
2016-02-01 23:19 ` Scotty Bauer [this message]
2016-02-02 9:15 ` Daniel Micay
2016-01-24 7:59 ` [kernel-hardening] [RFC PATCH 2/2] x86: SROP mitigation: implement " Scott Bauer
2016-01-28 23:31 ` Kees Cook
2016-01-30 14:34 ` Jann Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56AFE7EE.30100@eng.utah.edu \
--to=sbauer@eng.utah.edu \
--cc=abhiram@cs.utah.edu \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux@rasmusvillemoes.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).