linux-kernel - Re: [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP

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 for Android: free password hash cracker in your pocket

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

Date: Fri, 28 Jun 2024 16:03:47 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Andrii Nakryiko <andrii@...nel.org>, linux-fsdevel@...r.kernel.org, brauner@...nel.org, 
	viro@...iv.linux.org.uk, akpm@...ux-foundation.org, 
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org, gregkh@...uxfoundation.org, 
	linux-mm@...ck.org, liam.howlett@...cle.com, surenb@...gle.com, 
	rppt@...nel.org, adobriyan@...il.com
Subject: Re: [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API

On Fri, Jun 28, 2024 at 3:33 PM Andi Kleen <ak@...ux.intel.com> wrote:
>
> > Yep, makes sense. I'm currently reworking this whole lib/buildid.c
> > implementation to remove all the restrictions on data being in the
> > first page only, and making it work in a faultable context more
> > reliably. I can audit the code for TOCTOU issues and incorporate your
> > feedback. I'll probably post the patch set next week, will cc you as
> > well.
>
> Please also add checks that the mapping is executable, to
> close the obscure "can check the first 4 bytes of every mapped
> file is ELF\0" hole.
>
> But it will still need the hardening because mappings from
> ld.so are not EBUSY for writes.

I'm a bit confused. Two things:

1) non-executable file-backed VMA still has build ID associated with
it. Note, build ID is extracted from the backing file's content, not
from VMA itself. The part of ELF file that contains build ID isn't
necessarily mmap()'ed at all

2) What sort of exploitation are we talking about here? it's not
enough for backing file to have correct 4 starting bytes (0x7f"ELF"),
we still have to find correct PT_NOTE segment, and .note.gnu.build-id
section within it, that has correct type (3) and key name "GNU".

I'm trying to understand what we are protecting against here.
Especially that opening /proc/<pid>/maps already requires
PTRACE_MODE_READ permissions anyways (or pid should be self).

>
> -Andi