From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755924AbaEOVVF (ORCPT ); Thu, 15 May 2014 17:21:05 -0400 Received: from madhathacker.net ([178.63.244.10]:60270 "EHLO madhathacker.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754851AbaEOVVD (ORCPT ); Thu, 15 May 2014 17:21:03 -0400 Date: Thu, 15 May 2014 23:09:14 +0200 From: Erik Bosman To: linux-kernel@vger.kernel.org Subject: [PATCH 1/4] SROP mitigation: Architecture independent code for signal canaries Message-ID: <20140515210914.GA9536@pizzadoos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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 #include #include +#include #include #include @@ -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