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 618FD26254 for ; Mon, 11 Mar 2024 16:44:59 +0100 (CET) Received: (qmail 3357 invoked by uid 550); 11 Mar 2024 15:40:48 -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 16206 invoked from network); 11 Mar 2024 14:43:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rit.edu; i=@rit.edu; q=dns/txt; s=rit1608; t=1710168429; x=1741704429; h=mime-version:references:in-reply-to:reply-to:from:date: message-id:subject:to:cc:content-transfer-encoding; bh=zPepHQl9mOuoL0kN8njcAStKafd99YQHewS7ZhlbPWE=; b=G6e6JuxIifnygabAq17D4wwM+0gMaB7iWyMTzohgIRdOqfEwJ/yST+C2 9HuzGa9p7HwBfcNda6jFmeQdXq8DvN7KuqMN5BOjJYTvSEry0yOCv8l/7 8burbqhjsWSIwJs12ohgoHNnx7+uzpzgRpXuPDG3D6CXSdIC606OGpIKa k=; X-CSE-ConnectionGUID: 8RuSx19kQnqPVrEE8vphKw== X-CSE-MsgGUID: 4nr8QHrdQb+kpoNIEHYffw== X-RIT-HAT: Undetermined X-RIT-GSuite: Yes X-RIT-GoogleWorkspace: Yes X-IronPort-AV: E=Sophos;i="6.07,116,1708405200"; d="scan'208";a="196921667" X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710168416; x=1710773216; 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=tQlrpYAX3OfBbq+3Mgu0qmBHAMhEO06dCK/b+ykGGsc=; b=ljYk8cw6h0jfU3+ze9Bs7TIM3EPlnuD0bTEGFGR9h4QKxSelvCYvWjnrsgtcu4Ipdq tmEEFb/mdZaKAuSXTHPSXqmDYGxsOfvj2YzOnbIIVLiFC1SnRhFhY4AgKDFsAFIsy7FT FuHQ5A3dE+DhDmf+ts6Bu2C/WECwOhh/D08j22BErQBWOAb2HQ1+E/OMytNhU9xo5Y5k AisEK3fAdiMuIRWKLjlt11vXaF5iH0Ed6d1l9wsB9GoCwDpEFqPhJ5/NJx0bJGoaycTQ qkLxo+ieLNDgD0zo/Nw5zwJf2aj0UCrgRvqH0xzPGjOoatdyO1VK+L2fxUWxXaduvGMq ErDw== X-Forwarded-Encrypted: i=1; AJvYcCWTQq9W+jke4n8JWfeR3qu7MxAn+glqccdMrbHRKsm01rRt6dwkME2slPJUlGrvTiQyUyB0F3jcci3a+5Wk8FciidXjZ6btMw== X-Gm-Message-State: AOJu0Yy3CLT3V/FG4YLcorvHeA7qHFnRdgDyrlVFBkn3XMqrqx7Y6hbR ZMcJ65JuppnIb5DkPP55zWyjey1bEz83h/Q8LNWcs/JOHpvIQBZi22I/4VWMPOrDOfuEsQJCEwX UwNZMI19z+dl4IRERrIadmOvhKQHj0Ym3nyWdBhlm2VfNMXqPzvBRYh9REJu9PiA04Wq2s3bAiL /Q25wb+b+gRfbcS7cX5HnGGB3tzvu6XYzWhWk= X-Received: by 2002:a05:6e02:174d:b0:363:f8c5:9d7b with SMTP id y13-20020a056e02174d00b00363f8c59d7bmr9897915ill.9.1710168416561; Mon, 11 Mar 2024 07:46:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFvwOq2Mb/ilsBZiKTtnrEqggjBKmpXmJs4OzpRJzZ/u/Mod9iRXYrGvogUy3JkY1Zkv3n+4JFPvQg7nF+J2+k= X-Received: by 2002:a05:6e02:174d:b0:363:f8c5:9d7b with SMTP id y13-20020a056e02174d00b00363f8c59d7bmr9897880ill.9.1710168416290; Mon, 11 Mar 2024 07:46:56 -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 10:46:45 -0400 Message-ID: To: Alejandro Colomar Cc: 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 Hi, "Consider that a setuid program accidentally opens a privileged file in fd = 2." 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. Any defenses used to prevent exploitation when a setuid/setgid program does not do this, seems unlikely to succeed. All an attacker would need would be an attacker defined string going to stdout/stderr. Argv[0] is useful for this, but it is not the only option. Usernames/group names/etc. are chosen by attackers. Preventing these from being printed might increase security a bit, but they would make error messages worse. That's just my two cents. Skyler On Sun, Mar 10, 2024 at 8:46=E2=80=AFPM Alejandro Colomar = wrote: > > Hi Thorsten, > > On Mon, Mar 11, 2024 at 12:19:27AM +0000, Thorsten Glaser wrote: > > Rich Felker dixit: > > > > >the string literal, because the string literal appears in modular > > >library code that gets called from multiple utilities, then printing > > >an error message (and even worse, exiting, if you do that too), rather > > >than returning meaningful error information up to the caller for it to > > >handle/display, is just really sloppy, low-quality programming. > > > > Libraries totally should not call exit and thus not err/errx, > > and warn/warnx is=E2=80=A6 also questionable at best. > > > > But modularised code that builds a shared object and a few > > binaries using it? Why not. > > > > The thing I don=E2=80=99t get is why changing __progname is desired, > > but I guess everyone has use cases for something. > > setuid programs. Consider that a setuid program accidentally opens a > privileged file in fd 2. Now what happens if a random user can trigger > that accident, and write arbitrary text to a privileged file, just by > calling that setuid program with execlp("su", "inject this stuff", ...)? > > Bad stuff. > > Have a lovely night! > Alex > > > > > bye, > > //mirabilos > > -- > > (gnutls can also be used, but if you are compiling lynx for your own us= e, > > there is no reason to consider using that package) > > -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL > > -- >