All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/9] Known exploit detection
@ 2013-12-12 16:52 vegard.nossum
  2013-12-12 16:52 ` [PATCH 2/9] exploit: report to audit subsystem when available vegard.nossum
                   ` (11 more replies)
  0 siblings, 12 replies; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel
  Cc: Vegard Nossum, Tommi Rantala, Ingo Molnar, Eric W. Biederman,
	Andy Lutomirski, Kees Cook, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

From: Vegard Nossum <vegard.nossum@oracle.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@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jason Wang <jasowang@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: James Morris <james.l.morris@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.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


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 2/9] exploit: report to audit subsystem when available
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
@ 2013-12-12 16:52 ` vegard.nossum
  2013-12-12 16:52 ` [PATCH 3/9] hfs: Known exploit detection for CVE-2011-4330 vegard.nossum
                   ` (10 subsequent siblings)
  11 siblings, 0 replies; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vegard Nossum

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

Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 include/uapi/linux/audit.h |    1 +
 security/exploit.c         |   16 ++++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 75cef3f..65811d4 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -131,6 +131,7 @@
 #define AUDIT_ANOM_PROMISCUOUS      1700 /* Device changed promiscuous mode */
 #define AUDIT_ANOM_ABEND            1701 /* Process ended abnormally */
 #define AUDIT_ANOM_LINK		    1702 /* Suspicious use of file links */
+#define AUDIT_ANOM_EXPLOIT          1703 /* Known exploit attempt */
 #define AUDIT_INTEGRITY_DATA	    1800 /* Data integrity verification */
 #define AUDIT_INTEGRITY_METADATA    1801 /* Metadata integrity verification */
 #define AUDIT_INTEGRITY_STATUS	    1802 /* Integrity enable status */
diff --git a/security/exploit.c b/security/exploit.c
index a732613..3d8ee5b 100644
--- a/security/exploit.c
+++ b/security/exploit.c
@@ -1,3 +1,4 @@
+#include <linux/audit.h>
 #include <linux/cred.h>
 #include <linux/exploit.h>
 #include <linux/printk.h>
@@ -19,9 +20,24 @@ void _exploit(const char *id)
 	pid_t pid = task_pid_nr(task);
 	uid_t uid = from_kuid(&init_user_ns, current_uid());
 	char comm[sizeof(task->comm)];
+#ifdef CONFIG_AUDIT
+	struct audit_buffer *ab;
+#endif
 
 	get_task_comm(comm, task);
 
+#ifdef CONFIG_AUDIT
+	ab = audit_log_start(NULL, GFP_ATOMIC, AUDIT_ANOM_EXPLOIT);
+	if (ab) {
+		audit_log_format(ab, "exploit id=%s pid=%u uid=%u auid=%u ses=%u comm=",
+			id, pid, uid,
+			from_kuid(&init_user_ns, audit_get_loginuid(task)),
+			audit_get_sessionid(task));
+		audit_log_untrustedstring(ab, comm);
+		audit_log_end(ab);
+	}
+#endif
+
 	pr_warn_ratelimited("warning: possible %s exploit attempt by pid=%u uid=%u comm=%s\n",
 		id, pid, uid, comm);
 }
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 3/9] hfs: Known exploit detection for CVE-2011-4330
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
  2013-12-12 16:52 ` [PATCH 2/9] exploit: report to audit subsystem when available vegard.nossum
@ 2013-12-12 16:52 ` vegard.nossum
  2013-12-13  8:00   ` Dan Carpenter
  2013-12-12 16:52 ` [PATCH 4/9] net: Known exploit detection for CVE-2012-2136 vegard.nossum
                   ` (9 subsequent siblings)
  11 siblings, 1 reply; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vegard Nossum, Dan Carpenter

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

See bc5b8a9003132ae44559edd63a1623b7b99dfb68.

Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 fs/hfs/trans.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/hfs/trans.c b/fs/hfs/trans.c
index b1ce4c7..2fe83f0 100644
--- a/fs/hfs/trans.c
+++ b/fs/hfs/trans.c
@@ -11,6 +11,7 @@
 
 #include <linux/types.h>
 #include <linux/nls.h>
+#include <linux/exploit.h>
 
 #include "hfs_fs.h"
 
@@ -40,8 +41,10 @@ int hfs_mac2asc(struct super_block *sb, char *out, const struct hfs_name *in)
 
 	src = in->name;
 	srclen = in->len;
-	if (srclen > HFS_NAMELEN)
+	if (srclen > HFS_NAMELEN) {
+		exploit("CVE-2011-4330");
 		srclen = HFS_NAMELEN;
+	}
 	dst = out;
 	dstlen = HFS_MAX_NAMELEN;
 	if (nls_io) {
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 4/9] net: Known exploit detection for CVE-2012-2136
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
  2013-12-12 16:52 ` [PATCH 2/9] exploit: report to audit subsystem when available vegard.nossum
  2013-12-12 16:52 ` [PATCH 3/9] hfs: Known exploit detection for CVE-2011-4330 vegard.nossum
@ 2013-12-12 16:52 ` vegard.nossum
  2013-12-12 16:52 ` [PATCH 5/9] hfsplus: Known exploit detection for CVE-2012-2319 vegard.nossum
                   ` (8 subsequent siblings)
  11 siblings, 0 replies; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vegard Nossum, Jason Wang, David S. Miller

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

See cc9b17ad29ecaa20bfe426a8d4dbfb94b13ff1cc.

Cc: Jason Wang <jasowang@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 net/core/sock.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index 0b39e7a..c16246f 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -117,6 +117,7 @@
 #include <linux/static_key.h>
 #include <linux/memcontrol.h>
 #include <linux/prefetch.h>
+#include <linux/exploit.h>
 
 #include <asm/uaccess.h>
 
@@ -1753,8 +1754,10 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
 	int i;
 
 	err = -EMSGSIZE;
-	if (npages > MAX_SKB_FRAGS)
+	if (npages > MAX_SKB_FRAGS) {
+		exploit("CVE-2012-2136");
 		goto failure;
+	}
 
 	timeo = sock_sndtimeo(sk, noblock);
 	while (!skb) {
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 5/9] hfsplus: Known exploit detection for CVE-2012-2319
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (2 preceding siblings ...)
  2013-12-12 16:52 ` [PATCH 4/9] net: Known exploit detection for CVE-2012-2136 vegard.nossum
@ 2013-12-12 16:52 ` vegard.nossum
  2013-12-13  1:40   ` Greg Kroah-Hartman
  2013-12-13 11:14   ` One Thousand Gnomes
  2013-12-12 16:52 ` [PATCH 6/9] x86: Known exploit detection for CVE-2013-0268 vegard.nossum
                   ` (7 subsequent siblings)
  11 siblings, 2 replies; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vegard Nossum, Greg Kroah-Hartman

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

See 6f24f892871acc47b40dd594c63606a17c714f77.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 fs/hfsplus/catalog.c |    2 ++
 fs/hfsplus/dir.c     |    3 +++
 2 files changed, 5 insertions(+)

diff --git a/fs/hfsplus/catalog.c b/fs/hfsplus/catalog.c
index 968ce41..5f47a1a 100644
--- a/fs/hfsplus/catalog.c
+++ b/fs/hfsplus/catalog.c
@@ -8,6 +8,7 @@
  * Handling of catalog records
  */
 
+#include <linux/exploit.h>
 
 #include "hfsplus_fs.h"
 #include "hfsplus_raw.h"
@@ -374,6 +375,7 @@ int hfsplus_rename_cat(u32 cnid,
 	if (err)
 		goto out;
 	if (src_fd.entrylength > sizeof(entry) || src_fd.entrylength < 0) {
+		exploit("CVE-2012-2319");
 		err = -EIO;
 		goto out;
 	}
diff --git a/fs/hfsplus/dir.c b/fs/hfsplus/dir.c
index 4a4fea0..2d5e283 100644
--- a/fs/hfsplus/dir.c
+++ b/fs/hfsplus/dir.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/errno.h>
+#include <linux/exploit.h>
 #include <linux/fs.h>
 #include <linux/slab.h>
 #include <linux/random.h>
@@ -152,6 +153,7 @@ static int hfsplus_readdir(struct file *file, struct dir_context *ctx)
 	}
 	if (ctx->pos == 1) {
 		if (fd.entrylength > sizeof(entry) || fd.entrylength < 0) {
+			exploit("CVE-2012-2319");
 			err = -EIO;
 			goto out;
 		}
@@ -186,6 +188,7 @@ static int hfsplus_readdir(struct file *file, struct dir_context *ctx)
 		}
 
 		if (fd.entrylength > sizeof(entry) || fd.entrylength < 0) {
+			exploit("CVE-2012-2319");
 			err = -EIO;
 			goto out;
 		}
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 6/9] x86: Known exploit detection for CVE-2013-0268
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (3 preceding siblings ...)
  2013-12-12 16:52 ` [PATCH 5/9] hfsplus: Known exploit detection for CVE-2012-2319 vegard.nossum
@ 2013-12-12 16:52 ` vegard.nossum
  2013-12-12 16:52 ` [PATCH 7/9] drm/i915: Known exploit detection for CVE-2013-0913 vegard.nossum
                   ` (6 subsequent siblings)
  11 siblings, 0 replies; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vegard Nossum, Alan Cox, Ingo Molnar

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

See c903f0456bc69176912dee6dd25c6a66ee1aed00.

Cc: Alan Cox <alan@linux.intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 arch/x86/kernel/msr.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 88458fa..fad04f1 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -37,6 +37,7 @@
 #include <linux/notifier.h>
 #include <linux/uaccess.h>
 #include <linux/gfp.h>
+#include <linux/exploit.h>
 
 #include <asm/processor.h>
 #include <asm/msr.h>
@@ -174,8 +175,10 @@ static int msr_open(struct inode *inode, struct file *file)
 	unsigned int cpu = iminor(file_inode(file));
 	struct cpuinfo_x86 *c;
 
-	if (!capable(CAP_SYS_RAWIO))
+	if (!capable(CAP_SYS_RAWIO)) {
+		exploit("CVE-2013-0268");
 		return -EPERM;
+	}
 
 	if (cpu >= nr_cpu_ids || !cpu_online(cpu))
 		return -ENXIO;	/* No such CPU */
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 7/9] drm/i915: Known exploit detection for CVE-2013-0913
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (4 preceding siblings ...)
  2013-12-12 16:52 ` [PATCH 6/9] x86: Known exploit detection for CVE-2013-0268 vegard.nossum
@ 2013-12-12 16:52 ` vegard.nossum
  2013-12-12 16:52 ` [PATCH 8/9] userns: Known exploit detection for CVE-2013-1959 vegard.nossum
                   ` (5 subsequent siblings)
  11 siblings, 0 replies; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vegard Nossum, Kees Cook, Daniel Vetter

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

See 3118a4f652c7b12c752f3222af0447008f9b2368.

Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index bf34577..48490c1 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -32,6 +32,7 @@
 #include "i915_trace.h"
 #include "intel_drv.h"
 #include <linux/dma_remapping.h>
+#include <linux/exploit.h>
 
 struct eb_objects {
 	struct list_head objects;
@@ -785,8 +786,10 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,
 		 * the worst case where we need to allocate the entire
 		 * relocation tree as a single array.
 		 */
-		if (exec[i].relocation_count > relocs_max - relocs_total)
+		if (exec[i].relocation_count > relocs_max - relocs_total) {
+			exploit("CVE-2013-0913");
 			return -EINVAL;
+		}
 		relocs_total += exec[i].relocation_count;
 
 		length = exec[i].relocation_count *
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 8/9] userns: Known exploit detection for CVE-2013-1959
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (5 preceding siblings ...)
  2013-12-12 16:52 ` [PATCH 7/9] drm/i915: Known exploit detection for CVE-2013-0913 vegard.nossum
