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.