[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241015202135.GA8875@openwall.com>
Date: Tue, 15 Oct 2024 22:21:35 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2024-47191: Local root exploit in the PAM module pam_oath.so
On Tue, Oct 15, 2024 at 03:17:34PM -0400, Demi Marie Obenour wrote:
> What about opening the path one portion at a time using openat() with
> O_NOFOLLOW (and, as applicable, O_DIRECTORY),
As I understand, the SUSE patch already does that.
> ensuring that each portion
> is not "." or "..", does not contain "/", and is owned by either the
> target user or root? This solves all race conditions and does not
> require spawning another process.
The detail here may be different. And importantly, the final path
component must be owned strictly by the target user (not by root, unless
the target user is root).
On Tue, Oct 15, 2024 at 01:43:42PM +0200, Matthias Gerstner wrote:
> thanks for bringing up the potential problems with the patch we (SUSE)
> suggested. The missing drop of the ancillary group list has indeed been
> overlooked and will result in a lack of protection, since the
> "unprivileged" process will likely still be a member of the root group.
Both the SUSE and the upstream patch try to do two things at once: drop
privileges and access files safer. Maybe I missed, but I think neither
of you specified whether these two things are intended as required
complementary parts (and what attacks would work if only one part worked
as intended) or as defense-in-depth. You could want to clarify this.
> I will adjust the patch to contain this and one or two other adjustments
> and can then share it again here on the list.
Thanks.
> Indeed the patch does not take care of hard link attacks. Our products
> don't have any supported configuration without protected_hardlinks
> enabled, so we didn't have this in mind.
>
> The change to address this concern should be rather small, though, so I
> will try to incorporate it in a new version of the patch.
I guess it's checks of st_uid and st_nlink? There are still some really
subtle issues like side effects on open() of a device file, which can be
hard linked too, but privilege dropping should mostly prevent them. I'd
also add O_NOCTTY.
> On Tue, Oct 08, 2024 at 10:56:59PM +0200, Solar Designer wrote:
> > In general, switching to a user not only drops privileges for file
> > access, but also potentially exposes the process as that user's.
> > fsuid/fsgid switching is the safest in this respect (these were meant
> > just for file access purposes), but with other IDs (depending on which)
> > there may be extra exposure of the partially privileged log in process
> > to the user via /proc, kill(), setpriority(), etc. ... but thankfully
> > and hopefully not also via ptrace() on modern systems anymore.
>
> On modern Linux there shouldn't be a problem with dropping UID/GID, as
> the kernel will set the process's suid_dumpable attribute to the setting
> found in sys.fs.suid_dumpable, which should be 0. When this happens no
> ptrace() etc. will be possible on the end on the user/group that the
> process drops privileges to.
Yes, I am well aware of that, which is why I primarily mentioned other
exposures. Linux's "dumpable" also affects much of /proc, but does not
affect e.g. kill() and setpriority(). And I was speaking in general,
not only about your patch, so not only about Linux.
> Dropping only the fsuid and fsgid on Linux would avoid any potential
> ptrace() dangers. The system calls are marked deprecated, though,
> and have unfortunate error handling. What makes me feel a bit uneasy
> about this approach is that the programmer has to make sure that
> the privilege drop context only ever deals with file system operations.
Yes, that's a trade-off.
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.