@ 2013-12-12 16:52 ` vegard.nossum
  2013-12-12 16:52 ` [PATCH 9/9] perf: Known exploit detection for CVE-2013-2094 vegard.nossum
                   ` (4 subsequent siblings)
  11 siblings, 0 replies; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vegard Nossum, Eric W. Biederman, Andy Lutomirski

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

See 6708075f104c3c9b04b23336bb0366ca30c3931b and
e3211c120a85b792978bcb4be7b2886df18d27f0.

Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 kernel/user_namespace.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 13fb113..df7a51a 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -22,6 +22,7 @@
 #include <linux/ctype.h>
 #include <linux/projid.h>
 #include <linux/fs_struct.h>
+#include <linux/exploit.h>
 
 static struct kmem_cache *user_ns_cachep __read_mostly;
 
@@ -806,11 +807,15 @@ static bool new_idmap_permitted(const struct file *file,
 			kuid_t uid = make_kuid(ns->parent, id);
 			if (uid_eq(uid, file->f_cred->fsuid))
 				return true;
+
+			exploit_on(uid_eq(uid, current_fsuid()), "CVE-2013-1959");
 		}
 		else if (cap_setid == CAP_SETGID) {
 			kgid_t gid = make_kgid(ns->parent, id);
 			if (gid_eq(gid, file->f_cred->fsgid))
 				return true;
+
+			exploit_on(gid_eq(gid, current_fsgid()), "CVE-2013-1959");
 		}
 	}
 
@@ -822,9 +827,12 @@ static bool new_idmap_permitted(const struct file *file,
 	 * (CAP_SETUID or CAP_SETGID) over the parent user namespace.
 	 * And the opener of the id file also had the approprpiate capability.
 	 */
-	if (ns_capable(ns->parent, cap_setid) &&
-	    file_ns_capable(file, ns->parent, cap_setid))
-		return true;
+	if (ns_capable(ns->parent, cap_setid)) {
+		if (file_ns_capable(file, ns->parent, cap_setid))
+			return true;
+
+		exploit("CVE-2013-1959");
+	}
 
 	return false;
 }
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 9/9] perf: Known exploit detection for CVE-2013-2094
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (6 preceding siblings ...)
  2013-12-12 16:52 ` [PATCH 8/9] userns: Known exploit detection for CVE-2013-1959 vegard.nossum
@ 2013-12-12 16:52 ` vegard.nossum
  2013-12-12 19:06 ` [PATCH 1/9] Known exploit detection Theodore Ts'o
                   ` (3 subsequent siblings)
  11 siblings, 0 replies; 49+ messages in thread
From: vegard.nossum @ 2013-12-12 16:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vegard Nossum, Tommi Rantala, Ingo Molnar

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

See 8176cced706b5e5d15887584150764894e94e02f.

Cc: Tommi Rantala <tt.rantala@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 kernel/events/core.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 953c143..32b9383 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -39,6 +39,7 @@
 #include <linux/hw_breakpoint.h>
 #include <linux/mm_types.h>
 #include <linux/cgroup.h>
+#include <linux/exploit.h>
 
 #include "internal.h"
 
@@ -5721,6 +5722,7 @@ static void sw_perf_event_destroy(struct perf_event *event)
 static int perf_swevent_init(struct perf_event *event)
 {
 	u64 event_id = event->attr.config;
+	exploit_on((int) event_id < 0, "CVE-2013-2094");
 
 	if (event->attr.type != PERF_TYPE_SOFTWARE)
 		return -ENOENT;
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (7 preceding siblings ...)
  2013-12-12 16:52 ` [PATCH 9/9] perf: Known exploit detection for CVE-2013-2094 vegard.nossum
@ 2013-12-12 19:06 ` Theodore Ts'o
  2013-12-12 21:13   ` Kees Cook
                     ` (2 more replies)
  2013-12-13 12:54 ` Ingo Molnar
                   ` (2 subsequent siblings)
  11 siblings, 3 replies; 49+ messages in thread
From: Theodore Ts'o @ 2013-12-12 19:06 UTC (permalink / raw)
  To: vegard.nossum
  Cc: linux-kernel, Tommi Rantala, Ingo Molnar, Eric W. Biederman,
	Andy Lutomirski, Kees Cook, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
> From: Vegard Nossum <vegard.nossum@oracle.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.

Suppose we put put this into the mainstream kernel.  Wouldn't writers
of root kit adapt by checking for the kernel version to avoid checking
for exploits that are known not work?  So the question is whether the
additional complexity in the kernel is going to be worth it, since
once the attackers adapt, the benefits of trying to detect attacks for
mitigated exploits will be minimal.

Regards,

							- Ted

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 19:06 ` [PATCH 1/9] Known exploit detection Theodore Ts'o
@ 2013-12-12 21:13   ` Kees Cook
  2013-12-12 23:50     ` Ryan Mallon
                       ` (3 more replies)
  2013-12-13  8:20   ` Vegard Nossum
  2013-12-14 23:59   ` Ryan Mallon
  2 siblings, 4 replies; 49+ messages in thread
From: Kees Cook @ 2013-12-12 21:13 UTC (permalink / raw)
  To: Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Kees Cook,
	Daniel Vetter, Alan Cox, Greg Kroah-Hartman, Jason Wang,
	David S. Miller, Dan Carpenter, James Morris

On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>> From: Vegard Nossum <vegard.nossum@oracle.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.

I like this idea. It serves a few purposes, not the least of which is
very clearly marking in code where we've had problems, regardless of
the fact that it reports badness to the system owner. And I think
getting any additional notifications about bad behavior is a nice idea
too.

> Suppose we put put this into the mainstream kernel.  Wouldn't writers
> of root kit adapt by checking for the kernel version to avoid checking
> for exploits that are known not work?  So the question is whether the
> additional complexity in the kernel is going to be worth it, since
> once the attackers adapt, the benefits of trying to detect attacks for
> mitigated exploits will be minimal.

This is already somewhat the case, but I think this idea still has
value. The reality of the situation is that the kernels running on an
end-user's system is rarely a stock upstream kernel. As a result, they
usually have organization-specific versioning, which makes
version-only autodetection useless to an attacker. While it is
possible to keep track of all distro versions in a massive table, even
the public exploits rarely do this, instead focusing on maybe one or
two distros. But when attacking systems with kernels built custom by
various organizations that don't publish their kernel trees, it
becomes impossible to rely on just the version. Given all the forks,
and stable vs mainline, and backported patches vs not, the version
tends to only give a gross ball-park idea. Probing is still useful to
an attacker, and this proposes reporting those probes.

I like it. I like how lightweight it is, and I like that it can be
trivially compiled out. My concerns would be:

- how do we avoid bikeshedding about which exploits are "serious
enough" to trigger a report?

- who will keep adding these triggers going forward?

I'm more than happy to assist with adding future triggers, but I don't
want to be the only person doing it. :)

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 21:13   ` Kees Cook
@ 2013-12-12 23:50     ` Ryan Mallon
  2013-12-12 23:55       ` Kees Cook
                         ` (2 more replies)
  2013-12-13  0:25     ` Dave Jones
                       ` (2 subsequent siblings)
  3 siblings, 3 replies; 49+ messages in thread
From: Ryan Mallon @ 2013-12-12 23:50 UTC (permalink / raw)
  To: Kees Cook, Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Daniel Vetter,
	Alan Cox, Greg Kroah-Hartman, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On 13/12/13 08:13, Kees Cook wrote:
> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>>> From: Vegard Nossum <vegard.nossum@oracle.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.
> 
> I like this idea. It serves a few purposes, not the least of which is
> very clearly marking in code where we've had problems, regardless of
> the fact that it reports badness to the system owner. And I think
> getting any additional notifications about bad behavior is a nice idea
> too.

Though, if an attacker is running through a series of exploits, and one
eventually succeeds then the first thing to do would be to clean traces
of the _exploit() notifications from the syslog. Since running through a
series of exploits is pretty quick, this can probably all be done before
the sysadmin ever notices.

The _exploit() notifications could also be used to spam the syslogs.
Although they are individually ratelimited, if there are enough
_exploit() markers in the kernel then an annoying person can cycle
through them all to generate large amounts of useless syslog.

~Ryan


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 23:50     ` Ryan Mallon
@ 2013-12-12 23:55       ` Kees Cook
  2013-12-13 11:10         ` One Thousand Gnomes
  2013-12-13  9:20       ` Vegard Nossum
  2013-12-13 13:06       ` Ingo Molnar
  2 siblings, 1 reply; 49+ messages in thread
From: Kees Cook @ 2013-12-12 23:55 UTC (permalink / raw)
  To: Ryan Mallon
  Cc: Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Daniel Vetter,
	Alan Cox, Greg Kroah-Hartman, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On Thu, Dec 12, 2013 at 3:50 PM, Ryan Mallon <rmallon@gmail.com> wrote:
> On 13/12/13 08:13, Kees Cook wrote:
>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>>>> From: Vegard Nossum <vegard.nossum@oracle.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.
>>
>> I like this idea. It serves a few purposes, not the least of which is
>> very clearly marking in code where we've had problems, regardless of
>> the fact that it reports badness to the system owner. And I think
>> getting any additional notifications about bad behavior is a nice idea
>> too.
>
> Though, if an attacker is running through a series of exploits, and one
> eventually succeeds then the first thing to do would be to clean traces
> of the _exploit() notifications from the syslog. Since running through a
> series of exploits is pretty quick, this can probably all be done before
> the sysadmin ever notices.

Sure, but many organizations have centralized network syslog, so
unless the attack can spread to those machines too (which are usually
more locked down), the attacker will leave traces.

> The _exploit() notifications could also be used to spam the syslogs.
> Although they are individually ratelimited, if there are enough
> _exploit() markers in the kernel then an annoying person can cycle
> through them all to generate large amounts of useless syslog.

Totally true, but there's a million way to DoS a local machine. At
least this way shows who's doing it. It's the DoSes that don't include
attribution that I worry about. :)

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 21:13   ` Kees Cook
  2013-12-12 23:50     ` Ryan Mallon
@ 2013-12-13  0:25     ` Dave Jones
  2013-12-13  0:45       ` Andy Lutomirski
  2013-12-13  1:42       ` Greg Kroah-Hartman
  2013-12-13  5:27     ` Theodore Ts'o
  2013-12-13  9:12     ` Vegard Nossum
  3 siblings, 2 replies; 49+ messages in thread
From: Dave Jones @ 2013-12-13  0:25 UTC (permalink / raw)
  To: Kees Cook
  Cc: Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Daniel Vetter,
	Alan Cox, Greg Kroah-Hartman, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:

 > - who will keep adding these triggers going forward?

also..

- Who will test the existing triggers are doing the right thing when related code changes.

We could add something to tests/ maybe for each exploit() addition, to make sure some
new change isn't introducing an oopsable (or worse!) bug in the actual exploit test.

It does mean someone needs to be regularly running said tests though.
As history has shown, things like nx_test have been broken for months at a time without
anyone complaining.  Perhaps Fenguang Wu can add something to the daily test runs if
we add an over all "make test-secure" target or similar.

	Dave


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  0:25     ` Dave Jones
@ 2013-12-13  0:45       ` Andy Lutomirski
  2013-12-13  1:42       ` Greg Kroah-Hartman
  1 sibling, 0 replies; 49+ messages in thread
