From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753444AbdF0UIt (ORCPT ); Tue, 27 Jun 2017 16:08:49 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:33583 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753132AbdF0UIl (ORCPT ); Tue, 27 Jun 2017 16:08:41 -0400 MIME-Version: 1.0 In-Reply-To: <20170627144948.GD28078@dhcp22.suse.cz> References: <20170621173201.GA114489@beast> <20170627144948.GD28078@dhcp22.suse.cz> From: Kees Cook Date: Tue, 27 Jun 2017 13:08:39 -0700 X-Google-Sender-Auth: S1liSqSGw1pmebZIt4jq6pXzLd0 Message-ID: Subject: Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE To: Michal Hocko Cc: Andrew Morton , Rik van Riel , Daniel Micay , Qualys Security Advisory , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , Alexander Viro , Dmitry Safonov , Andy Lutomirski , Grzegorz Andrejczuk , Masahiro Yamada , LKML , "linux-fsdevel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 7:49 AM, 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. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f182.google.com ([209.85.223.182]:35947 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753265AbdF0UIl (ORCPT ); Tue, 27 Jun 2017 16:08:41 -0400 Received: by mail-io0-f182.google.com with SMTP id z62so24235198ioi.3 for ; Tue, 27 Jun 2017 13:08:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170627144948.GD28078@dhcp22.suse.cz> References: <20170621173201.GA114489@beast> <20170627144948.GD28078@dhcp22.suse.cz> From: Kees Cook Date: Tue, 27 Jun 2017 13:08:39 -0700 Message-ID: Subject: Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE To: Michal Hocko Cc: Andrew Morton , Rik van Riel , Daniel Micay , Qualys Security Advisory , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , Alexander Viro , Dmitry Safonov , Andy Lutomirski , Grzegorz Andrejczuk , Masahiro Yamada , LKML , "linux-fsdevel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jun 27, 2017 at 7:49 AM, 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. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <20170627144948.GD28078@dhcp22.suse.cz> References: <20170621173201.GA114489@beast> <20170627144948.GD28078@dhcp22.suse.cz> From: Kees Cook Date: Tue, 27 Jun 2017 13:08:39 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE To: Michal Hocko Cc: Andrew Morton , Rik van Riel , Daniel Micay , Qualys Security Advisory , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , Alexander Viro , Dmitry Safonov , Andy Lutomirski , Grzegorz Andrejczuk , Masahiro Yamada , LKML , "linux-fsdevel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" List-ID: On Tue, Jun 27, 2017 at 7:49 AM, 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. 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