From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 4EF2D3858C2F for ; Tue, 27 Sep 2022 20:32:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4EF2D3858C2F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Content-Type: multipart/signed; boundary="Apple-Mail=_6F771BEB-AB0E-416A-A064-2F102FF46030"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: readpassphrase(3) in glibc, and agetpass() (Was: Is getpass(3) really obsolete?) From: Sam James In-Reply-To: Date: Tue, 27 Sep 2022 21:30:12 +0100 Cc: Zack Weinberg , Theo de Raadt , rsbecker@nexbridge.com, linux-man , tech@openbsd.org, Florian Weimer , git@vger.kernel.org Message-Id: <180409CA-768D-44E5-A15D-91F66F8EC0C2@gentoo.org> References: <73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com> <00d501d7ccbe$0169c340$043d49c0$@nexbridge.com> <63238.1635515736@cvs.openbsd.org> <6d8642e9-71f7-4a83-9791-880d04f67d17@www.fastmail.com> To: Alejandro Colomar X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Apple-Mail=_6F771BEB-AB0E-416A-A064-2F102FF46030 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 27 Sep 2022, at 20:19, Alejandro Colomar via Libc-alpha = wrote: >=20 > Hi Zack, >=20 > On 10/29/21 16:53, Zack Weinberg via Libc-alpha wrote: >> On Fri, Oct 29, 2021, at 9:55 AM, Theo de Raadt wrote: >>> wrote: >>>> On October 29, 2021 7:29 AM, Alejandro Colomar wrote: >>>>> On 10/29/21 13:15, Alejandro Colomar wrote: >>>>>> Hi, >>>>>>=20 >>>>>> As the manual pages says, SUSv2 marked it as LEGACY, and POSIX = doesn't >>>>>> have it at all. The manual page goes further and says "This = function >>>>>> is obsolete. Do not use it." in its first lines. >> ... >>> The community finally had the balls to get rid of gets(3). >>>=20 >>> getpass(3) shares the same flaw, that the buffer size isn't passed. >>> This has been an issue in the past >> I was about to post exactly the same thing. getpass(3) is not = deprecated because there's a better replacement, it's deprecated because = it's _unsafe_. The glibc implementation wraps getline(3) and therefore = doesn't truncate the passphrase or overflow a fixed-size buffer, no = matter how long the input is, but portable code cannot rely on that. = And come to think of it, using getline(3) means that prefixes of the = passphrase may be left lying around in malloc's free lists. >> (getpass also cannot be made thread safe, due to recycling of a = static buffer, but a program in which multiple threads are racing to = prompt the user for passwords would be a UX disaster anyway, so I don't = think that's a critical flaw the way it is for e.g. strtok(3).) >> The Linux manpage project's documentation is, as I understand it, for = Linux with glibc _first_, but not _only_; it should not describe this = function as not-deprecated just because glibc has patched its worst = problems and doesn't offer any better API. >>> readpassphrase(3) has a few too many features/extensions for my = taste, but >>> at least it is harder to abuse. >> I am inclined to agree that readpassphrase has too many knobs, and I = can't think of any legitimate present-day use for several of them, which = is not a good property for an API handling security-critical data. = Also, it relies on the caller to size the buffer for the passphrase, and = therefore risks truncating people's passphrases. >> With my libxcrypt hat on I've thought a bit about replacements for = getpass. The conclusion I came to is that the easy changes are all = putting lipstick on a pig, and if I was going to work on this at all I = was going to design a privilege-separated authentication service that = could be asked to take over a tty, read a passphrase, check it, and = return just success or failure to the caller. Neither the passphrase = itself, nor any strings derived from it, would ever be in the caller's = address space. But this is obviously well out of scope for the C = library. >> zw >=20 > I happen to be working on replacing getpass(3) in shadow-utils. As = there is no replacement in glibc, I'm making the code depend on libbsd = on GNU systems. >=20 > I developed a function similar to getpass(3), but which allocates a = buffer (similar to asprintf(3)). I only allocate once, and bail out if = the password exceeds PASS_MAX, so no leaks in allocated memory (modulo = bugs that I may have not noticed). >=20 > I also enforce both clearing and freeing the memory, by requiring a = specific clean-up function. >=20 > The prototypes for the function and the clean-up are: >=20 > [snip] > Would you mind implementing readpassphrase(3) in glibc so that it's = easier to use something safe and portable without resorting to = compatibility libraries? Also, I'd like some review of this function, = if you think the API could be improved. Maybe agetpass() would be a = simple almost-drop-in replacement for getpass(3), so if you like it for = glibc, let's discuss it. >=20 I assume it'd be libxcrypt instead? Best, sam --Apple-Mail=_6F771BEB-AB0E-416A-A064-2F102FF46030 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCYzNdVV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kP8FAP93cWRejaNr1xofyUlSVQxeIiH5bBpzYNW2ThKOV/8KzgEA7f5aqWlTtrwk mMoUKUnEFjbmkjREJ2QlxcWOyegZlgM= =Knaw -----END PGP SIGNATURE----- --Apple-Mail=_6F771BEB-AB0E-416A-A064-2F102FF46030--