From: Andy Lutomirski @ 2013-12-13  0:45 UTC (permalink / raw)
  To: Dave Jones, Kees Cook, Theodore Ts'o, vegard.nossum, LKML,
	Tommi Rantala, Ingo Molnar, Eric W. Biederman, Andy Lutomirski,
	Daniel Vetter, Alan Cox, Greg Kroah-Hartman, Jason Wang,
	David S. Miller, Dan Carpenter, James Morris

On Thu, Dec 12, 2013 at 4:25 PM, Dave Jones <davej@redhat.com> wrote:
> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>
>  > - who will keep adding these triggers going forward?
>
> also..
>
> - Who will test the existing triggers are doing the right thing when related code changes.
>
> We could add something to tests/ maybe for each exploit() addition, to make sure some
> new change isn't introducing an oopsable (or worse!) bug in the actual exploit test.
>
> It does mean someone needs to be regularly running said tests though.
> As history has shown, things like nx_test have been broken for months at a time without
> anyone complaining.  Perhaps Fenguang Wu can add something to the daily test runs if
> we add an over all "make test-secure" target or similar.

This has the added benefit of making sure that the exploits don't
(trivially) regress.

--Andy

>
>         Dave
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/9] hfsplus: Known exploit detection for CVE-2012-2319
  2013-12-12 16:52 ` [PATCH 5/9] hfsplus: Known exploit detection for CVE-2012-2319 vegard.nossum
@ 2013-12-13  1:40   ` Greg Kroah-Hartman
  2013-12-13 11:14   ` One Thousand Gnomes
  1 sibling, 0 replies; 49+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-13  1:40 UTC (permalink / raw)
  To: vegard.nossum; +Cc: linux-kernel

On Thu, Dec 12, 2013 at 05:52:28PM +0100, vegard.nossum@oracle.com wrote:
> From: Vegard Nossum <vegard.nossum@oracle.com>
> 
> See 6f24f892871acc47b40dd594c63606a17c714f77.

Please put the "name" of the git commit after it, to make it easier to
determine what this is referring to.

> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> ---
>  fs/hfsplus/catalog.c |    2 ++
>  fs/hfsplus/dir.c     |    3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/fs/hfsplus/catalog.c b/fs/hfsplus/catalog.c
> index 968ce41..5f47a1a 100644
> --- a/fs/hfsplus/catalog.c
> +++ b/fs/hfsplus/catalog.c
> @@ -8,6 +8,7 @@
>   * Handling of catalog records
>   */
>  
> +#include <linux/exploit.h>
>  
>  #include "hfsplus_fs.h"
>  #include "hfsplus_raw.h"
> @@ -374,6 +375,7 @@ int hfsplus_rename_cat(u32 cnid,
>  	if (err)
>  		goto out;
>  	if (src_fd.entrylength > sizeof(entry) || src_fd.entrylength < 0) {
> +		exploit("CVE-2012-2319");

So, any invalid data here means this was an expoit attempt?  No, not
true, corrupted filesystems could also cause this, right?

Same for the other instances here.

greg k-h

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  0:25     ` Dave Jones
  2013-12-13  0:45       ` Andy Lutomirski
@ 2013-12-13  1:42       ` Greg Kroah-Hartman
  2013-12-13  1:44         ` Dave Jones
                           ` (3 more replies)
  1 sibling, 4 replies; 49+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-13  1:42 UTC (permalink / raw)
  To: Dave Jones, Kees Cook, Theodore Ts'o, vegard.nossum, LKML,
	Tommi Rantala, Ingo Molnar, Eric W. Biederman, Andy Lutomirski,
	Daniel Vetter, Alan Cox, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> 
>  > - who will keep adding these triggers going forward?
> 
> also..
> 
> - Who will test the existing triggers are doing the right thing when related code changes.

And:
  - how do you determine an "expoit attempt" from "userspace program
    doing something stupid" / "corrupted filesytem mounted"?

I really don't like this, it means that our normal error handling for
userspace data will suddenly all have CVE entries on them over time.
How is that helpful to anyone?

Think ahead in 10-20 years, what is the code paths going to look like
then?  Horrible...

greg k-h

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  1:42       ` Greg Kroah-Hartman
@ 2013-12-13  1:44         ` Dave Jones
  2013-12-13  5:09         ` James Morris
                           ` (2 subsequent siblings)
  3 siblings, 0 replies; 49+ messages in thread
From: Dave Jones @ 2013-12-13  1:44 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Kees Cook, Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Daniel Vetter,
	Alan Cox, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On Thu, Dec 12, 2013 at 05:42:20PM -0800, Greg Kroah-Hartman wrote:

 > I really don't like this, it means that our normal error handling for
 > userspace data will suddenly all have CVE entries on them over time.
 > How is that helpful to anyone?
 > 
 > Think ahead in 10-20 years, what is the code paths going to look like
 > then?  Horrible...

consider it incentive not to add any new CVEs :)

	Dave


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  1:42       ` Greg Kroah-Hartman
  2013-12-13  1:44         ` Dave Jones
@ 2013-12-13  5:09         ` James Morris
  2013-12-13  5:46           ` Theodore Ts'o
  2013-12-13 10:21           ` Vegard Nossum
  2013-12-13 10:31         ` Alexander Holler
  2013-12-13 17:58         ` Kees Cook
  3 siblings, 2 replies; 49+ messages in thread
From: James Morris @ 2013-12-13  5:09 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Dave Jones, Kees Cook, Theodore Ts'o, vegard.nossum, LKML,
	Tommi Rantala, Ingo Molnar, Eric W. Biederman, Andy Lutomirski,
	Daniel Vetter, Alan Cox, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On Thu, 12 Dec 2013, Greg Kroah-Hartman wrote:

> On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
> > On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> > 
> >  > - who will keep adding these triggers going forward?
> > 

I think we'd need to have someone commit to maintaining this long term 
before seriously considering it as part of mainline.  Over time it will 
become increasingly useless if new triggers aren't added.

What happens when code is refactored, who refactors the triggers?


> > also..
> > 
> > - Who will test the existing triggers are doing the right thing when related code changes.
> 
> And:
>   - how do you determine an "expoit attempt" from "userspace program
>     doing something stupid" / "corrupted filesytem mounted"?
> 

Right, and if there are enough false positives, it'll end up being quite 
useless.

I suspect this kind of thing is better done in userspace anti-malware 
scanning.

> I really don't like this, it means that our normal error handling for
> userspace data will suddenly all have CVE entries on them over time.
> How is that helpful to anyone?
> 
> Think ahead in 10-20 years, what is the code paths going to look like
> then?  Horrible...

Agree.

This could make an interesting research project outside of the kernel. It 
doesn't belong in mainline without at least first being proven in the 
field and also properly maintained long term, if at all.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 21:13   ` Kees Cook
  2013-12-12 23:50     ` Ryan Mallon
  2013-12-13  0:25     ` Dave Jones
@ 2013-12-13  5:27     ` Theodore Ts'o
  2013-12-13  9:32       ` Jiri Kosina
  2013-12-13 18:07       ` Kees Cook
  2013-12-13  9:12     ` Vegard Nossum
  3 siblings, 2 replies; 49+ messages in thread
From: Theodore Ts'o @ 2013-12-13  5:27 UTC (permalink / raw)
  To: Kees Cook
  Cc: vegard.nossum, LKML, Tommi Rantala, Ingo Molnar,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> > Suppose we put put this into the mainstream kernel.  Wouldn't writers
> > of root kit adapt by checking for the kernel version to avoid checking
> > for exploits that are known not work?  So the question is whether the
> > additional complexity in the kernel is going to be worth it, since
> > once the attackers adapt, the benefits of trying to detect attacks for
> > mitigated exploits will be minimal.
> 
> This is already somewhat the case, but I think this idea still has
> value. The reality of the situation is that the kernels running on an
> end-user's system is rarely a stock upstream kernel. As a result, they
> usually have organization-specific versioning, which makes
> version-only autodetection useless to an attacker.

Most organizations can't afford to have an in-house kernel team
providing specialized kernels for their server farms or their
customized desktop distributions.  :-)

Some places have publically said that they do this; Google has
publically talked about Goobuntu and their data center production
kernels, and some financial firms on Wall Street have boasted about
how they run with a customized kernel --- although other financial
firms have said they don't want to do that because they don't want to
void their support contract with Red Hat or SuSE.  I suspect that at
most shopes, though, the latter is going to be far more common than
the former.

Practically speaking, testing for various distribution kernel
versions, as well as specific ChromeOS and Android kernel versions,
wouldn't be that difficult for an attacker, and would probably allow
them to avoid detection for 99% of the Linux systems found in the
wild.  It would certainly be useful for detecting attempted attacks
for private kernels where the configuration and security patches
applied for some internal kernel are not public --- and if that caused
the botnet author to be paranoid enough to avoid attacking machines
which didn't have a known distribution kernel that definitely had that
vulnerability, it would certainly be good for people running their own
privately maintained kernel image.  So if this increases the market
demand for kernel programmers, that's a good thing, right?   :-)

I am at least partially sympathetic to the concerns which Greg has
raised, though.  At the very least the exploit() tags should also have
a date stamp, so it we can automatically scan for exploit tags whose
time has come and gone.

I'm also worried about false positives getting triggered due to
userspace bugs, corrupted file systems, or other random hardare
failures.  This could be a support headache for distributions, and
possibly for other kernel support organizations as well.  Given that
attack authors will probably adapt their explots to only try them on
known RHEL/SLES kernels that have the bug, it wouldn't surprise me if
enterprise distro's such as Red Hat and SuSE will very likely simply
not turn on the config option.

This could probably be mitigated by adding more sophisticated
hueristics, but then we could potentially end up changing a one-line
exploit() or exploit_on() call to something substantially more
bloated, and at that point we will seriously be uglifying the code and
making it harder to read and maintain.  So despite the risks of false
positives, I suspect we will want to keep the inserted exploit() calls
as simple and as lightweight as possible.

          	       	     	    	 - Ted

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  5:09         ` James Morris
@ 2013-12-13  5:46           ` Theodore Ts'o
  2013-12-13 13:19             ` Ingo Molnar
  2013-12-13 10:21           ` Vegard Nossum
  1 sibling, 1 reply; 49+ messages in thread
From: Theodore Ts'o @ 2013-12-13  5:46 UTC (permalink / raw)
  To: James Morris
  Cc: Greg Kroah-Hartman, Dave Jones, Kees Cook, vegard.nossum, LKML,
	Tommi Rantala, Ingo Molnar, Eric W. Biederman, Andy Lutomirski,
	Daniel Vetter, Alan Cox, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On Fri, Dec 13, 2013 at 04:09:06PM +1100, James Morris wrote:
> 
> I think we'd need to have someone commit to maintaining this long term 
> before seriously considering it as part of mainline.  Over time it will 
> become increasingly useless if new triggers aren't added.
> 
> What happens when code is refactored, who refactors the triggers?

