From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9744 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] crypt_blowfish: allow short salt strings Date: Sun, 27 Mar 2016 05:11:21 +0300 Message-ID: <20160327021121.GA28942@openwall.com> References: <1458907955-8698-1-git-send-email-timo.teras@iki.fi> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1459044692 19163 80.91.229.3 (27 Mar 2016 02:11:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Mar 2016 02:11:32 +0000 (UTC) Cc: Timo Teras To: musl@lists.openwall.com Original-X-From: musl-return-9757-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 27 04:11:31 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ak0As-0007uX-V0 for gllmg-musl@m.gmane.org; Sun, 27 Mar 2016 04:11:31 +0200 Original-Received: (qmail 14226 invoked by uid 550); 27 Mar 2016 02:11:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 14196 invoked from network); 27 Mar 2016 02:11:25 -0000 Content-Disposition: inline In-Reply-To: <1458907955-8698-1-git-send-email-timo.teras@iki.fi> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:9744 Archived-At: Hi Timo, On Fri, Mar 25, 2016 at 02:12:35PM +0200, Timo Ter??s wrote: > assume the remainder of the salt to be zero bits. > --- > src/crypt/crypt_blowfish.c | 2 ++ > 1 file changed, 2 insertions(+) > > Any comments if this makes sense? Sort of, but we shouldn't do it. crypt_blowfish is deliberately strict, and recent versions of it (after the inclusion in musl, though) were cross-tested against OpenBSD's original implementation resulting in the latter becoming stricter as well, including on wrong inputs like this. Prior to that cross-testing, IIRC it was possible for OpenBSD's implementation to leak uninitialized stack space on too-short salts like this. This confirms that too-short salts were never meant to be supported. OpenBSD is upstream for bcrypt. > There seems to be some test suites that even verify that short > salt strings should succeed. > > See: http://bugs.alpinelinux.org/issues/5141 This looks like a script testing PHP's behavior. I vaguely recall PHP relaxing the PHP-embedded crypt_blowfish code like this. I think they shouldn't have. Especially they shouldn't have done that when at the same time (apparently) continuing to detect and prefer the underlying system's bcrypt support whenever that is available. The behavior you're observing on a system with glibc is most likely actually that of PHP's embedded copy of crypt_blowfish, since upstream glibc lacks bcrypt support (or has this changed?) Only some Linux distros with glibc have bcrypt support patched into their glibc. There is one maybe-bug seen in your test results: the "*" return on error. Normally, it would be "*0" or "*1" for crypt_blowfish, and it would never match the salt input. Rich, did musl retain this behavior? Where does the bare "*" come from? The concern here is that a "*" might also be returned when crypt() is called with "*" for the salt input. Then its output would match what may be a stored hash placeholder, where "*" means locked account or an error having occurred when the password was set. We must deny access in such cases, but returning "*" on all errors would grant access. This could be a musl or PHP security bug, if it's indeed as bad as it appears from that test. Alexander