On 06/06/2025 03:49, Solar Designer wrote:> On Thu, Jun 05, 2025 at
05:31:41AM +0200, Solar Designer wrote:
This general issue in the Linux kernel is indeed not new:
https://www.openwall.com/lists/oss-security/2012/02/08/2
https://www.openwall.com/lists/kernel-hardening/2012/02/10/1
As I recall, grsecurity's fix already available by the time was to
have globally unique exec_id's and compare against those before
allowing procfs file access.
As described by Jason A. Donenfeld and Djalal Harouni back then,
this flavor of confused deputy attacks is even more usable for
reading the target SUID/SGID/setcap process info, such as for ASLR
bypass, which doesn't require unusual permissions on the
corresponding special files. Has this aspect been addressed in
upstream Linux at all? I'm sorry I haven't been following this
since 2012.
I tried to refresh my memory on this and found that Djalal Harouni
attempted to upstream this sort of fix in March 2012:
https://www.openwall.com/lists/kernel-hardening/2012/03/10/
and got some feedback/criticism from Linus Torvalds and a few others
in the next couple of days. Then the thread proceeds into another
related topic ("CLONE_PARENT shouldn't allow to set ->exit_signal" by
Oleg Nesterov, which I see actually got in, and "Potentially this
change allows to kill self_exec_id/parent_exec_id", which are an
earlier mechanism of non-unique IDs originating from my -ow patches)
and ends on March 18. So nothing further happened, it seems?
I started a discussion with secur...@kernel.org in February 2022 with a
handful of replies on the same day, I attempted to restart the
conversation in June 2022 and got a couple of replies, but no
conclusion. A few patches were tested out, but (IIRC) all of them broke
userspace in some way.
ns_last_pid isn't a security issue by itself (as you can always loop the
pid space, like Qualys did), but it's worrisome that we don't have a
general solution to this problem in the kernel -- and that's why I opted
to just fix newgrp in July 2023 as it was an obvious vector.
Vegard
