[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110714134921.GA29522@openwall.com>
Date: Thu, 14 Jul 2011 17:49:21 +0400
From: Solar Designer <solar@...nwall.com>
To: Ludwig Nussel <ludwig.nussel@...e.de>, oss-security@...ts.openwall.com
Cc: Michael Matz <matz@...e.de>, Thorsten Kukuk <kukuk@...e.de>,
Andreas Jaeger <aj@...e.de>, Zefram <zefram@...h.org>
Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling
On Wed, Jul 13, 2011 at 01:37:30PM +0200, Ludwig Nussel wrote:
> After more thinking however ... adding any option that influences
> how new passwords are generated means we have to patch all
> applications that generate passwords to honor that option, ie parse
> the config file. On OpenSUSE I've found pam_unix2, pwdutils,
> mkpasswd and yast2 so far. Biting the bullet and just hardcoding 2y
> would be much easier.
Yes. On Owl, pam_tcb accepts the prefix= parameter, so we can make it
use any new hash type supported by crypt_gensalt*() and crypt*() with no
patching, though. :-) But config files need changes. For example,
here's our /etc/pam.d/system-auth:
#%PAM-1.0
# $Owl: Owl/packages/pam/system-auth.pam,v 1.4 2009/09/28 23:12:58 ldv Exp $
auth required pam_tcb.so shadow fork nullok prefix=$2a$ count=8
account required pam_tcb.so shadow fork
password required pam_passwdqc.so config=/etc/passwdqc.conf
password required pam_tcb.so use_authtok shadow write_to=tcb fork nullok prefix=$2a$ count=8
session required pam_tcb.so
(We supply "prefix=$2a$ count=8" for "auth" as well such that pam_tcb
can defend against timing attacks probing for valid/invalid usernames.)
Our /etc/login.defs has:
#
# The password hashing method and iteration count to use for group
# passwords that may be set with gpasswd(1).
#
CRYPT_PREFIX $2a$
CRYPT_ROUNDS 8
so again, only a config file change is needed here. If you've been
hard-coding "$2a$", you haven't been taking full advantage of
crypt_gensalt*().
> Nevertheless if we miss to patch any package there would be still the
> chance of someone generating 2a hashes with a different algorithm than
> what the system uses to verify them later though.
Yes. And I fully expect some hashes of this kind to be generated by the
various PHP apps, which have to generate salts on their own. There's no
perfect solution to this, I'm afraid.
> So implementing your
> original idea and have crypt_gensalt change the prefix wouldn't be
> that bad after all. That bears the risk to break some programs like
> mkpasswd but they would at least fail with an error rather than
> generating unusable hashes.
It's not obvious which is worse (and the "unusable hashes" would only be
such for passwords with 8-bit chars, and not fully unusable but just not
usable yet until other systems or parts of the system are updated and
the "$2a$" to "$2x$" compatibility mode is disabled). It's a tradeoff
either way. So I don't intend to revert to that older trick, which
we've already moved away from.
I am tempted to just release the current code as 1.2 now. We won't
arrive at a perfect solution anyway, because it doesn't exist. And we
need to let other projects upgrade to better/safer code (dealing with
one-correct to many-buggy collisions) sooner rather than later.
Thanks,
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
