linux-hardening - Re: [PATCH] elf: Relax assumptions about vaddr ordering

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]

Message-ID: <YfTychdtyCdslrEY@localhost.localdomain>
Date:   Sat, 29 Jan 2022 10:53:22 +0300
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Magnus Groß <magnus.gross@...h-aachen.de>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Eric Biederman <ebiederm@...ssion.com>,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH] elf: Relax assumptions about vaddr ordering

On Fri, Jan 28, 2022 at 02:30:12PM -0800, Kees Cook wrote:
> On Fri, Jan 28, 2022 at 09:26:09AM +0100, Magnus Groß wrote:
> > On Wed, Jan 26, 2022 at 10:31:42PM -0800 Kees Cook wrote:
> > > On Wed, Jan 26, 2022 at 08:50:15AM -0800, Kees Cook wrote:
> > > > On Wed, Jan 26, 2022 at 05:25:20PM +0100, Magnus Groß wrote:
> > > > > From ff4dde97e82727727bda711f2367c05663498b24 Mon Sep 17 00:00:00 2001
> > > > > From: =?UTF-8?q?Magnus=20Gro=C3=9F?= <magnus.gross@...h-aachen.de>
> > > > > Date: Wed, 26 Jan 2022 16:35:07 +0100
> > > > > Subject: [PATCH] elf: Relax assumptions about vaddr ordering
> > > > > MIME-Version: 1.0
> > > > > Content-Type: text/plain; charset=UTF-8
> > > > > Content-Transfer-Encoding: 8bit
> > > > > 
> > > > > Commit 5f501d555653 ("binfmt_elf: reintroduce using
> > > > > MAP_FIXED_NOREPLACE") introduced a regression, where the kernel now
> > > > > assumes that PT_LOAD segments are ordered by vaddr in load_elf_binary().
> > > > > 
> > > > > Specifically consider an ELF binary with the following PT_LOAD segments:
> > > > > 
> > > > > Type  Offset   VirtAddr   PhysAddr   FileSiz  MemSiz    Flg Align
> > > > > LOAD  0x000000 0x08000000 0x08000000 0x474585 0x474585  R E 0x1000
> > > > > LOAD  0x475000 0x08475000 0x08475000 0x090a4  0xc6c10   RW  0x1000
> > > > > LOAD  0x47f000 0x00010000 0x00010000 0x00000  0x7ff0000     0x1000
> > > > > 
> > > > > Note how the last segment is actually the first segment and vice versa.
> > > > > 
> > > > > Since total_mapping_size() only computes the difference between the
> > > > > first and the last segment in the order that they appear, it will return
> > > > > a size of 0 in this case, thus causing load_elf_binary() to fail, which
> > > > > did not happen before that change.
> > > > > 
> > > > > Strictly speaking total_mapping_size() made that assumption already
> > > > > before that patch, but the issue did not appear because the old
> > > > > load_addr_set guards never allowed this call to total_mapping_size().
> > > > > 
> > > > > Instead of fixing this by reverting to the old load_addr_set logic, we
> > > > > fix this by comparing the correct first and last segments in
> > > > > total_mapping_size().
> > > > 
> > > > Ah, nice. Yeah, this is good.
> > > > 
> > > > > Signed-off-by: Magnus Groß <magnus.gross@...h-aachen.de>
> > > > 
> > > > Fixes: 5f501d555653 ("binfmt_elf: reintroduce using MAP_FIXED_NOREPLACE")
> > > > Cc: stable@...r.kernel.org
> > > > Acked-by: Kees Cook <keescook@...omium.org>
> > > 
> > > Andrew, can you pick this up too?
> > > 
> > > -Kees
> > > 
> > 
> > May I also propose to include this patch in whatever mailing-list
> > corresponds to the 5.16.x bugfix series?
> > It turns out that almost all native Linux games published by the Virtual
> > Programming company have this kind of weird PT_LOAD ordering including
> > the famous Bioshock Infinite, so right now those games are all
> > completely broken since Linux 5.16.
> > 
> > P.S.: Someone should probably ask Virtual Programming, what kind of
> > tooling they use to create such convoluted ELF binaries.
> 
> Oh, actually, this was independently fixed:
> https://lore.kernel.org/all/YVmd7D0M6G/DcP4O@localhost.localdomain/

Oh wow, I accidently fixed real bug.

> Alexey, you never answered by question about why we can't use a proper
> type and leave the ELF_PAGESTART() macros alone:
> https://lore.kernel.org/all/202110071038.B589687@keescook/
> 
> I still don't like the use of "int" in ELF_PAGESTART(), but I agree
> it shouldn't cause a problem. I just really don't like mixing a signed
> type with address calculations, from a robustness perspective.

It is very robust. There are 2 ways to mask pointers

	unsigned long & ~(unsigned long)-1

	or

	unsigned long & ~(int)-1

Both work. Second variant works for uint32_t too.

As I wrote in that thread, this macro

	#define ELF_PAGESTART(_v) ((_v) & ~(unsigned long)(ELF_MIN_ALIGN-1))

is slightly incorrect because type of the expression can be (unsigned long)
but it logically should be typeof(v). Now fixing by switching to ALIGN
doesn't do anything because ALIGN has the same problem.
And fixing ALIGN requires to go through thousands of usages, which is
way too much for one localised ELF fix.

	PT_ALEXEY