All of lore.kernel.org
 help / color / mirror / Atom feed
From: Erik Bosman <erik@minemu.org>
To: linux-kernel@vger.kernel.org
Subject: [PATCH 1/4] SROP mitigation: Architecture independent code for signal canaries
Date: Thu, 15 May 2014 23:09:14 +0200	[thread overview]
Message-ID: <20140515210914.GA9536@pizzadoos.com> (raw)


Architecture independent code for signal canaries

Add support for canary values in user-space signal frames.  These canaries
function much like stack canaries/cookies, making it harder for an attacker to
fake a call to {rt_,}sigreturn()

This patch deals with architecture independent changes needed to support
these canaries.


These patches are meant to make Sigreturn Oriented Programming (SROP) a much
less attractive exploitation path.  In Sigreturn Oriented Programming, an
attacker causes a user-space program to call the sigreturn system call in order
to get complete control control over the entire userspace context in one go.

( see: http://www.cs.vu.nl/~herbertb/papers/srop_sp14.pdf )

While mitigating SROP will probably not stop determined attackers from
exploiting a program, as there's always the much more well-known Return
Oriented Programming, we still think SROP's relative ease warrants mitigation,
especially since the mitigation is so cheap.


Signed-off-by: Erik Bosman <erik@minemu.org>

---
 arch/Kconfig          | 16 ++++++++++++++++
 fs/exec.c             |  8 ++++++++
 include/linux/sched.h |  5 +++++
 3 files changed, 29 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 97ff872..8319984 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -399,6 +399,22 @@ config CC_STACKPROTECTOR_STRONG
 
 endchoice
 
+config HAVE_SIGNAL_CANARY
+	bool
+	help
+	  An arch should select this symbol if:
+	  - its struct sigframe contains a canary field
+	  - it has implemented signal canary checking
+
+config SIGNAL_CANARY
+	bool "signal canary"
+	default y
+	depends on HAVE_SIGNAL_CANARY
+	help
+	  Mitigate against a userland exploitation techinque called
+	  sigreturn oriented programming by putting a canary value on a
+	  signal's struct sigframe
+
 config HAVE_CONTEXT_TRACKING
 	bool
 	help
diff --git a/fs/exec.c b/fs/exec.c
index 476f3eb..883f456 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -56,6 +56,7 @@
 #include <linux/pipe_fs_i.h>
 #include <linux/oom.h>
 #include <linux/compat.h>
+#include <linux/random.h>
 
 #include <asm/uaccess.h>
 #include <asm/mmu_context.h>
@@ -1105,6 +1106,13 @@ void setup_new_exec(struct linux_binprm * bprm)
 	/* This is the point of no return */
 	current->sas_ss_sp = current->sas_ss_size = 0;
 
+#ifdef CONFIG_SIGNAL_CANARY
+	/* canary value to mitigate the use of sigreturn in (userland) exploits
+	 * get_random_int() should be random enough also for 64bit
+	 */
+	current->signal_canary = (unsigned long)get_random_int();
+#endif
+
 	if (uid_eq(current_euid(), current_uid()) && gid_eq(current_egid(), current_gid()))
 		set_dumpable(current->mm, SUID_DUMP_USER);
 	else
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c7..cb8b54b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1364,6 +1364,11 @@ struct task_struct {
 
 	unsigned long sas_ss_sp;
 	size_t sas_ss_size;
+
+#ifdef CONFIG_SIGNAL_CANARY
+	u32 signal_canary; /* sigreturn exploit mitigation */
+#endif
+
 	int (*notifier)(void *priv);
 	void *notifier_data;
 	sigset_t *notifier_mask;
-- 
1.9.1


             reply	other threads:[~2014-05-15 21:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15 21:09 Erik Bosman [this message]
2014-05-19 19:13 ` [PATCH 1/4] SROP mitigation: Architecture independent code for signal canaries Andy Lutomirski

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=20140515210914.GA9536@pizzadoos.com \
    --to=erik@minemu.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.