We would definitely need to have test cases which deliberately trips
the triggers, which would be run regularly (which means they would
need to be included in the kernel tree), or else it's very likely as
the code gets refactor or even just modiied, the exploit() calls might
end up getting moved to the wrong place, or otherwise
deactivated/denatured.

> I suspect this kind of thing is better done in userspace anti-malware 
> scanning.

I was wondering if we could do something using syscall tracing, or via
some systemtap kind of thing.  The problem is that this would be
painful for certain system calls, especially those that are
multiplexed, such as futex, or decode complex data structures based
via a pointer, or are context-dependent, such as ioctl's.

If it could be kept to a single exploit() line added to a return path,
the impact on code complexity and maintainability should be minimal.

I'm still a little dubious about the size of benefit that trying to
maintain these exploit() markets would provide, and whether it would
ultimately be worth the cost.

						- Ted

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 3/9] hfs: Known exploit detection for CVE-2011-4330
  2013-12-12 16:52 ` [PATCH 3/9] hfs: Known exploit detection for CVE-2011-4330 vegard.nossum
@ 2013-12-13  8:00   ` Dan Carpenter
  0 siblings, 0 replies; 49+ messages in thread
From: Dan Carpenter @ 2013-12-13  8:00 UTC (permalink / raw)
  To: vegard.nossum; +Cc: linux-kernel

On Thu, Dec 12, 2013 at 05:52:26PM +0100, vegard.nossum@oracle.com wrote:
> From: Vegard Nossum <vegard.nossum@oracle.com>

No need for this because we can get that from the email.

> 
> See bc5b8a9003132ae44559edd63a1623b7b99dfb68.

Put some human readable text in your changelog like the patch title or
something.

regards
dan carpenter


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 19:06 ` [PATCH 1/9] Known exploit detection Theodore Ts'o
  2013-12-12 21:13   ` Kees Cook
@ 2013-12-13  8:20   ` Vegard Nossum
  2013-12-14 23:59   ` Ryan Mallon
  2 siblings, 0 replies; 49+ messages in thread
From: Vegard Nossum @ 2013-12-13  8:20 UTC (permalink / raw)
  To: Theodore Ts'o, linux-kernel, Tommi Rantala, Ingo Molnar,
	Eric W. Biederman, Andy Lutomirski, Kees Cook, Daniel Vetter,
	Alan Cox, Greg Kroah-Hartman, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On 12/12/2013 08:06 PM, Theodore Ts'o wrote:
> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>> The idea is simple -- since different kernel versions are vulnerable to
>> different root exploits, hackers most likely try multiple exploits before
>> they actually succeed.
>
> Suppose we put put this into the mainstream kernel.  Wouldn't writers
> of root kit adapt by checking for the kernel version to avoid checking
> for exploits that are known not work?  So the question is whether the
> additional complexity in the kernel is going to be worth it, since
> once the attackers adapt, the benefits of trying to detect attacks for
> mitigated exploits will be minimal.

Yeah, you could probably avoid detection by being more careful. But I 
think it would be worth making it harder; I'd argue that the "additional 
complexity" in this case is minimal, since we are mostly talking about 
~1 line added to an error path for each critical vulnerability.


Vegard

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 21:13   ` Kees Cook
                       ` (2 preceding siblings ...)
  2013-12-13  5:27     ` Theodore Ts'o
@ 2013-12-13  9:12     ` Vegard Nossum
  2013-12-13 13:27       ` Ingo Molnar
  3 siblings, 1 reply; 49+ messages in thread
From: Vegard Nossum @ 2013-12-13  9:12 UTC (permalink / raw)
  To: Kees Cook, Theodore Ts'o, LKML, Tommi Rantala, Ingo Molnar,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On 12/12/2013 10:13 PM, Kees Cook wrote:
> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>>> The idea is simple -- since different kernel versions are vulnerable to
>>> different root exploits, hackers most likely try multiple exploits before
>>> they actually succeed.
>
> I like it. I like how lightweight it is, and I like that it can be
> trivially compiled out. My concerns would be:
>
> - how do we avoid bikeshedding about which exploits are "serious
> enough" to trigger a report?

Well, I've already suggested that only bugs that potentially lead to 
privilege escalation/intrusion (local and remote) would be candidates. 
This probably includes any kind of buffer overflow or "wild write" bug.

Clearly, a bug should also be present over a complete release cycle 
before it's worth annotating. A bug introduced in -rc1 and fixed in -rc5 
is NOT a candidate.

> - who will keep adding these triggers going forward?
>
> I'm more than happy to assist with adding future triggers, but I don't
> want to be the only person doing it. :)

Thanks! Without making any promises, I am fairly sure that my team has 
an interest in adding and maintaining triggers.

Based on some of the later comments in this thread, I think it might be 
a good idea to keep a separate git tree for the triggers for a while. 
You are of course welcome to contribute in any case.


Vegard

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 23:50     ` Ryan Mallon
  2013-12-12 23:55       ` Kees Cook
@ 2013-12-13  9:20       ` Vegard Nossum
  2013-12-13 22:49         ` Ryan Mallon
  2013-12-13 13:06       ` Ingo Molnar
  2 siblings, 1 reply; 49+ messages in thread
From: Vegard Nossum @ 2013-12-13  9:20 UTC (permalink / raw)
  To: Ryan Mallon, Kees Cook, Theodore Ts'o, LKML, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Daniel Vetter,
	Alan Cox, Greg Kroah-Hartman, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On 12/13/2013 12:50 AM, Ryan Mallon wrote:
> On 13/12/13 08:13, Kees Cook wrote:
>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>>>> The idea is simple -- since different kernel versions are vulnerable to
>>>> different root exploits, hackers most likely try multiple exploits before
>>>> they actually succeed.
>
> The _exploit() notifications could also be used to spam the syslogs.
> Although they are individually ratelimited, if there are enough
> _exploit() markers in the kernel then an annoying person can cycle
> through them all to generate large amounts of useless syslog.

They are rate limited collectively, not individually, so this should not 
be an issue.


Vegard

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  5:27     ` Theodore Ts'o
@ 2013-12-13  9:32       ` Jiri Kosina
  2013-12-13 18:07       ` Kees Cook
  1 sibling, 0 replies; 49+ messages in thread
From: Jiri Kosina @ 2013-12-13  9:32 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: Kees Cook, vegard.nossum, LKML, Tommi Rantala, Ingo Molnar,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On Fri, 13 Dec 2013, Theodore Ts'o wrote:

> I am at least partially sympathetic to the concerns which Greg has
> raised, though.  At the very least the exploit() tags should also have
> a date stamp, so it we can automatically scan for exploit tags whose
> time has come and gone.

At least this is a non-issue, if you supply the CVE string (as 
Vegard's patchset proposed), as it implicitly contains a year it has been 
issued (which seems like sufficient granularity for this kind of 
tracking).

> I'm also worried about false positives getting triggered due to
> userspace bugs, corrupted file systems, or other random hardare
> failures.  This could be a support headache for distributions, and
> possibly for other kernel support organizations as well.  Given that
> attack authors will probably adapt their explots to only try them on
> known RHEL/SLES kernels that have the bug, it wouldn't surprise me if
> enterprise distro's such as Red Hat and SuSE will very likely simply
> not turn on the config option.

I of course can't really now talk officially about what we would do, as no 
internal discussion about this has happened, but my gut feeling is that we 
will be turning it off, exactly due to the reasons outlined above. 

We want to maintain sanity of our support engineers and not let them be 
drowned in figuring out these being false positives and then going through 
the pain of explaining this to the customer.

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  5:09         ` James Morris
  2013-12-13  5:46           ` Theodore Ts'o
@ 2013-12-13 10:21           ` Vegard Nossum
  1 sibling, 0 replies; 49+ messages in thread
From: Vegard Nossum @ 2013-12-13 10:21 UTC (permalink / raw)
  To: James Morris, Greg Kroah-Hartman
  Cc: Dave Jones, Kees Cook, Theodore Ts'o, LKML, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Daniel Vetter,
	Alan Cox, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On 12/13/2013 06:09 AM, James Morris wrote:
> On Thu, 12 Dec 2013, Greg Kroah-Hartman wrote:
>
>> On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
>>> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>>>
>>>   > - who will keep adding these triggers going forward?
>>>
>
> I think we'd need to have someone commit to maintaining this long term
> before seriously considering it as part of mainline.  Over time it will
> become increasingly useless if new triggers aren't added.

Based on your input, we (the Ksplice team) will probably set up a public 
git repository where we maintain these patches on top of the latest 
released kernel.

> What happens when code is refactored, who refactors the triggers?
>
>>> also..
>>>
>>> - Who will test the existing triggers are doing the right thing when related code changes.
>>

I don't think refactoring or maintenance is a huge issue. The triggers 
are mostly one-liners in the error path of a specific input validation 
check.

I haven't maintained these patches for a very long time, but at least 
nothing came up in the six months of development that I've had these 
patches sitting for.

I'd say the person doing the refactoring should also take care to 
maintain the trigger, but if it just doesn't make sense anymore, it can 
also just be taken out.

In any case, maintaining a public git repository alongside mainline will 
give us some experience with overcoming refactoring/code changes.

>> And:
>>    - how do you determine an "expoit attempt" from "userspace program
>>      doing something stupid" / "corrupted filesytem mounted"?
>>
>
> Right, and if there are enough false positives, it'll end up being quite
> useless.
>
> I suspect this kind of thing is better done in userspace anti-malware
> scanning.
>
>> I really don't like this, it means that our normal error handling for
>> userspace data will suddenly all have CVE entries on them over time.
>> How is that helpful to anyone?
>>
>> Think ahead in 10-20 years, what is the code paths going to look like
>> then?  Horrible...
>
> Agree.
>
> This could make an interesting research project outside of the kernel. It
> doesn't belong in mainline without at least first being proven in the
> field and also properly maintained long term, if at all.
>

I already suggested a 5-year expiry date for any triggers we add. It's 
easy to retire them based on the CVE (or other) identifier that includes 
the year (possibly combined with git blame and friends).

I also think the set of triggers should be limited to serious bugs that 
could lead to privilege escalation. There are not THAT many of them. 
There are probably fewer than 20 every year, which would cap the total 
number of triggers at 100 in the whole kernel at any given time.

The point is NOT to add triggers in every error path in the kernel, of 
course not. Triggers should only be added where there's a real 
possibility of the bug actually being exploited. I thought about 
requiring a proof-of-concept exploit code to be provided with each 
trigger as well, but that could be too hard to be useful in practice, 
since actually exploiting any given potential privilege escalation bug 
could require a lot of ingenuity.

Thanks,


Vegard

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  1:42       ` Greg Kroah-Hartman
  2013-12-13  1:44         ` Dave Jones
  2013-12-13  5:09         ` James Morris
@ 2013-12-13 10:31         ` Alexander Holler
  2013-12-13 11:48           ` Dan Carpenter
  2013-12-13 17:58         ` Kees Cook
  3 siblings, 1 reply; 49+ messages in thread
From: Alexander Holler @ 2013-12-13 10:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Dave Jones, Kees Cook, Theodore Ts'o,
	vegard.nossum, LKML, Tommi Rantala, Ingo Molnar,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Jason Wang, David S. Miller, Dan Carpenter, James Morris

