Re: [musl] Re: Tweaking the program name for <err.h> functions

[Gabriel Ravier <gabravier@gmail.com>]

On 3/11/24 19:47, Rich Felker wrote:
> 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


Doing this would break many programs, such as:
- most of coreutils, e.g. programs like ls, cat or head, since they 
always `close` their input and output descriptors (when they've written 
or read something) to make sure to diagnose all errors
- grep
- xargs
- find
- strace, which (using the half-closed self-pipe trick mentioned earlier 
in this thread to avoid reusing them later btw) closes the standard 
descriptors, to avoid changing the behavior of programs calling it if 
e.g. its input is a pipe (where if it left the fds open that'd mean the 
writer would get SIGPIPE later than if the program was ran without strace)
- tcsh, which deliberately does `close(n)` with `n < 3` to make it so 
all the standard FDs point to `/dev/null`
- troff and groff (and thus man)
- git
- many more... I have found these by simply stracing random programs as 
found on my system with `ls /bin/ | shuf -n1`