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.
