[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E1EFF30.7050601@suse.de>
Date: Thu, 14 Jul 2011 16:37:36 +0200
From: Ludwig Nussel <ludwig.nussel@...e.de>
To: oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>, 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
Solar Designer wrote:
> # 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*().
Well, you need to modify that in %post to automatically get 2y for
new passwords then. Which is kind of ugly as that's a file the admin
may have modified.
Anyways, we have the prefix configurable in /etc/default/password
too (CRYPT=blowfish). So no magic config file editing needed. The
programs parsing that file all do the blowfish=>2a mapping
themselves though as there is no lib unfortunately. So we have to
touch several packages to s/2a/2y/. That's what I meant with
"hard-coding".
>> 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.
Ok. Meanwhile I've found that libxcrypt's crypt_gensalt actually
also may change the prefix. It has a fallback to DES if the
requested prefix isn't available as plugin. So mkpasswd was broken
in that regard always. That error never happened though as mkpasswd
didn't support any prefix libxcrypt didn't support too.
> 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.
Indeed.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
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.