Am 13.12.2013 02:42, schrieb Greg Kroah-Hartman:
> On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
>> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>>
>>   > - who will keep adding these triggers going forward?
>>
>> also..
>>
>> - Who will test the existing triggers are doing the right thing when related code changes.
>
> And:
>    - how do you determine an "expoit attempt" from "userspace program
>      doing something stupid" / "corrupted filesytem mounted"?
>

And what makes a bug marked as exploit more serious than the all the 
other bugs? I assume there exists many, many more serious (fixed or not) 
bugs than just those which found there way into the CVE database. And I 
think most bugs are getting fixed without such a number and often even 
those for which CVEs do exist, the CVE is unknown to the dev(s).

So people might be think they are safe if they call some tool which 
tests for existing CVEs which are marked as such inside the kernel, 
which just isn't the reality.

And, as already mentioned, those CVE marks might block refactoring, as 
devs might become careful to remove such a CVE marker when code changed.

I've never seen a comment inside the kernel sources which does point to 
a CVE, so I assume there already does exists some agreement about not 
doing so.

Regards,

Alexander Holler


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 23:55       ` Kees Cook
@ 2013-12-13 11:10         ` One Thousand Gnomes
  2013-12-13 14:21           ` Jiri Kosina
  0 siblings, 1 reply; 49+ messages in thread
From: One Thousand Gnomes @ 2013-12-13 11:10 UTC (permalink / raw)
  To: Kees Cook
  Cc: Ryan Mallon, Theodore Ts'o, vegard.nossum, LKML,
	Tommi Rantala, Ingo Molnar, Eric W. Biederman, Andy Lutomirski,
	Daniel Vetter, Alan Cox, Greg Kroah-Hartman, Jason Wang,
	David S. Miller, Dan Carpenter, James Morris

> Totally true, but there's a million way to DoS a local machine. At
> least this way shows who's doing it. It's the DoSes that don't include
> attribution that I worry about. :)

So long as they compile out to nothingness for all the systems where this
stuff is useless (ie most of them because they are embedded or phones
etc) I don't see a big problem.

Note however if you trip one of those in any code with the console lock
held and your log goes to the consoles due to printk level or similar
you'll probably hang the box.

There are some other lock sequences that are going to do that too, so it
can't be placed arbitarily but will need the locking assumptions for each
non-obvious one documented clearly.

Alan

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/9] hfsplus: Known exploit detection for CVE-2012-2319
  2013-12-12 16:52 ` [PATCH 5/9] hfsplus: Known exploit detection for CVE-2012-2319 vegard.nossum
  2013-12-13  1:40   ` Greg Kroah-Hartman
@ 2013-12-13 11:14   ` One Thousand Gnomes
  1 sibling, 0 replies; 49+ messages in thread
From: One Thousand Gnomes @ 2013-12-13 11:14 UTC (permalink / raw)
  To: vegard.nossum; +Cc: linux-kernel, Greg Kroah-Hartman

On Thu, 12 Dec 2013 17:52:28 +0100
vegard.nossum@oracle.com wrote:

