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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZoQTlSLDwaX3u37r@tassilo>
Date: Tue, 2 Jul 2024 07:49:57 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.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

> 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

That's true, but there should be at least one executable mapping
for any useful ELF file.

Basically such a check guarantee that you cannot tell anything
about a non x mapping not related to ELF.

> 
> 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".

There's a timing side channel, you can tell where the checks
stop. I don't think it's a big problem, but it's still better to avoid
such leaks in the first place as much as possible.

> 
> 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).

While that's true for the standard security permission model there might
be non standard ones where the relationship is more complicated.

-Andi