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_INVALID,DKIM_SIGNED, 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 F40F327B88 for ; Mon, 11 Mar 2024 16:45:28 +0100 (CET) Received: (qmail 7344 invoked by uid 550); 11 Mar 2024 15:41:19 -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 14245 invoked from network); 11 Mar 2024 15:26:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rit.edu; i=@rit.edu; q=dns/txt; s=rit1608; t=1710171028; x=1741707028; h=mime-version:references:in-reply-to:reply-to:from:date: message-id:subject:to:cc:content-transfer-encoding; bh=DgQutMK5cp3QPCA7SIpwUjpRXxswhcToj5X28nX9Iio=; b=IJlZOPA4s7El6rhzF9zasKfMKtkvIJI2TC7ocYHiS93FRF+WBVFYl/KH 4XojUVXO6nJOuB6MeRG5KH5rV4yA2hM5yaDiKuUICL+TFsO5PPXBwhWqu cf5CXl8AB/BfEhqRlkjG2QJzPBcNJO0U+5bZjrM6t0YfnVBonTIY7l4ij I=; X-CSE-ConnectionGUID: Sigtqu1OQjGatdS90nbNSA== X-CSE-MsgGUID: FNnPZRc8S1KwPxZGzS5Ojg== X-RIT-HAT: Undetermined X-RIT-GSuite: Yes X-RIT-GoogleWorkspace: Yes X-IronPort-AV: E=Sophos;i="6.07,117,1708405200"; d="scan'208";a="196934536" X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710171015; x=1710775815; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=p05L/UBq+zC+UHlY3uE/MVe5UYjO6yF2cDOaFj4nbb4=; b=sB6O3UF+jQCpA8AQn5DnH4p35b4ZE6FG1iroyNvDwytCMUif21x872bvNyBy7eRUUD 6Kt/8e91xEb2H1hcjqjTOKRVckTsX0z4po154i91AIi7ovoCNIxHxFwHKj/Q1GQvy8un FxsCVOsL33Dsibba1U229M4/smtbpbQ4f2QmLCIdyH1nbFLoDvXTVoOAYaJp3KhmxZMc jnFXrr0G2CNhIBkKszXzVrDYQ1Tbdcv9g8PyNuwCoYPC8Q+78upY6yGQ2JhYQO1bywI+ FUQig/8nUG14PyblkxrP6OYBsR2j9heK9Y1qHBelH+NJOIV9Wvm1HfjWqLTl6aA3/Ph4 zFlA== X-Forwarded-Encrypted: i=1; AJvYcCVNCsCYP0iTyFu4DpVvXABiVGbyxKeyYYtH3f/pU5LWuYzDl1uyZOh3wKqjjpI5XZA8DeeU91fnWfYPT2Y0Iq31ArAIzrgOFQ== X-Gm-Message-State: AOJu0Yx0ZfK5RtB0CATf7Ya05QDFj6wmf2TmVX7SEuVyKhPFwmt800/c 98yYfsk3IJbmLX9N6f6s6OOYU9MVtWYFhNn5QP7dGzswiDG5yV0+9q3ejLRE3kIgGJOtsmci6Ds iOBwg8EdzsGyiYxHAQ1pL6Jku5Iq8si+VKSRqR2mq1y1HQ02ocAQBvDmBPu+0LW35A4+TTrR5e7 FN4/rXmhh+i4UAAB0LOhUStQeUJeA2R35a0uc= X-Received: by 2002:a05:6e02:156c:b0:365:696:2817 with SMTP id k12-20020a056e02156c00b0036506962817mr10257657ilu.3.1710171015491; Mon, 11 Mar 2024 08:30:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGzZURgZRKGfKYDmlOLc8ROxHHJsZMtq3i1HXr/zuS2xdIeZ2vbzJhWPTb25d0dujk8ey7byFAg7lck/YqpdKc= X-Received: by 2002:a05:6e02:156c:b0:365:696:2817 with SMTP id k12-20020a056e02156c00b0036506962817mr10257633ilu.3.1710171015239; Mon, 11 Mar 2024 08:30:15 -0700 (PDT) MIME-Version: 1.0 References: <20240309150258.GS4163@brightrain.aerifal.cx> <20240310193956.GU4163@brightrain.aerifal.cx> <20240310234410.GW4163@brightrain.aerifal.cx> In-Reply-To: From: "Skyler Ferrante (RIT Student)" Date: Mon, 11 Mar 2024 11:30:04 -0400 Message-ID: To: Andreas Schwab Cc: Alejandro Colomar , Thorsten Glaser , Rich Felker , musl@lists.openwall.com, NRK , Guillem Jover , libc-alpha@sourceware.org, libbsd@lists.freedesktop.org, "Serge E. Hallyn" , Iker Pedrosa , Christian Brauner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Re: Tweaking the program name for functions 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? Skyler On Mon, Mar 11, 2024 at 11:09=E2=80=AFAM Andreas Schwab wr= ote: > > On M=C3=A4r 11 2024, Skyler Ferrante (RIT Student) wrote: > > > It seems like this is the main thing shadow-utils (and other projects) > > should be concerned about. Every setuid/setgid program should check > > for fd 0,1,2 being open at the start of execution, and either abort or > > open new fds to /dev/null to prevent file descriptor omission attacks. > > That's what glibc already does. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint =3D 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D= 7 > "And now for something completely different."