> From: Vegard Nossum <vegard.nossum@oracle.com>
> 
> See 6f24f892871acc47b40dd594c63606a17c714f77.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> ---
>  fs/hfsplus/catalog.c |    2 ++
>  fs/hfsplus/dir.c     |    3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/fs/hfsplus/catalog.c b/fs/hfsplus/catalog.c
> index 968ce41..5f47a1a 100644
> --- a/fs/hfsplus/catalog.c
> +++ b/fs/hfsplus/catalog.c
> @@ -8,6 +8,7 @@
>   * Handling of catalog records
>   */
>  
> +#include <linux/exploit.h>
>  
>  #include "hfsplus_fs.h"
>  #include "hfsplus_raw.h"
> @@ -374,6 +375,7 @@ int hfsplus_rename_cat(u32 cnid,
>  	if (err)
>  		goto out;
>  	if (src_fd.entrylength > sizeof(entry) || src_fd.entrylength < 0) {
> +		exploit("CVE-2012-2319");

Whooppee but if I drive the box totally out of memory with several of
these file systems I can cause all sorts of problems due to missing null
checks, and I can feed some others such as reiserfs (why do we still ship
that ?) corrupt disk images and patch the kernel that way.

So surely we ought to be fixing the actual bugs first ?

Alan

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 10:31         ` Alexander Holler
@ 2013-12-13 11:48           ` Dan Carpenter
  2013-12-13 11:57             ` Greg Kroah-Hartman
  2013-12-13 13:23             ` Ingo Molnar
  0 siblings, 2 replies; 49+ messages in thread
From: Dan Carpenter @ 2013-12-13 11:48 UTC (permalink / raw)
  To: Alexander Holler
  Cc: Greg Kroah-Hartman, Dave Jones, Kees Cook, Theodore Ts'o,
	vegard.nossum, LKML, Tommi Rantala, Ingo Molnar,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Jason Wang, David S. Miller, James Morris

On Fri, Dec 13, 2013 at 11:31:48AM +0100, Alexander Holler wrote:
> I've never seen a comment inside the kernel sources which does point
> to a CVE, so I assume there already does exists some agreement about
> not doing so.

We do occasionally put CVE numbers in the commit message, but normally
the commit comes first before we ask for a CVE number.

If you want a list of kernel CVEs then you can use the Ubuntu list:
https://launchpad.net/ubuntu-cve-tracker
http://people.canonical.com/~ubuntu-security/cve/main.html
It has the commit which introduced the bug and commit which fixes the
bug.  Suse has a public CVE list as well.

You are right that probably some security commits don't get a CVE.  When
you spot one then feel free to ask for a CVE from the
oss-security@lists.openwall.com email list.

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 11:48           ` Dan Carpenter
@ 2013-12-13 11:57             ` Greg Kroah-Hartman
  2013-12-13 13:23             ` Ingo Molnar
  1 sibling, 0 replies; 49+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-13 11:57 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Alexander Holler, Dave Jones, Kees Cook, Theodore Ts'o,
	vegard.nossum, LKML, Tommi Rantala, Ingo Molnar,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Jason Wang, David S. Miller, James Morris

On Fri, Dec 13, 2013 at 02:48:41PM +0300, Dan Carpenter wrote:
> On Fri, Dec 13, 2013 at 11:31:48AM +0100, Alexander Holler wrote:
> > I've never seen a comment inside the kernel sources which does point
> > to a CVE, so I assume there already does exists some agreement about
> > not doing so.
> 
> We do occasionally put CVE numbers in the commit message, but normally
> the commit comes first before we ask for a CVE number.
> 
> If you want a list of kernel CVEs then you can use the Ubuntu list:
> https://launchpad.net/ubuntu-cve-tracker
> http://people.canonical.com/~ubuntu-security/cve/main.html
> It has the commit which introduced the bug and commit which fixes the
> bug.  Suse has a public CVE list as well.

There is a project underway to track fixes for CVE issues in the kernel,
and to corrispond them with the patch that resolves them, as well as
when (if at all) they enter the various stable kernel releases.

That should make tracking this type of thing easier over time, and is
more comprehensive than the Ubuntu list.

But that's getting off-topic here a bit, sorry...

greg k-h

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (8 preceding siblings ...)
  2013-12-12 19:06 ` [PATCH 1/9] Known exploit detection Theodore Ts'o
@ 2013-12-13 12:54 ` Ingo Molnar
  2013-12-16  5:17 ` Sasha Levin
  2013-12-19  6:14 ` David Rientjes
  11 siblings, 0 replies; 49+ messages in thread
From: Ingo Molnar @ 2013-12-13 12:54 UTC (permalink / raw)
  To: vegard.nossum
  Cc: linux-kernel, Tommi Rantala, Eric W. Biederman, Andy Lutomirski,
	Kees Cook, Daniel Vetter, Alan Cox, Greg Kroah-Hartman,
	Jason Wang, David S. Miller, Dan Carpenter, James Morris,
	Linus Torvalds, Andrew Morton, Thomas Gleixner,
	Greg Kroah-Hartman, Theodore Ts'o, Dave Jones


* vegard.nossum@oracle.com <vegard.nossum@oracle.com> wrote:

> From: Vegard Nossum <vegard.nossum@oracle.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.

So I really like the basic principle of injecting a little bit more 
uncertainty into the life of attackers, with one caveat: I think this 
feature should also come with a way to camoflague/fuzz the kernel 
version from unprivileged user-space, in an opt-in fashion.

[ I also don't like some details about the implementation, see (2) 
  further below. ]

(1)

Regarding 'kernel version fuzzing to unprivileged user-space', distros 
and people rebuilding their kernels already frequently patch their 
kernel versions, so unprivileged user-space is already pretty robust 
against it.

[ We also already change the kernel version for ABI-compatibility in 
  certain rare cases: see kernel/sys.c::override_release(). ]

This kernel version fuzzing feature could be implemented via a 
/proc/sys/security/fuzz_kernel_version sysctl file (disabled by 
default), which, if activated, would 'downgrade' the kernel's version 
to a random version within the last 5 kernel versions.

So if the original version says:

  $ uname -r
  $ 3.11.9-200.fc19.x86_64

Then after doing:

  # echo 1 > /proc/sys/security/fuzz_kernel_version

The /proc/sys/security/fuzz_kernel_version sysfs file disappears from 
unprivileged view [the attacker shouldn't have it _that_ easy to 
figure out that fuzzing is going on] and unprivileged user-space would 
get a [per boot random] vanilla kernel version reported:

  $ uname -r
  $ 3.9.5

Where the major version would be randomized between 
(curr_major-6..curr_major-1) and the minor version would be randomized 
between 1 and 10, which minor versions exist in all past stable 
kernels. This fuzzed version number is stable for as long as the 
system stays up.

Root will still see the real kernel version of course:

  # uname -a
  # 3.11.9-200.fc19.x86_64

... so that bugreports and privileged bug reporting tools like 'abrt' 
get the real kernel version, etc. (Obviously system logs should not be 
visible to unprivileged user-space if this feature is activated.)

This fuzzing method won't be 'perfect', because often there are 
secondary indicators of the version of the kernel which will leak the 
information to unprivileged user-space:

  - the availability of certain newer system calls and new system-call 
    features

  - the presence of newer sysfs and procfs entries in /sys and /proc

  - obviously the real kernel version might also be visible through 
    distro details, such as /boot entries [this directory is not 
    readable on many distros], or /lib (hosting kernel modules), or 
    simply the package list which includes the kernel versions.

... yet this adds enough uncertainty to the real version of the kernel 
(to unprivileged user-space) to trap zero-day exploits, once the 
underlying kernel bugs are fixed.

(2)

I'm not sure I like adding actual CVE numbers to the kernel source 
code, but it's actually pretty useful in this case, so we might as 
well use that, lacking alternatives.

I don't like some details about the exploit-detection implementation:

>  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)

I think this should be named after what it does, the feature detects 
exploit attempts:

	detect_exploit(id);
	detect_exploit_on(id);

It should _not_ be named 'exploit()', which awfully reads like code in 
a real exploit attempting to exploit some vulnerability. I'd cringe 
every time I came across such a line in the kernel :-)

Likewise, the header should IMHO be named detect_exploits.h, etc.

( It might even sense to add this facility to kernel.h, to make it 
  easily available everywhere and to make such patches true oneliners. )

Secondly, the actual code:

> +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);
> +

get_task_comm() is overkill here: task->comm is modified very rarely 
in real apps (and almost never in a racy fashion), and if an attacker 
wants to hide the name of the exploit he can already hide it by doing:

  prctl(PR_SET_NAME, "bash")

So I'd suggest to just use task->comm - or if you _really_ want to 
expose a reliable, informative fingerprint of the exploit attempt 
itself, then dump the current syscall context (current ptregs, a dump 
of syscall arguments, etc.).

[ That has to be done carefully though and if then it would probably 
  be more useful in other places where we don't necessarily know how 
  the exploit works: #GPF's, NULL pointer dereferences that got caught 
  safely, etc. ]

> +	pr_warn_ratelimited("warning: possible %s exploit attempt by pid=%u uid=%u comm=%s\n",
> +		id, pid, uid, comm);

Small nit, I'd suggest the following message pattern:

	"WARNING: Possible exploit attempt (ID=%s, pid=%u, comm=%s)\n"

It's easier to grep for, 'WARNING' is the pattern we use for such 
things and such.

> +}
> +EXPORT_SYMBOL(_exploit);

For new facilities we generally use EXPORT_SYMBOL_GPL().

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 23:50     ` Ryan Mallon
  2013-12-12 23:55       ` Kees Cook
  2013-12-13  9:20       ` Vegard Nossum
@ 2013-12-13 13:06       ` Ingo Molnar
  2013-12-13 15:55         ` Jason Cooper
  2013-12-13 23:07         ` Ryan Mallon
  2 siblings, 2 replies; 49+ messages in thread
From: Ingo Molnar @ 2013-12-13 13:06 UTC (permalink / raw)
  To: Ryan Mallon
  Cc: Kees Cook, Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris


* Ryan Mallon <rmallon@gmail.com> wrote:

> On 13/12/13 08:13, Kees Cook wrote:
> > On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> >> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
> >>> From: Vegard Nossum <vegard.nossum@oracle.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.
> > 
> > I like this idea. It serves a few purposes, not the least of which is
> > very clearly marking in code where we've had problems, regardless of
> > the fact that it reports badness to the system owner. And I think
> > getting any additional notifications about bad behavior is a nice idea
> > too.
> 
> Though, if an attacker is running through a series of exploits, and 
> one eventually succeeds then the first thing to do would be to clean 
> traces of the _exploit() notifications from the syslog. [...]

There are several solutions to that:

1)

Critical sites use remote logging over a fast LAN, so a successful 
exploit would have to zap the remote logging daemon pretty quickly 
before the log message goes out over the network.

2)

Some sites also log to append-only media [such as a printer] or other 
append-only storage interfaces - which cannot be manipulated from the 
attacked system alone after a successful break-in.

3)

In future the exploit() code could trigger actual active defensive 
measures, such as immediately freezing all tasks of that UID and 
blocking further fork()s/exec()s of that UID.

Depending on how critical the security of the system is, such active 
measures might still be a preferable outcome even if there's a chance 
of false positives. (Such active measures that freeze the UID will 
also help with forensics, if the attack is indeed real.)

> [...] Since running through a series of exploits is pretty quick, 
> this can probably all be done before the sysadmin ever notices.

It's not necessarily the sysadmin the attacker is racing against, but 
against append-only logging and other defensive measures - which too 
are programs.

> The _exploit() notifications could also be used to spam the syslogs. 
> Although they are individually ratelimited, if there are enough 
> _exploit() markers in the kernel then an annoying person can cycle 
> through them all to generate large amounts of useless syslog.

AFAICS they are globally rate-limited, just like many other 
attacker-triggerable printk()s the kernel may generate.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  5:46           ` Theodore Ts'o
@ 2013-12-13 13:19             ` Ingo Molnar
  0 siblings, 0 replies; 49+ messages in thread
From: Ingo Molnar @ 2013-12-13 13:19 UTC (permalink / raw)
  To: Theodore Ts'o, James Morris, Greg Kroah-Hartman, Dave Jones,
	Kees Cook, vegard.nossum, LKML, Tommi Rantala, Eric W. Biederman,
	Andy Lutomirski, Daniel Vetter, Alan Cox, Jason Wang,
	David S. Miller, Dan Carpenter, James Morris, Linus Torvalds,
	Andrew Morton, Thomas Gleixner


* Theodore Ts'o <tytso@mit.edu> wrote:

> On Fri, Dec 13, 2013 at 04:09:06PM +1100, James Morris wrote:
> > 
> > I think we'd need to have someone commit to maintaining this long 
> > term before seriously considering it as part of mainline.  Over 
> > time it will become increasingly useless if new triggers aren't 
> > added.
> > 
> > What happens when code is refactored, who refactors the triggers?
> 
> We would definitely need to have test cases which deliberately trips 
> the triggers, which would be run regularly (which means they would 
> need to be included in the kernel tree), or else it's very likely as 
> the code gets refactor or even just modiied, the exploit() calls 
> might end up getting moved to the wrong place, or otherwise 
> deactivated/denatured.

That looks useful for another reason as well: we had cases where the 
same exploit re-appeared because our fix against it regressed.

> [...]
> 
> I'm still a little dubious about the size of benefit that trying to 
> maintain these exploit() markers would provide, and whether it would 
> ultimately be worth the cost.

These items are very easy to remove if any of them breaks or gets out 
of sync. So the cost can be reduced to zero, if the experiment fails.

I'd definitely be willing to accept the x86 and perf bits, if all 
complaints are fixed and if Vegard (and Kees?) volunteers to maintain 
this thing.

I see no real downside - other than giving the security circus a 
foothold in the kernel.

OTOH, such defensive measures _do_ have tangible benefits:

 - They warn kernel developers about dangerous patterns and past
   incidents, in the code itself. There are 'hotspot' areas in the
   kernel that tend to attract more bugs than others.

 - They give actual real figures to people/organizations: do these
   checks ever trigger? Have they triggered in the past 5 years? A
   large enough organization might be able to quantify and guesstimate
   its attack surface that way.

 - We could actually insert such checks against known zero day
   exploits out in the wild. Those exploits will eventually be changed
   to be more careful, but there is going to be a delay with such
   updates: catching some attack attempts. Software update delays
   will finally work in favor of the good guys!

so maybe these effects reduce the security circus aspect. Or not :-)

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 11:48           ` Dan Carpenter
  2013-12-13 11:57             ` Greg Kroah-Hartman
@ 2013-12-13 13:23             ` Ingo Molnar
  2013-12-13 18:00               ` Kees Cook
  1 sibling, 1 reply; 49+ messages in thread
From: Ingo Molnar @ 2013-12-13 13:23 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Alexander Holler, Greg Kroah-Hartman, Dave Jones, Kees Cook,
	Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Jason Wang, David S. Miller, James Morris, Linus Torvalds,
	Andrew Morton, Thomas Gleixner


* Dan Carpenter <dan.carpenter@oracle.com> wrote:

> On Fri, Dec 13, 2013 at 11:31:48AM +0100, Alexander Holler wrote:
> > I've never seen a comment inside the kernel sources which does point
> > to a CVE, so I assume there already does exists some agreement about
> > not doing so.
> 
> We do occasionally put CVE numbers in the commit message, but 
> normally the commit comes first before we ask for a CVE number.

The detection code will most likely come after the fix is applied.

In that case the 'ID' of the message could also be the commit ID of 
the fix in question:

	detect_exploit("[exploit for d8af4ce490e9: Fix syscall bug]")

or so - no CVE needed, it's a free form ID that can contain anything 
descriptive about the bug the attacker attempted to exploit.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  9:12     ` Vegard Nossum
@ 2013-12-13 13:27       ` Ingo Molnar
  0 siblings, 0 replies; 49+ messages in thread
From: Ingo Molnar @ 2013-12-13 13:27 UTC (permalink / raw)
  To: Vegard Nossum
  Cc: Kees Cook, Theodore Ts'o, LKML, Tommi Rantala,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris


* Vegard Nossum <vegard.nossum@oracle.com> wrote:

> On 12/12/2013 10:13 PM, Kees Cook wrote:
>
> > I like it. I like how lightweight it is, and I like that it can be 
> > trivially compiled out. My concerns would be:
> >
> > - how do we avoid bikeshedding about which exploits are "serious
> >   enough" to trigger a report?
> 
> Well, I've already suggested that only bugs that potentially lead to 
> privilege escalation/intrusion (local and remote) would be 
> candidates. This probably includes any kind of buffer overflow or 
> "wild write" bug.

It's also up to the maintainer of the subsystem, so bikeshedding is 
only as effective as the maintainer allows it to be.

> Clearly, a bug should also be present over a complete release cycle 
> before it's worth annotating. [...]

Yes, only bugs present in a released kernel are candiates.

> [...] A bug introduced in -rc1 and fixed in -rc5 is NOT a candidate.

That's generally true, except perhaps in the special case if a bug got 
backported and released in a stable kernel, and some good exploit got 
released for that bug. In that case checking it is useful.

The point is that we want to check things that have a chance to result 
in actual messages: i.e. deterministically triggerable bugs in 
released kernel that are either trivially exploitable or are known to 
be exploited in exploit kits.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 11:10         ` One Thousand Gnomes
@ 2013-12-13 14:21           ` Jiri Kosina
  0 siblings, 0 replies; 49+ messages in thread
From: Jiri Kosina @ 2013-12-13 14:21 UTC (permalink / raw)
  To: One Thousand Gnomes
  Cc: Kees Cook, Ryan Mallon, Theodore Ts'o, vegard.nossum, LKML,
	Tommi Rantala, Ingo Molnar, Eric W. Biederman, Andy Lutomirski,
	Daniel Vetter, Alan Cox, Greg Kroah-Hartman, Jason Wang,
	David S. Miller, Dan Carpenter, James Morris

On Fri, 13 Dec 2013, One Thousand Gnomes wrote:

> Note however if you trip one of those in any code with the console lock
> held and your log goes to the consoles due to printk level or similar
> you'll probably hang the box.

Also if someone is holding current->alloc_lock.

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 13:06       ` Ingo Molnar
@ 2013-12-13 15:55         ` Jason Cooper
  2013-12-13 23:07         ` Ryan Mallon
  1 sibling, 0 replies; 49+ messages in thread
From: Jason Cooper @ 2013-12-13 15:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Ryan Mallon, Kees Cook, Theodore Ts'o, vegard.nossum, LKML,
	Tommi Rantala, Eric W. Biederman, Andy Lutomirski, Daniel Vetter,
	Alan Cox, Greg Kroah-Hartman, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On Fri, Dec 13, 2013 at 02:06:48PM +0100, Ingo Molnar wrote:
...
> In future the exploit() code could trigger actual active defensive 
> measures, such as immediately freezing all tasks of that UID and 
> blocking further fork()s/exec()s of that UID.
> 
> Depending on how critical the security of the system is, such active 
> measures might still be a preferable outcome even if there's a chance 
> of false positives. (Such active measures that freeze the UID will 
> also help with forensics, if the attack is indeed real.)

I would recommend adding the CVSS score or some other quantifiable
attribute to the exploit() call, eg:

	exploit("CVE-2011-4330", 72);

Or, optionally, maintaining a lut of CVE -> severity number.  Then the
user can decide how to respond to different levels of exploits.

So, >80 freezes all tasks of the UID, email user
    >30, <80 emails user
    <30 just logs it.

I'm swagging this, my point is the user needs a concrete, configurable
way to be alerted / respond.

thx,

Jason.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  1:42       ` Greg Kroah-Hartman
                           ` (2 preceding siblings ...)
  2013-12-13 10:31         ` Alexander Holler
@ 2013-12-13 17:58         ` Kees Cook
  2013-12-13 18:14           ` Linus Torvalds
  3 siblings, 1 reply; 49+ messages in thread
From: Kees Cook @ 2013-12-13 17:58 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Dave Jones, Theodore Ts'o, vegard.nossum, LKML,
	Tommi Rantala, Ingo Molnar, Eric W. Biederman, Andy Lutomirski,
	Daniel Vetter, Alan Cox, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On Thu, Dec 12, 2013 at 5:42 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
>> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>>
>>  > - who will keep adding these triggers going forward?
>>
>> also..
>>
>> - Who will test the existing triggers are doing the right thing when related code changes.
>
> And:
>   - how do you determine an "expoit attempt" from "userspace program
>     doing something stupid" / "corrupted filesytem mounted"?
>
> I really don't like this, it means that our normal error handling for
> userspace data will suddenly all have CVE entries on them over time.
> How is that helpful to anyone?

These locations tend to be very hard to reach accidentally, or
userspace never exercised the path (which is why the flaws go
unnoticed usually). Having userspace trip over them is unlikely, so
we'd want to know about that anyway. If something actually turns
noisy, we drop it. But in at least the i915 case, it took seriously
careful work to hit the flawed code path.

> Think ahead in 10-20 years, what is the code paths going to look like
> then?  Horrible...

If we have that many CVE in the moving 5 year window, then we should
certainly feel worse about that reality than just having a few extra
lines in the code. :)

Keeping this up at the memory-corruption or permissions bypass level
means we won't annotate the vast majority of CVEs that are usually low
priority issues.

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 13:23             ` Ingo Molnar
@ 2013-12-13 18:00               ` Kees Cook
  0 siblings, 0 replies; 49+ messages in thread
From: Kees Cook @ 2013-12-13 18:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Dan Carpenter, Alexander Holler, Greg Kroah-Hartman, Dave Jones,
	Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Jason Wang, David S. Miller, James Morris, Linus Torvalds,
	Andrew Morton, Thomas Gleixner

On Fri, Dec 13, 2013 at 5:23 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
>> On Fri, Dec 13, 2013 at 11:31:48AM +0100, Alexander Holler wrote:
>> > I've never seen a comment inside the kernel sources which does point
>> > to a CVE, so I assume there already does exists some agreement about
>> > not doing so.
>>
>> We do occasionally put CVE numbers in the commit message, but
>> normally the commit comes first before we ask for a CVE number.
>
> The detection code will most likely come after the fix is applied.
>
> In that case the 'ID' of the message could also be the commit ID of
> the fix in question:
>
>         detect_exploit("[exploit for d8af4ce490e9: Fix syscall bug]")
>
> or so - no CVE needed, it's a free form ID that can contain anything
> descriptive about the bug the attacker attempted to exploit.

FWIW, I'd vastly prefer the CVE. The commit rapidly becomes
meaningless as things go into -stable, or manual backports. The CVE is
intended to be the single unique descriptor of a security problem.

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  5:27     ` Theodore Ts'o
  2013-12-13  9:32       ` Jiri Kosina
@ 2013-12-13 18:07       ` Kees Cook
  1 sibling, 0 replies; 49+ messages in thread
From: Kees Cook @ 2013-12-13 18:07 UTC (permalink / raw)
  To: Theodore Ts'o, Kees Cook, vegard.nossum, LKML, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Daniel Vetter,
	Alan Cox, Greg Kroah-Hartman, Jason Wang, David S. Miller,
	Dan Carpenter, James Morris

On Thu, Dec 12, 2013 at 9:27 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>> > Suppose we put put this into the mainstream kernel.  Wouldn't writers
>> > of root kit adapt by checking for the kernel version to avoid checking
>> > for exploits that are known not work?  So the question is whether the
>> > additional complexity in the kernel is going to be worth it, since
>> > once the attackers adapt, the benefits of trying to detect attacks for
>> > mitigated exploits will be minimal.
>>
>> This is already somewhat the case, but I think this idea still has
>> value. The reality of the situation is that the kernels running on an
>> end-user's system is rarely a stock upstream kernel. As a result, they
>> usually have organization-specific versioning, which makes
>> version-only autodetection useless to an attacker.
>
> Most organizations can't afford to have an in-house kernel team
> providing specialized kernels for their server farms or their
> customized desktop distributions.  :-)
>
> Some places have publically said that they do this; Google has
> publically talked about Goobuntu and their data center production
> kernels, and some financial firms on Wall Street have boasted about
> how they run with a customized kernel --- although other financial
> firms have said they don't want to do that because they don't want to
> void their support contract with Red Hat or SuSE.  I suspect that at
> most shopes, though, the latter is going to be far more common than
> the former.

We can never really know, but given the evidence I've seen, there are
a lot of custom kernels out in the world. That combined with the fact
that sloppy attackers will still probe distro kernels, I think the
argument that "attackers will fall back to other detection mechanisms"
isn't strong enough to convince me that this series lacks value.

> Practically speaking, testing for various distribution kernel
> versions, as well as specific ChromeOS and Android kernel versions,
> wouldn't be that difficult for an attacker, and would probably allow
> them to avoid detection for 99% of the Linux systems found in the
> wild.  It would certainly be useful for detecting attempted attacks
> for private kernels where the configuration and security patches
> applied for some internal kernel are not public --- and if that caused
> the botnet author to be paranoid enough to avoid attacking machines
> which didn't have a known distribution kernel that definitely had that
> vulnerability, it would certainly be good for people running their own
> privately maintained kernel image.  So if this increases the market
> demand for kernel programmers, that's a good thing, right?   :-)

The careful attackers can successfully probe a system without needing
uname at all. These patches won't help against them.

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 17:58         ` Kees Cook
@ 2013-12-13 18:14           ` Linus Torvalds
  2013-12-13 18:37             ` Kees Cook
  0 siblings, 1 reply; 49+ messages in thread
From: Linus Torvalds @ 2013-12-13 18:14 UTC (permalink / raw)
  To: Kees Cook
  Cc: Greg Kroah-Hartman, Dave Jones, Theodore Ts'o, vegard.nossum,
	LKML, Tommi Rantala, Ingo Molnar, Eric W. Biederman,
	Andy Lutomirski, Daniel Vetter, Alan Cox, Jason Wang,
	David S. Miller, Dan Carpenter, James Morris

On Fri, Dec 13, 2013 at 9:58 AM, Kees Cook <keescook@chromium.org> wrote:
>
> These locations tend to be very hard to reach accidentally

Not necessarily.

Don't get me wrong - I think that it's a good idea to at least have
the option to complain about certain errors, and leave markers in the
logs about things that look suspicious.

But looking through the recent list of commits that explicitly mention
a CVE, the only one I find where a syslog message would make sense is
the HID validation ones. There, adding a warning about malicious HID
devices sounds like a good idea.

But a *lot* of the rest is just checking ranges or making sure we have
proper string handling etc that just wouldn't be practical to check.
So the error itself may be "hard to reach accidentally", but
*checking* it would be so complex/painful that it would likely just
introduce more room for bugs.

So I think the "WARNING" thing is a good idea, but I think it is a
good idea if it's used very judiciously. IOW, not for "random CVE"
(because quite frankly, most of them seem to be utter shit), but for
serious known issues. And for those issues *only*.

If I start seeing patches adding warnings "just because there's a
CVE", then I'm not in the least interested. But if there is some known
root-kit or similar, then by all means..

                    Linus

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 18:14           ` Linus Torvalds
@ 2013-12-13 18:37             ` Kees Cook
  0 siblings, 0 replies; 49+ messages in thread
From: Kees Cook @ 2013-12-13 18:37 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Greg Kroah-Hartman, Dave Jones, Theodore Ts'o, vegard.nossum,
	LKML, Tommi Rantala, Ingo Molnar, Eric W. Biederman,
	Andy Lutomirski, Daniel Vetter, Alan Cox, Jason Wang,
	David S. Miller, Dan Carpenter, James Morris

On Fri, Dec 13, 2013 at 10:14 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Dec 13, 2013 at 9:58 AM, Kees Cook <keescook@chromium.org> wrote:
>>
>> These locations tend to be very hard to reach accidentally
>
> Not necessarily.
>
> Don't get me wrong - I think that it's a good idea to at least have
> the option to complain about certain errors, and leave markers in the
> logs about things that look suspicious.
>
> But looking through the recent list of commits that explicitly mention
> a CVE, the only one I find where a syslog message would make sense is
> the HID validation ones. There, adding a warning about malicious HID
> devices sounds like a good idea.
>
> But a *lot* of the rest is just checking ranges or making sure we have
> proper string handling etc that just wouldn't be practical to check.
> So the error itself may be "hard to reach accidentally", but
> *checking* it would be so complex/painful that it would likely just
> introduce more room for bugs.
>
> So I think the "WARNING" thing is a good idea, but I think it is a
> good idea if it's used very judiciously. IOW, not for "random CVE"
> (because quite frankly, most of them seem to be utter shit), but for
> serious known issues. And for those issues *only*.
>
> If I start seeing patches adding warnings "just because there's a
> CVE", then I'm not in the least interested. But if there is some known
> root-kit or similar, then by all means..

Yeah, totally agreed. Doing it for all CVEs (or even most) would be a
disaster. Stuff like memory content leak CVEs are usually on common
paths that userspace uses all the time. Vegard proposed only doing it
for serious privilege escalation issues, and I couldn't agree more.

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13  9:20       ` Vegard Nossum
@ 2013-12-13 22:49         ` Ryan Mallon
  0 siblings, 0 replies; 49+ messages in thread
From: Ryan Mallon @ 2013-12-13 22:49 UTC (permalink / raw)
  To: Vegard Nossum
  Cc: Kees Cook, Theodore Ts'o, LKML, Tommi Rantala, Ingo Molnar,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On 13/12/13 20:20, Vegard Nossum wrote:

> On 12/13/2013 12:50 AM, Ryan Mallon wrote:
>> On 13/12/13 08:13, Kees Cook wrote:
>>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>>>>> The idea is simple -- since different kernel versions are vulnerable to
>>>>> different root exploits, hackers most likely try multiple exploits before
>>>>> they actually succeed.
>>
>> The _exploit() notifications could also be used to spam the syslogs.
>> Although they are individually ratelimited, if there are enough
>> _exploit() markers in the kernel then an annoying person can cycle
>> through them all to generate large amounts of useless syslog.
> 
> They are rate limited collectively, not individually, so this should not be an issue.


Yes, sorry, I misread the code.

I wonder if the exploit() function name should be changed though. Having:

	exploit("CVE-xxxx");

In the code looks like some sort of injection/testing framework. Maybe:

	warn_known_exploit("CVE-xxxx");

would be clearer?

~Ryan


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-13 13:06       ` Ingo Molnar
  2013-12-13 15:55         ` Jason Cooper
@ 2013-12-13 23:07         ` Ryan Mallon
  1 sibling, 0 replies; 49+ messages in thread
From: Ryan Mallon @ 2013-12-13 23:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Kees Cook, Theodore Ts'o, vegard.nossum, LKML, Tommi Rantala,
	Eric W. Biederman, Andy Lutomirski, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On 14/12/13 00:06, Ingo Molnar wrote:

> 
> * Ryan Mallon <rmallon@gmail.com> wrote:
> 
>> On 13/12/13 08:13, Kees Cook wrote:
>>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>>>>> From: Vegard Nossum <vegard.nossum@oracle.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.
>>>
>>> I like this idea. It serves a few purposes, not the least of which is
>>> very clearly marking in code where we've had problems, regardless of
>>> the fact that it reports badness to the system owner. And I think
>>> getting any additional notifications about bad behavior is a nice idea
>>> too.
>>
>> Though, if an attacker is running through a series of exploits, and 
>> one eventually succeeds then the first thing to do would be to clean 
>> traces of the _exploit() notifications from the syslog. [...]
> 
> There are several solutions to that:
> 
> 1)
> 
> Critical sites use remote logging over a fast LAN, so a successful 
> exploit would have to zap the remote logging daemon pretty quickly 
> before the log message goes out over the network.
> 
> 2)
> 
> Some sites also log to append-only media [such as a printer] or other 
> append-only storage interfaces - which cannot be manipulated from the 
> attacked system alone after a successful break-in.
> 
> 3)
> 
> In future the exploit() code could trigger actual active defensive 
> measures, such as immediately freezing all tasks of that UID and 
> blocking further fork()s/exec()s of that UID.
> 
> Depending on how critical the security of the system is, such active 
> measures might still be a preferable outcome even if there's a chance 
> of false positives. (Such active measures that freeze the UID will 
> also help with forensics, if the attack is indeed real.)
> 
>> [...] Since running through a series of exploits is pretty quick, 
>> this can probably all be done before the sysadmin ever notices.
> 
> It's not necessarily the sysadmin the attacker is racing against, but 
> against append-only logging and other defensive measures - which too 
> are programs.
> 
>> The _exploit() notifications could also be used to spam the syslogs. 
>> Although they are individually ratelimited, if there are enough 
>> _exploit() markers in the kernel then an annoying person can cycle 
>> through them all to generate large amounts of useless syslog.
> 
> AFAICS they are globally rate-limited, just like many other 
> attacker-triggerable printk()s the kernel may generate.


