[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1498575296.1180.0.camel@gmail.com>
Date: Tue, 27 Jun 2017 10:54:56 -0400
From: Daniel Micay <danielmicay@...il.com>
To: Michal Hocko <mhocko@...nel.org>, Kees Cook <keescook@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Rik van Riel
<riel@...hat.com>, Qualys Security Advisory <qsa@...lys.com>, Thomas
Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter
Anvin" <hpa@...or.com>, x86@...nel.org, Alexander Viro
<viro@...iv.linux.org.uk>, Dmitry Safonov <dsafonov@...tuozzo.com>, Andy
Lutomirski <luto@...capital.net>, Grzegorz Andrejczuk
<grzegorz.andrejczuk@...el.com>, Masahiro Yamada
<yamada.masahiro@...ionext.com>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE
On Tue, 2017-06-27 at 16:49 +0200, Michal Hocko wrote:
> On Wed 21-06-17 10:32:01, Kees Cook wrote:
> > The ELF_ET_DYN_BASE position was originally intended to keep loaders
> > away from ET_EXEC binaries. (For example, running "/lib/ld-
> > linux.so.2
> > /bin/cat" might cause the subsequent load of /bin/cat into where the
> > loader had been loaded.) With the advent of PIE (ET_DYN binaries
> > with
> > an INTERP Program Header), ELF_ET_DYN_BASE continued to be used
> > since
> > the kernel was only looking at ET_DYN. However, since
> > ELF_ET_DYN_BASE
> > is traditionally set at the top 1/3rd of the TASK_SIZE, a
> > substantial
> > portion of the address space is unused.
> >
> > For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs
> > are loaded below the mmap region. This means they can be made to
> > collide
> > (CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
> > pathological
> > stack regions. Lowering ELF_ET_DYN_BASE solves both by moving
> > programs
> > above the mmap region in all cases, and will now additionally avoid
> > programs falling back to the mmap region by enforcing MAP_FIXED for
> > program loads (i.e. if it would have collided with the stack, now it
> > will fail to load instead of falling back to the mmap region).
>
> I do not understand this part. MAP_FIXED will simply unmap whatever
> was under the requested range, how it could help failing anything? So
> what would happen if something was mapped in that region, or is this
> impossible? Moreover MAP_FIXED close to stack will inhibit the stack
> gap
> protection.
I don't think there's a reason to use MAP_FIXED. PaX likely ignores the
address hint with RANDMMAP in that code, which would explain it there.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
