mailing list archives
Re: Linux procfs infoleaks via self-read by a SUID/SGID program (was: CVE-2011-3637 Linux kernel: proc: fix Oops on invalid /proc/<pid>/maps access)
From: Solar Designer <solar () openwall com>
Date: Thu, 9 Feb 2012 10:47:26 +0400
On Thu, Feb 09, 2012 at 12:03:20AM +0100, Djalal Harouni wrote:
I've some kernel patches which are not ready yet, I was planning to send
them to lkml and to the kernel-hardening lists to get feedback from the
I suggest that you bring this to kernel-hardening first to see how it
fits in with what others have been working on and to consider their
feedback - I think Kees and Vasiliy are also doing something in this
area. When you have patches ready for LKML, post them to LKML and CC
the thread to kernel-hardening.
On Wed, Feb 08, 2012 at 02:12:58PM +0400, Solar Designer wrote:
Nice. I guess the same works for /proc/self/mem as well, including with
lseek(). Using this for more than just an ASLR bypass may be tricky -
I thing that same thing will not work for /proc/self/mem since it was
patched, after the execl() the fd will still referece the old
/proc/self/maps of the maps.c program, not the 'chsh' one.
(You mean /proc/self/mem.) Sure. I was thinking of older kernels (e.g.
RHEL5) that did not yet have write support for "mem". I currently care
about these more than I do about current mainline kernels in part
because I dislike the "keep old mm" fix anyway (I think we'll need to
deal with this differently) and in part because these still do allow
read access to "mem" (nothing was patched in RHEL5 as it relates to this
Just set your user password to (without quotes):
"Locked: 0 kB"
I like this.