[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250606014914.GA423@openwall.com>
Date: Fri, 6 Jun 2025 03:49:14 +0200
From: Solar Designer <solar@...nwall.com>
To: Vegard Nossum <vegard.nossum@...cle.com>
Cc: oss-security@...ts.openwall.com,
Qualys Security Advisory <qsa@...lys.com>
Subject: Re: Local information disclosure in apport and systemd-coredump
On Thu, Jun 05, 2025 at 05:31:41AM +0200, Solar Designer wrote:
> On Tue, Jun 03, 2025 at 10:16:52AM +0200, Vegard Nossum wrote:
> > newgrp: fix potential string injection
> >
> > Since newgrp is setuid-root, any write() system calls it does in order
> > to print error messages will be done as the root user.
> >
> > Unprivileged users can get newgrp to print essentially arbitrary strings
> > to any open file in this way by passing those strings as argv[0] when
> > calling execve(). For example:
> >
> > $ setpid() { (exec -a $1$'\n:' newgrp ''
> > 2>/proc/sys/kernel/ns_last_pid & wait) >/dev/null; }
> > $ setpid 31000
> > $ readlink /proc/self
> > 31001
> 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?
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
