linux-kernel - Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 27 Jun 2017 13:08:39 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Rik van Riel <riel@...hat.com>,
        Daniel Micay <danielmicay@...il.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" <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>,
        LKML <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Tue, Jun 27, 2017 at 7:49 AM, Michal Hocko <mhocko@...nel.org> 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.

Hmm, well, that's my misunderstanding. Regardless, it should still use
MAP_FIXED otherwise we end up with potentially unpredictable results.
(Note that MAP_FIXED is already used all all remaining allocations, it
was just missing on the first one.)

-Kees

-- 
Kees Cook
Pixel Security