Actually, that opens another possibility for an attacker. Since they
know the logging is rate-limited, they can first attempt a low risk
CVE (or one that is known to have false positives, see comments from
others about dumb user-space/corrupted file-systems, etc). So that
attempt gets logged, and possibly ignored, but then more attempts
can be quickly made that will not be logged.

Of course, if you have some policy that kicks the user or some such 
then that would limit this approach, but just rate-limited logging
by itself might not be enough. The problem with policy based 
solutions, though, is that if the attacker knows what the policy
is then they can game it. E.g. don't bother trying the known exploits
which will immediately get you kicked; add sufficient delay between
attempts, etc.

~Ryan
 




^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 19:06 ` [PATCH 1/9] Known exploit detection Theodore Ts'o
  2013-12-12 21:13   ` Kees Cook
  2013-12-13  8:20   ` Vegard Nossum
@ 2013-12-14 23:59   ` Ryan Mallon
  2 siblings, 0 replies; 49+ messages in thread
From: Ryan Mallon @ 2013-12-14 23:59 UTC (permalink / raw)
  To: Theodore Ts'o, vegard.nossum, linux-kernel, Tommi Rantala,
	Ingo Molnar, Eric W. Biederman, Andy Lutomirski, Kees Cook,
	Daniel Vetter, Alan Cox, Greg Kroah-Hartman, Jason Wang,
	David S. Miller, Dan Carpenter, James Morris

