Date:	Thu, 12 Dec 2013 17:52:24 +0100
From:	vegard.nossum@...cle.com
To:	linux-kernel@...r.kernel.org
Cc:	Vegard Nossum <vegard.nossum@...cle.com>,
	Tommi Rantala <tt.rantala@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andy Lutomirski <luto@...capital.net>,
	Kees Cook <keescook@...omium.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Alan Cox <alan@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jason Wang <jasowang@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	James Morris <james.l.morris@...cle.com>
Subject: [PATCH 1/9] Known exploit detection

From: Vegard Nossum <vegard.nossum@...cle.com>

The idea is simple -- since different kernel versions are vulnerable to
different root exploits, hackers most likely try multiple exploits before
they actually succeed.

Fixing an exploitable kernel bug usually means adding a check to see if
what a userspace program tried to do is allowed and makes sense (for
example, writing beyond the end of an array is a bug and can be fixed by
checking that the index provided by userspace is indeed within the array
bounds).

Instead of just returning an error when these extra checks fail, we can
also give the system administrator a heads up that somebody supplied this
invalid input that would have lead to elevated privileges on earlier
versions of the kernel.

This serves as a practical, low-overhead early-detection of malicious users
(and/or buggy userspace programs) to system administrators.

I propose limiting the annotation of known exploits to the most serious
type of exploit, namely where the attacker otherwise silently gains
root/elevated capabilities. For sure, there is little point in calling
exploit() where an older kernel would just panic or OOM.

I also propose to keep each exploit() annotation around for only ~5 years
after the bug was discovered/fixed. This will allow us to catch most of the
intrusion attempts while still not littering the kernel code forever.

Cc: Tommi Rantala <tt.rantala@...il.com>
Cc: Ingo Molnar <mingo@...nel.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Andy Lutomirski <luto@...capital.net>
Cc: Kees Cook <keescook@...omium.org>
Cc: Daniel Vetter <daniel.vetter@...ll.ch>
Cc: Alan Cox <alan@...ux.intel.com>
Cc: Ingo Molnar <mingo@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Jason Wang <jasowang@...hat.com>
Cc: David S. Miller <davem@...emloft.net>
Cc: Dan Carpenter <dan.carpenter@...cle.com>
Cc: James Morris <james.l.morris@...cle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@...cle.com>
---
 include/linux/exploit.h |   23 +++++++++++++++++++++++
 security/Kconfig        |   14 +++++++++++++-
 security/Makefile       |    2 ++
 security/exploit.c      |   28 ++++++++++++++++++++++++++++
 4 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/exploit.h
 create mode 100644 security/exploit.c

diff --git a/include/linux/exploit.h b/include/linux/exploit.h
new file mode 100644
index 0000000..a8df72a
--- /dev/null
+++ b/include/linux/exploit.h
@@ -0,0 +1,23 @@
+#ifndef _LINUX_EXPLOIT_H
+#define _LINUX_EXPLOIT_H
+
+#ifdef CONFIG_EXPLOIT_DETECTION
+extern void _exploit(const char *id);
+
+#define exploit_on(cond, id) \
+	do { \
+		if (unlikely(cond)) \
+			_exploit(id); \
+	} while (0)
+
+#else
+
+#define exploit_on(cond, id) \
+	do { \
+	} while (0)
+
+#endif
+
+#define exploit(id) exploit_on(true, id)
+
+#endif
diff --git a/security/Kconfig b/security/Kconfig
index e9c6ac7..a828dfb 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -167,5 +167,17 @@ config DEFAULT_SECURITY
 	default "yama" if DEFAULT_SECURITY_YAMA
 	default "" if DEFAULT_SECURITY_DAC
 
-endmenu
+config EXPLOIT_DETECTION
+	bool "Known exploit detection"
+	depends on PRINTK
+	default y
+	help
+	  This option enables the detection of users/programs who attempt to
+	  break into the kernel using publicly known (past) exploits.
+
+	  Upon detection, a message will be printed in the kernel log.
 
+	  The runtime overhead of enabling this option is extremely small, so
+	  you are recommended to say Y.
+
+endmenu
diff --git a/security/Makefile b/security/Makefile
index c26c81e..d152a1d 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -28,3 +28,5 @@ obj-$(CONFIG_CGROUP_DEVICE)		+= device_cgroup.o
 # Object integrity file lists
 subdir-$(CONFIG_INTEGRITY)		+= integrity
 obj-$(CONFIG_INTEGRITY)			+= integrity/built-in.o
+
+obj-$(CONFIG_EXPLOIT_DETECTION)		+= exploit.o
diff --git a/security/exploit.c b/security/exploit.c
new file mode 100644
index 0000000..a732613
--- /dev/null
+++ b/security/exploit.c
@@ -0,0 +1,28 @@
+#include <linux/cred.h>
+#include <linux/exploit.h>
+#include <linux/printk.h>
+#include <linux/ratelimit.h>
+#include <linux/sched.h>
+
+void _exploit(const char *id)
+{
+	/*
+	 * This function needs to be super defensive/conservative, since
+	 * userspace can easily get to it from several different contexts.
+	 * We don't want it to become an attack vector in itself!
+	 *
+	 * We can assume that we're in process context, but spinlocks may
+	 * be held, etc.
+	 */
+
+	struct task_struct *task = current;
+	pid_t pid = task_pid_nr(task);
+	uid_t uid = from_kuid(&init_user_ns, current_uid());
+	char comm[sizeof(task->comm)];
+
+	get_task_comm(comm, task);
+
+	pr_warn_ratelimited("warning: possible %s exploit attempt by pid=%u uid=%u comm=%s\n",
+		id, pid, uid, comm);
+}
+EXPORT_SYMBOL(_exploit);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists