linux-hardening - Re: [PATCH] leaking_addresses: Provide mechanism to scan binary files

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]

Message-ID: <ZddnEtnxhJsafdcF@tycho.pizza>
Date: Thu, 22 Feb 2024 08:24:02 -0700
From: Tycho Andersen <tycho@...ho.pizza>
To: Kees Cook <keescook@...omium.org>
Cc: "Tobin C. Harding" <me@...in.cc>, Greg KH <gregkh@...uxfoundation.org>,
	Guixiong Wei <guixiongwei@...il.com>,
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] leaking_addresses: Provide mechanism to scan binary files

Hi Kees,

On Sun, Feb 18, 2024 at 09:38:12AM -0800, Kees Cook wrote:
> Introduce --kallsyms argument for scanning binary files for known symbol
> addresses. This would have found the exposure in /sys/kernel/notes:
> 
> $ scripts/leaking_addresses.pl --kallsyms=<(sudo cat /proc/kallsyms)
> /sys/kernel/notes: hypercall_page @ 156
> /sys/kernel/notes: xen_hypercall_set_trap_table @ 156
> /sys/kernel/notes: startup_xen @ 132
> 
> Signed-off-by: Kees Cook <keescook@...omium.org>

Patch itself is

Reviewed-by: Tycho Andersen <tandersen@...flix.com>

And if you can carry it, that would be great (see below :).

This does bring up some interesting questions. From off-list
discussions with Tobin, I believe he is not particularly interested in
maintaining this script any more. I was never set up to do the PRs
myself, I agreed to be a reviewer to help Tobin out. I'm happy to
adopt it if that makes sense, but I'm curious about the future of the
script:

1. is it useful? (seems like yes if you're adding features)
2. does it make sense to live here as a separate thing? should we
   perhaps run it as part of kselftests or similar? I think that e.g.
   681ff0181bbf ("x86/mm/init/32: Stop printing the virtual memory
   layout") was not discovered with this script, but maybe if we put it
   inline with some other stuff people regularly run more of these would
   fall out? Maybe it makes sense to live somewhere else entirely
   (syzkaller)? I can probably set up some x86/arm64 infra to run it
   regularly, but that won't catch other less popular arches.
3. perl. I'm mostly not a perl programmer, but would be happy to
   rewrite it in python pending the outcome of discussion above.

Thoughts?

Tycho