From owner-freebsd-security@FreeBSD.ORG Sat Feb 14 23:17:16 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81588C05; Sat, 14 Feb 2015 23:17:16 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 42BE328A; Sat, 14 Feb 2015 23:17:16 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 320ED358C5F; Sun, 15 Feb 2015 00:17:13 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 1FD2528494; Sun, 15 Feb 2015 00:17:13 +0100 (CET) Date: Sun, 15 Feb 2015 00:17:13 +0100 From: Jilles Tjoelker To: "Derek (freebsd lists)" <482254ac@razorfever.net> Subject: Re: [patch] libcrypt & friends - modular crypt format support in /etc/login.conf Message-ID: <20150214231712.GA1360@stack.nl> References: <54D9F8DF.7070904@razorfever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D9F8DF.7070904@razorfever.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@FreeBSD.org, John-Mark Gurney , "A.J. Kehoe IV \(Nanoman\)" , delphij@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 23:17:16 -0000 On Tue, Feb 10, 2015 at 07:26:07AM -0500, Derek (freebsd lists) wrote: > I've been working on this for a while, and I've produced a patch > that does a few things with the base system: > 1. allows modular crypt to be specified as passwd_format in > /etc/login.conf > - this allows setting the algorithm *and rounds*, i.e. $2b$10$ > for users of varying classes. > - this will allow any future algorithms and parameters > supported by crypt(3) to be supported by the tools around login.conf OK. > 2. introduces a new api, crypt_makesalt which will generate an > appropriate salt for any algorithm selected I like the idea. > 3. updates userland to use this API, and removes totally the > {crypt_set_format, login_setcryptfmt, login_getcryptfmt} APIs Removing API functions completely requires a SHLIB_MAJOR bump. I think this can be avoided by replacing the functions with a stub instead, so they would behave as if the default always applied and not allow changes to it. > 4. switches crypt algorithms to use thread-local storage, so the > good old global crypt buffer is thread-local This uses quite a bit of memory for each thread created, even if it does not call crypt() at all. Fortunately, libcrypt is not commonly used. Given that crypt() has never been thread-safe, consider implementing crypt_r() as in glibc and leaving crypt() thread-unsafe. Thread-local storage via pthread_key_create() (one key for libcrypt) is still "magic" but reduces the memory waste for threads that do not call crypt(). > 5. includes a bunch of new test vectors for libcrypt ATF tests OK. Some remarks about the code: lib/libcrypt/crypt.c crypt_makesalt() > b64_from_24bit((uint8_t) rand_buf[2], (uint8_t) rand_buf[1], (uint8_t) > rand_buf[0], diff, (int *) &(diff), &out); All these casts can be avoided by making the affected variables the proper type in the first place. The cast of &diff causes a strict-aliasing violation and is definitely wrong on 64-bit big-endian systems. rand_buf is a salt, not a secret, so clearing it afterwards is unnecessary. Consider memcpy() and adding '\0' afterward instead of strncpy(). It seems unnecessary to clear the buffer completely. -- Jilles Tjoelker