[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090504125114.5e391564@chukar>
Date: Mon, 4 May 2009 12:51:14 -0600
From: Jake Edge <jake@....net>
To: <security@...nel.org>, linux-kernel@...r.kernel.org,
James Morris <jmorris@...ei.org>,
linux-security-module@...r.kernel.org,
Arjan van de Ven <arjan@...radead.org>,
Eric Paris <eparis@...hat.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Roland McGrath <roland@...hat.com>, mingo@...hat.com,
Andrew Morton <akpm@...ux-foundation.org>,
Greg KH <greg@...ah.com>,
ebiederm@...ssion.com (Eric W. Biederman)
Subject: [PATCH] proc: avoid information leaks to non-privileged processes
This is essentially v2 of "[PATCH] proc: avoid leaking eip, esp, or
wchan to non-privileged processes", adding some of Eric Biederman's
suggestions as well as the start_stack change (only give out that
address if the process is ptrace()-able). This has been tested with ps
and top without any ill effects being seen.
proc: avoid information leaks to non-privileged processes
By using the same test as is used for /proc/pid/maps and /proc/pid/smaps,
only allow processes that can ptrace() a given process to see information
that might be used to bypass address space layout randomization (ASLR).
These include eip, esp, wchan, and start_stack in /proc/pid/stat as well
as the non-symbolic output from /proc/pid/wchan.
ASLR can be bypassed by sampling eip as shown by the proof-of-concept code
at http://code.google.com/p/fuzzyaslr/ As part of a presentation
(http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were also
noted as possibly usable information leaks as well. The start_stack address
also leaks potentially useful information.
Cc: Stable Team <stable@...nel.org>
Signed-off-by: Jake Edge <jake@....net>
---
fs/proc/array.c | 13 +++++++++----
fs/proc/base.c | 5 ++++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 7e4877d..725a650 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -80,6 +80,7 @@
#include <linux/delayacct.h>
#include <linux/seq_file.h>
#include <linux/pid_namespace.h>
+#include <linux/ptrace.h>
#include <linux/tracehook.h>
#include <asm/pgtable.h>
@@ -352,6 +353,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
char state;
pid_t ppid = 0, pgid = -1, sid = -1;
int num_threads = 0;
+ int permitted;
struct mm_struct *mm;
unsigned long long start_time;
unsigned long cmin_flt = 0, cmaj_flt = 0;
@@ -364,11 +366,14 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
state = *get_task_state(task);
vsize = eip = esp = 0;
+ permitted = ptrace_may_access(task, PTRACE_MODE_READ);
mm = get_task_mm(task);
if (mm) {
vsize = task_vsize(mm);
- eip = KSTK_EIP(task);
- esp = KSTK_ESP(task);
+ if (permitted) {
+ eip = KSTK_EIP(task);
+ esp = KSTK_ESP(task);
+ }
}
get_task_comm(tcomm, task);
@@ -424,7 +429,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
unlock_task_sighand(task, &flags);
}
- if (!whole || num_threads < 2)
+ if (permitted && (!whole || num_threads < 2))
wchan = get_wchan(task);
if (!whole) {
min_flt = task->min_flt;
@@ -476,7 +481,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
rsslim,
mm ? mm->start_code : 0,
mm ? mm->end_code : 0,
- mm ? mm->start_stack : 0,
+ (permitted && mm) ? mm->start_stack : 0,
esp,
eip,
/* The signal information here is obsolete.
diff --git a/fs/proc/base.c b/fs/proc/base.c
index aa763ab..fb45615 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -322,7 +322,10 @@ static int proc_pid_wchan(struct task_struct *task, char *buffer)
wchan = get_wchan(task);
if (lookup_symbol_name(wchan, symname) < 0)
- return sprintf(buffer, "%lu", wchan);
+ if (!ptrace_may_access(task, PTRACE_MODE_READ))
+ return 0;
+ else
+ return sprintf(buffer, "%lu", wchan);
else
return sprintf(buffer, "%s", symname);
}
--
1.6.2.2
--
Jake Edge - LWN - jake@....net - http://lwn.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists