[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKbZUD3dxYqb4RSnXFs9ehWymXe15pt8ra232WAD_msJsBF_BQ@mail.gmail.com>
Date: Fri, 29 Sep 2023 12:58:18 +0100
From: Pedro Falcato <pedro.falcato@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Eric Biederman <ebiederm@...ssion.com>,
Sebastian Ott <sebott@...hat.com>,
Thomas Weißschuh <linux@...ssschuh.net>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v4 0/6] binfmt_elf: Support segments with 0 filesz and
misaligned starts
On Fri, Sep 29, 2023 at 4:24 AM Kees Cook <keescook@...omium.org> wrote:
>
> Hi,
>
> This is the continuation of the work Eric started for handling
> "p_memsz > p_filesz" in arbitrary segments (rather than just the last,
> BSS, segment). I've added the suggested changes:
>
> - drop unused "elf_bss" variable
> - refactor load_elf_interp() to use elf_load()
> - refactor load_elf_library() to use elf_load()
> - report padzero() errors when PROT_WRITE is present
> - drop vm_brk()
>
> Thanks!
>
> -Kees
>
> v4:
> - refactor load_elf_library() too
> - don't refactor padzero(), just test in the only remaining caller
> - drop now-unused vm_brk()
> v3: https://lore.kernel.org/all/20230927033634.make.602-kees@kernel.org
> v2: https://lore.kernel.org/lkml/87sf71f123.fsf@email.froward.int.ebiederm.org
> v1: https://lore.kernel.org/lkml/87jzsemmsd.fsf_-_@email.froward.int.ebiederm.org
>
> Eric W. Biederman (1):
> binfmt_elf: Support segments with 0 filesz and misaligned starts
>
> Kees Cook (5):
> binfmt_elf: elf_bss no longer used by load_elf_binary()
> binfmt_elf: Use elf_load() for interpreter
> binfmt_elf: Use elf_load() for library
> binfmt_elf: Only report padzero() errors when PROT_WRITE
> mm: Remove unused vm_brk()
>
> fs/binfmt_elf.c | 214 ++++++++++++++++-----------------------------
> include/linux/mm.h | 3 +-
> mm/mmap.c | 6 --
> mm/nommu.c | 5 --
> 4 files changed, 76 insertions(+), 152 deletions(-)
Sorry for taking so long to take a look at this.
While I didn't test PPC64 (I don't own PPC64 hardware, and I wasn't
the original reporter), I did manage to craft a reduced test case of:
a.out:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000001f8 0x00000000000001f8 R 0x8
INTERP 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x0000000000000020 0x0000000000000020 R 0x1
[Requesting program interpreter: /home/pfalcato/musl/lib/libc.so]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000428 0x0000000000000428 R 0x1000
LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
0x00000000000000cd 0x00000000000000cd R E 0x1000
LOAD 0x0000000000002000 0x0000000000002000 0x0000000000002000
0x0000000000000084 0x0000000000000084 R 0x1000
LOAD 0x0000000000002e50 0x0000000000003e50 0x0000000000003e50
0x00000000000001c8 0x00000000000001c8 RW 0x1000
DYNAMIC 0x0000000000002e50 0x0000000000003e50 0x0000000000003e50
0x0000000000000180 0x0000000000000180 RW 0x8
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x0000000000002e50 0x0000000000003e50 0x0000000000003e50
0x00000000000001b0 0x00000000000001b0 R 0x1
/home/pfalcato/musl/lib/libc.so:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x0000000000000230 0x0000000000000230 R 0x8
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000049d9c 0x0000000000049d9c R 0x1000
LOAD 0x0000000000049da0 0x000000000004ada0 0x000000000004ada0
0x0000000000057d30 0x0000000000057d30 R E 0x1000
LOAD 0x00000000000a1ad0 0x00000000000a3ad0 0x00000000000a3ad0
0x00000000000005f0 0x00000000000015f0 RW 0x1000
LOAD 0x00000000000a20c0 0x00000000000a60c0 0x00000000000a60c0
0x0000000000000428 0x0000000000002f80 RW 0x1000
DYNAMIC 0x00000000000a1f38 0x00000000000a3f38 0x00000000000a3f38
0x0000000000000110 0x0000000000000110 RW 0x8
GNU_RELRO 0x00000000000a1ad0 0x00000000000a3ad0 0x00000000000a3ad0
0x00000000000005f0 0x0000000000002530 R 0x1
GNU_EH_FRAME 0x0000000000049d10 0x0000000000049d10 0x0000000000049d10
0x0000000000000024 0x0000000000000024 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x0
NOTE 0x0000000000000270 0x0000000000000270 0x0000000000000270
0x0000000000000018 0x0000000000000018 R 0x4
Section to Segment mapping:
Segment Sections...
00
01 .note.gnu.build-id .dynsym .gnu.hash .hash .dynstr .rela.dyn
.rela.plt .rodata .eh_frame_hdr .eh_frame
02 .text .plt
03 .data.rel.ro .dynamic .got .toc
04 .data .got.plt .bss
05 .dynamic
06 .data.rel.ro .dynamic .got .toc
07 .eh_frame_hdr
08
09 .note.gnu.build-id
So on that end, you can take my
Tested-by: Pedro Falcato <pedro.falcato@...il.com>
Although this still doesn't address the other bug I found
(https://github.com/heatd/elf-bug-questionmark), where segments can
accidentally overwrite cleared BSS if we end up in a situation where
e.g we have the following segments:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000001000 0x0000000000400000 0x0000000000400000
0x0000000000000045 0x0000000000000045 R E 0x1000
LOAD 0x0000000000002000 0x0000000000401000 0x0000000000401000
0x000000000000008c 0x000000000000008c R 0x1000
LOAD 0x0000000000000000 0x0000000000402000 0x0000000000402000
0x0000000000000000 0x0000000000000801 RW 0x1000
LOAD 0x0000000000002801 0x0000000000402801 0x0000000000402801
0x0000000000000007 0x0000000000000007 RW 0x1000
NOTE 0x0000000000002068 0x0000000000401068 0x0000000000401068
0x0000000000000024 0x0000000000000024 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .rodata .note.gnu.property .note.gnu.build-id
02 .bss
03 .data
04 .note.gnu.build-id
since the mmap of .data will end up happening over .bss.
--
Pedro
Powered by blists - more mailing lists