From: Solar Designer <solar@openwall.com>
To: musl@lists.openwall.com
Cc: Timo Teras <timo.teras@iki.fi>
Subject: Re: [PATCH] crypt_blowfish: allow short salt strings
Date: Sun, 27 Mar 2016 06:30:07 +0300 [thread overview]
Message-ID: <20160327033007.GA29317@openwall.com> (raw)
In-Reply-To: <20160327021121.GA28942@openwall.com>
On Sun, Mar 27, 2016 at 05:11:21AM +0300, Solar Designer wrote:
> 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.
I just discussed this with Rich.
Yes, musl's modified crypt_blowfish returns "*" on error. No, this
isn't a security bug in musl as a whole, because that code path is not
reached when the setting argument is "*" as well. So no match.
However, there's risk for code reuse from musl by other projects, and
for potential cut-down revisions of musl (with only bcrypt left, invoked
unconditionally). So I think a change is needed, either reintroducing
the "*0" / "*1" behavior (my preference) or returning NULL (Rich's
preference) on error like glibc does (and unfortunately crashing older
programs that don't expect this).
Alexander
next prev parent reply other threads:[~2016-03-27 3:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 12:12 Timo Teräs
2016-03-27 2:11 ` Solar Designer
2016-03-27 2:54 ` Solar Designer
2016-03-27 15:22 ` Solar Designer
2016-03-27 3:30 ` Solar Designer [this message]
2016-03-27 13:26 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160327033007.GA29317@openwall.com \
--to=solar@openwall.com \
--cc=musl@lists.openwall.com \
--cc=timo.teras@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).