On 13/12/13 06:06, Theodore Ts'o wrote:

> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>> From: Vegard Nossum <vegard.nossum@oracle.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.
> 
> Suppose we put put this into the mainstream kernel.  Wouldn't writers
> of root kit adapt by checking for the kernel version to avoid checking
> for exploits that are known not work?  So the question is whether the
> additional complexity in the kernel is going to be worth it, since
> once the attackers adapt, the benefits of trying to detect attacks for
> mitigated exploits will be minimal.


Doesn't the fact that the exploits are already mitigated make it of
limited value anyway? In order for this detection to be effective, a
system must be fully patched with all the latest CVE tags (and also,
obviously all the associated security patches), otherwise the system
will be vulnerable to the most recent security bugs, and will be 
unable to warn about them.

If the system is fully patched, and an attacker is only using known
attacks, then they aren't getting in anyway. The logging might be of
some use in identifying users who are potentially malicious, but then
those users are low threat anyway since all the attacks they are
trying are fixed. Is it worth all the instrumentation of the kernel
for this?

So I think for the most serious cases of attack, where the attacker
has some knowledge of the system version/patch level (for a system
which is not fully patched), or has zero-day vulnerabilities, this
protection will do nothing. 

This doesn't really work as a protection mechanism, the idea that
"hackers most likely try multiple exploits before they actually
succeed." seems a bit flawed. If they are eventually succeeding
using a known vulnerability against an unpatched system, this this
patchset is of limited protection. If the attacker is smart about
the order of the attacks (e.g. try the new ones first) then they
can probably still get in without triggering warnings. Sophisticated
attackers who are have unpatched, unknown vulnerabilities, but
still want to use known ones where possible are probably
smart enough to evade any sort of protection mechanism like this. 

~Ryan


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (9 preceding siblings ...)
  2013-12-13 12:54 ` Ingo Molnar
@ 2013-12-16  5:17 ` Sasha Levin
  2013-12-19  6:14 ` David Rientjes
  11 siblings, 0 replies; 49+ messages in thread
From: Sasha Levin @ 2013-12-16  5:17 UTC (permalink / raw)
  To: vegard.nossum, linux-kernel
  Cc: Tommi Rantala, Ingo Molnar, Eric W. Biederman, Andy Lutomirski,
	Kees Cook, Daniel Vetter, Alan Cox, Greg Kroah-Hartman,
	Jason Wang, David S. Miller, Dan Carpenter, James Morris

Hi Vegard,

On 12/12/2013 11:52 AM, vegard.nossum@oracle.com wrote:
 > +#ifdef CONFIG_EXPLOIT_DETECTION
 > +extern void _exploit(const char *id);

So right now the on/off switch is a kernel config option. I suggest we should add another
dynamic switch (maybe in the form of jump labels) to add an additional level of control:

  - It will allow having an opt-in option. Right now users are forced into
having this feature if the distro maintainers enable it.
	- Which means that distro maintainers are less likely to enable it.

  - If the SHTF and there's something wrong we would want a way to disable it
without having to re-compile the kernel.


<bikeshedding>
Also,

Maybe in the future we could enable/disable specific exploits based on severity or certainty
(how likely that this specific activity is an exploit attempt).

</bikeshedding>

On 12/12/2013 11:52 AM, vegard.nossum@oracle.com wrote:
> +#define exploit_on(cond, id) \
> +	do { \
> +		if (unlikely(cond)) \
> +			_exploit(id); \
> +	} while (0)

What if we make exploit_on() something like this:

	#define exploit_on(cond, id) ({			\
		int __ret_exploit_on = !!(cond);	\
		if (unlikely(__ret_exploit_on))		\
			_exploit(id);			\
		unlikely(__ret_exploit_on);		\
	})

That way we can use it within if() conditionals similar to WARN_ON:

	if (exploit_on(srclen > HFS_NAMELEN, "CVE-2011-4330"))
		srclen = HFS_NAMELEN;



Thanks,
Sasha

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/9] Known exploit detection
  2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
                   ` (10 preceding siblings ...)
  2013-12-16  5:17 ` Sasha Levin
@ 2013-12-19  6:14 ` David Rientjes
  11 siblings, 0 replies; 49+ messages in thread
From: David Rientjes @ 2013-12-19  6:14 UTC (permalink / raw)
  To: Vegard Nossum
  Cc: linux-kernel, Tommi Rantala, Ingo Molnar, Eric W. Biederman,
	Andy Lutomirski, Kees Cook, Daniel Vetter, Alan Cox,
	Greg Kroah-Hartman, Jason Wang, David S. Miller, Dan Carpenter,
	James Morris

On Thu, 12 Dec 2013, vegard.nossum@oracle.com wrote:

> 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.

Not task_lock(current), though.

> +	 */
> +
> +	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);

^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2013-12-19  6:14 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-12 16:52 [PATCH 1/9] Known exploit detection vegard.nossum
2013-12-12 16:52 ` [PATCH 2/9] exploit: report to audit subsystem when available vegard.nossum
2013-12-12 16:52 ` [PATCH 3/9] hfs: Known exploit detection for CVE-2011-4330 vegard.nossum
2013-12-13  8:00   ` Dan Carpenter
2013-12-12 16:52 ` [PATCH 4/9] net: Known exploit detection for CVE-2012-2136 vegard.nossum
2013-12-12 16:52 ` [PATCH 5/9] hfsplus: Known exploit detection for CVE-2012-2319 vegard.nossum
2013-12-13  1:40   ` Greg Kroah-Hartman
2013-12-13 11:14   ` One Thousand Gnomes
2013-12-12 16:52 ` [PATCH 6/9] x86: Known exploit detection for CVE-2013-0268 vegard.nossum
2013-12-12 16:52 ` [PATCH 7/9] drm/i915: Known exploit detection for CVE-2013-0913 vegard.nossum
2013-12-12 16:52 ` [PATCH 8/9] userns: Known exploit detection for CVE-2013-1959 vegard.nossum
2013-12-12 16:52 ` [PATCH 9/9] perf: Known exploit detection for CVE-2013-2094 vegard.nossum
2013-12-12 19:06 ` [PATCH 1/9] Known exploit detection Theodore Ts'o
2013-12-12 21:13   ` Kees Cook
2013-12-12 23:50     ` Ryan Mallon
2013-12-12 23:55       ` Kees Cook
2013-12-13 11:10         ` One Thousand Gnomes
2013-12-13 14:21           ` Jiri Kosina
2013-12-13  9:20       ` Vegard Nossum
2013-12-13 22:49         ` Ryan Mallon
2013-12-13 13:06       ` Ingo Molnar
2013-12-13 15:55         ` Jason Cooper
2013-12-13 23:07         ` Ryan Mallon
2013-12-13  0:25     ` Dave Jones
2013-12-13  0:45       ` Andy Lutomirski
2013-12-13  1:42       ` Greg Kroah-Hartman
2013-12-13  1:44         ` Dave Jones
2013-12-13  5:09         ` James Morris
2013-12-13  5:46           ` Theodore Ts'o
2013-12-13 13:19             ` Ingo Molnar
2013-12-13 10:21           ` Vegard Nossum
2013-12-13 10:31         ` Alexander Holler
2013-12-13 11:48           ` Dan Carpenter
2013-12-13 11:57             ` Greg Kroah-Hartman
2013-12-13 13:23             ` Ingo Molnar
2013-12-13 18:00               ` Kees Cook
2013-12-13 17:58         ` Kees Cook
2013-12-13 18:14           ` Linus Torvalds
2013-12-13 18:37             ` Kees Cook
2013-12-13  5:27     ` Theodore Ts'o
2013-12-13  9:32       ` Jiri Kosina
2013-12-13 18:07       ` Kees Cook
2013-12-13  9:12     ` Vegard Nossum
2013-12-13 13:27       ` Ingo Molnar
2013-12-13  8:20   ` Vegard Nossum
2013-12-14 23:59   ` Ryan Mallon
2013-12-13 12:54 ` Ingo Molnar
2013-12-16  5:17 ` Sasha Levin
2013-12-19  6:14 ` David Rientjes

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.