> 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
