[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2f361de-3ba6-45b2-951a-353b187a4631@oracle.com>
Date: Fri, 6 Jun 2025 10:11:55 +0200
From: Vegard Nossum <vegard.nossum@...cle.com>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com, Qualys Security Advisory <qsa@...lys.com>
Subject: Re: Local information disclosure in apport and
systemd-coredump
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 security@...nel.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
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.
