[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Jan 2012 12:22:51 -0700
From: "Samuel J. Greear" <sjg@...sjg.com>
To: Solar Designer <solar@...nwall.com>
Cc: dillon@...llo.backplane.com, Nolan Lum <nol888@...il.com>,
security@...gonflybsd.org, oss-security@...ts.openwall.com,
magnum <john.magnum@...hmail.com>
Subject: Re: weird crypt-sha* in DragonFly BSD
>
> 1. You will want to be aware of this issue:
>
> glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()
> http://www.openwall.com/lists/oss-security/2011/11/15/1
>
> There's no agreed upon fix yet (use "thread-next" to see some ideas),
> but I think all distros/projects using Ulrich's SHA-crypt will need to
> deal with this issue eventually. I'll try to remember to inform you
> once we choose to do anything specific.
>
I saw this, my preference would be to get rid of all uses of alloca() and
use malloc(), optionally with a fixed-size array on the stack for short
passwords. If specific alignment is needed it can be forced by
over-allocating and indexing into the heap allocation to the correct
alignment. (I have a personally vendetta against alloca(), importing new
uses of it made me cry a little) -- So I may do this, but it doesn't make
my short list, if someone beats me to it I would be interested in hearing
about it so we can keep in sync.
> 2. Instead of:
>
> + * The deprecated sha256/512 functions are somehow sensitive to the
> + * order of this crypt_types array as well as their respective "name"
> members.
> + *
> + * In order to ensure that both existing passwords will continue to work
> and
> + * that new passwords will be more secure by using the new algorithms even
> + * without updating the existing login.conf, this array is now scanned
> + * backwards. This could be reverted in the future when the deprecated SHA
> + * functionality is removed.
>
> how about using the more reliable approach proposed by magnum here? -
>
> http://www.openwall.com/lists/john-dev/2012/01/19/1
>
> As you can see, he has even spent time to identify the specific 64-bit
> magic values. Of course, you'll need to double-check them (such as by
> applying the patch and testing logins to existing accounts with both
> sha256 and sha512 on a 64-bit DragonFly system.)
>
>
There isn't a collision issue with $3$ and $4$ on DragonFly, so I don't see
any obvious need. I intend to rip the old code out after a few releases, so
the issue (if there is one) will be (relatively) short lived.
> 3. It would be nice for upgraded systems to automatically switch from
> sha256 to sha512 in login.conf - perhaps there's some on-upgrade hook
> that you can use for this? sha256 no longer means the same thing
> anyway; there's no good reason for a percentage of DragonFly systems to
> temporarily switch from one SHA-256 based algorithm to another just for
> them to hopefully switch to sha512 a little bit later (when the admin
> does that). And, what's worse, many systems will end up stuck in this
> intermediary state.
>
>
We do not have specific infrastructure for this and it needed to work for
any systems stuck in such an intermediary state anyway, but I will be
looking into what we can do to a) automatically change the setting in
login.conf and b) warn users/administrators of their existing potentially
insecure passwords.
An aside on B above, if we do put in place a mechanism to warn users/admins
about passwords with $3$ and $4$ magic, is the MD5 implementation
sufficiently weak at this point to warrant warning about it as well?
Thanks,
Sam
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.
