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 EFB6A22BCB for ; Tue, 12 Mar 2024 15:44:30 +0100 (CET) Received: (qmail 9636 invoked by uid 550); 12 Mar 2024 14:40:18 -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 9613 invoked from network); 12 Mar 2024 14:40:18 -0000 Date: Tue, 12 Mar 2024 10:44:36 -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: <20240312144436.GD4163@brightrain.aerifal.cx> References: <20240310234410.GW4163@brightrain.aerifal.cx> <20240311194756.GY4163@brightrain.aerifal.cx> <40962405-c5b4-4925-9ca5-7a1c723ebbfd@gmail.com> <20240312004309.GZ4163@brightrain.aerifal.cx> <80ae776d-8a62-4fa0-99b1-9524ad90ad6c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80ae776d-8a62-4fa0-99b1-9524ad90ad6c@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 03:23:32AM +0000, Gabriel Ravier wrote: > On 3/12/24 00:43, Rich Felker wrote: > >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. > > > Those applications above (though some of those below appear to do > raw /close/ calls) all circumvent your objection by calling /fclose/ > on the standard streams rather than /close/-ing the file descriptors > directly, which seems legal according to POSIX given otherwise the > following quote would make no sense: OK, in that case, _FORTIFY_SOURCE>1 trapping close(n) for n<3 would not affect them, since they're calling fclose not close... None of this is particularly intended as a serious proposal, but it could be interesting to experiment with and catch programs with dubious behavior that might be a bug. Rich