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=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 85C632BCAE for ; Tue, 12 Mar 2024 01:18:50 +0100 (CET) Received: (qmail 3621 invoked by uid 550); 12 Mar 2024 00:14:39 -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 3600 invoked from network); 12 Mar 2024 00:14:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710202717; x=1710807517; darn=lists.openwall.com; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=2NirQv8fvyXb/U7T3nApVeknt9fZHfWMVO1IoblF73s=; b=mqrUNmUZEhapImpBs/G6+Ko/0WaKJ4geITqcN/zdQNtZVuzeZsjfZsgjY+XH7AzV2l RmC94CJ/5ji6UuJW5AXLOCGmVo57a3jAstnAleuAkpI1LSN1i6CpcJ/2hLDBKHBJVNjv m2ZnGAWFJig3cnwGM75Fu2QyKUwRWSL3fB8uIrkcQJPoj9EndIaOg3xWq0AZLT43Cp20 VGIJHRXzp/hhrxyjqlK3lCTiWboBeVSKJgtqQ03LKRQ/NcgoaMqhd7enDFLwiB05Vidu 4j46E2kOP641gXRjdT+RUcoySxwKVNrILFAUaktsyCzR5Ojckumf6sBfV9zHsKDC42jO bgvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710202717; x=1710807517; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2NirQv8fvyXb/U7T3nApVeknt9fZHfWMVO1IoblF73s=; b=dWRMkFlhx284vWFSZ5WVlTybFlg4lcmxTIn5DavNZGDKGpUhBzxLGBlliqFRnxHz2V gKA6Rj0jEVU0TdL8TMx1BZ0mGzJ8ZcGYHGED6sEvcU+IDSxsPZ61IVsxvCNx32bef6LX +LYPMoPPCMwFBG0IEht+JK3YCYC9lXFkmhonKoIqx49/5Tm7qDMIDHWeX5IHIuu5xyap WiW39+hv3I/3+az+FZvLuPza6u4cvlMQy8I+Q0uqbDPfk6/HYs1vSGOdjXHQA0olM2bY OYwndG2qLRl5UgV62BoSFxBiPkBE2JBUj9LFH0cSyHqtswjrGJ6tRNuM40i8U/PjVtkw JZiA== X-Forwarded-Encrypted: i=1; AJvYcCXSTOUxYyNVni7vHcUs1rFDzmEEXbAwjLBEmuT00T+EYmLab5iQEcVz5+r1wPYG44Eg1wO0ieYMGhmrjNX1HN2XKGw/27CAkw== X-Gm-Message-State: AOJu0Yy/Ro7x7gnNGKMQhiOzLH2IJmpPx1prAtQFqSj0yD2EUKG3FFrm 3m0fZ2oFm9653uehIk6G+/62cNdk3P4Ibbe/IxRaIdYqlJfmvmjl X-Google-Smtp-Source: AGHT+IFXELfN4cooe5ERVIEgqWr21mqxRi2tCTslPGWXeRJcQeVzUURYSjRh3JghXwESVqqjgIpYXg== X-Received: by 2002:a5d:53c6:0:b0:33d:886d:bb51 with SMTP id a6-20020a5d53c6000000b0033d886dbb51mr6120040wrw.60.1710202716811; Mon, 11 Mar 2024 17:18:36 -0700 (PDT) Message-ID: <40962405-c5b4-4925-9ca5-7a1c723ebbfd@gmail.com> Date: Tue, 12 Mar 2024 00:18:24 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Rich Felker , "Skyler Ferrante (RIT Student)" Cc: 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 References: <20240310193956.GU4163@brightrain.aerifal.cx> <20240310234410.GW4163@brightrain.aerifal.cx> <20240311194756.GY4163@brightrain.aerifal.cx> From: Gabriel Ravier In-Reply-To: <20240311194756.GY4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] Re: Tweaking the program name for functions 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`