[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Mar 2024 15:47:56 -0400
From: Rich Felker <dalias@...c.org>
To: "Skyler Ferrante (RIT Student)" <sjf5462@....edu>
Cc: Andreas Schwab <schwab@...e.de>, Alejandro Colomar <alx@...nel.org>,
Thorsten Glaser <tg@...bsd.de>, musl@...ts.openwall.com,
NRK <nrk@...root.org>, Guillem Jover <guillem@...rons.org>,
libc-alpha@...rceware.org, libbsd@...ts.freedesktop.org,
"Serge E. Hallyn" <serge@...lyn.com>,
Iker Pedrosa <ipedrosa@...hat.com>,
Christian Brauner <christian@...uner.io>
Subject: Re: Re: Tweaking the program name for <err.h> functions
On Mon, Mar 11, 2024 at 11:30:04AM -0400, Skyler Ferrante (RIT Student) wrote:
> Hmm, maybe I'm missing something, but it seems you can close(fd) for
> the standard fds and then call execve, and the new process image will
> have no fd 0,1,2. I've tried this on a default Ubuntu 22.04 system.
> This seems to affect shadow-utils and other setuid/setgid binaries.
>
> Here is a repo I built for testing,
> https://github.com/skyler-ferrante/fd_omission/. What is the correct
> glibc behavior? Am I misunderstanding something?
As Florian noted, you're missing that strace cannot invoke it suid.
POSIX explicitly permits the implementation to open these fds if they
started closed in suid execs, and IIRC indicates as a future direction
that it might be permitted for all execs. We do the same in musl in
the suid case. So really the only way that "writing attacker
controlled prefix strings to fd 2" becomes an issue is if the
application erroneously closes fd 2 and lets something else get opened
on it.
(Aside: making _FORTIFY_SOURCE>1 trap close(n) with n<3 would be an
interesting idea... :)
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
