From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 0B5F1253AA for ; Tue, 12 Mar 2024 01:43:04 +0100 (CET) Received: (qmail 32297 invoked by uid 550); 12 Mar 2024 00:38:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32268 invoked from network); 12 Mar 2024 00:38:53 -0000 Date: Mon, 11 Mar 2024 20:43:09 -0400 From: Rich Felker To: Gabriel Ravier Cc: "Skyler Ferrante (RIT Student)" , Andreas Schwab , Alejandro Colomar , Thorsten Glaser , musl@lists.openwall.com, NRK , Guillem Jover , libc-alpha@sourceware.org, libbsd@lists.freedesktop.org, "Serge E. Hallyn" , Iker Pedrosa , Christian Brauner Message-ID: <20240312004309.GZ4163@brightrain.aerifal.cx> References: <20240310193956.GU4163@brightrain.aerifal.cx> <20240310234410.GW4163@brightrain.aerifal.cx> <20240311194756.GY4163@brightrain.aerifal.cx> <40962405-c5b4-4925-9ca5-7a1c723ebbfd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40962405-c5b4-4925-9ca5-7a1c723ebbfd@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: Tweaking the program name for functions On Tue, Mar 12, 2024 at 12:18:24AM +0000, Gabriel Ravier wrote: > 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... :) > > 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 This makes it so they can malfunction during exit when it flushes/closes the corresponding stdio FILEs. If nothing else has been opened in the mean time, under typical implementations it should be safe, but I think per 2.5.1 Interaction of File Descriptors and Standard I/O Streams: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05_01 it's undefined. The safe way to do what they want is to dup the fd they want to close-and-check-for-errors, open /dev/null, dup2 that over the original fd, then close the first dup. Or, don't exit()/return-from-main, but instead _exit, so there's no subsequent access to the FILE. > - 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` Yes, I'm quite aware it's commonplace, but it would be something nice to get cleaned up... Rich