[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Jan 2012 21:12:04 +0400
From: Solar Designer <solar@...nwall.com>
To: dillon@...llo.backplane.com, Nolan Lum <nol888@...il.com>
Cc: oss-security@...ts.openwall.com, magnum <john.magnum@...hmail.com>
Subject: Re: weird crypt-sha* in DragonFly BSD
Matt -
magnum proceeded to implement support for DragonFly's SHA-2 based hashes
in John the Ripper - to hopefully make you reconsider sooner rather than
later. While doing so, he ended up finding a nasty bug that I
previously did not notice: the code uses sizeof(magic) instead of
strlen(magic), where "magic" is a pointer. Thus, the resulting hashes
are non-portable between 32-bit and 64-bit systems, and additionally
they may be non-portable between different 64-bit versions/builds of
DragonFly (let alone to/from other systems). While this lack of
portability might make some attacks on stolen/leaked hashes more
difficult (it certainly is an issue that we have to consider when adding
support for these hashes to JtR), I doubt that this is what you want.
I strongly recommend that you revert to FreeBSD's MD5-crypt ASAP.
More detail here:
http://www.openwall.com/lists/john-dev/2012/01/16/1
http://www.openwall.com/lists/john-dev/2012/01/16/4
For now, we'll support only the 32-bit flavor of these hashes in JtR.
If you keep them in DragonFly for much longer, we'll likely do something
about supporting the 64-bit flavors as well.
The speeds on one CPU core (in a E5420):
Reference (heavily optimized and parallelized FreeBSD MD5-crypt, 12
hashes computed in parallel):
Benchmarking: FreeBSD MD5 [SSE2i 12x]... DONE
Raw: 25320 c/s real, 25320 c/s virtual
DragonFly's alternatives:
Benchmarking: DragonFly BSD SHA-256 w/ bug (32-bit) [OpenSSL 32/64]... DONE
Many salts: 1663K c/s real, 1646K c/s virtual
Only one salt: 1479K c/s real, 1494K c/s virtual
Benchmarking: DragonFly BSD SHA-512 w/ bugs (32-bit) [OpenSSL 64/64]... DONE
Many salts: 1377K c/s real, 1377K c/s virtual
Only one salt: 1257K c/s real, 1257K c/s virtual
That's 65 times faster cracking - before we even started optimizing.
8-way OpenMP on 2xE5420 (8 cores), reference:
Benchmarking: FreeBSD MD5 [SSE2i 12x]... (8xOMP) DONE
Raw: 202368 c/s real, 25264 c/s virtual
(215k c/s is possible with Intel's compiler, but I did not bother here.)
DragonFly's alternatives:
Benchmarking: DragonFly BSD SHA-256 w/ bug (32-bit) [OpenSSL 32/64]... (8xOMP) DONE
Many salts: 10870K c/s real, 1370K c/s virtual
Only one salt: 6119K c/s real, 763973 c/s virtual
Benchmarking: DragonFly BSD SHA-512 w/ bugs (32-bit) [OpenSSL 64/64]... (8xOMP) DONE
Many salts: 8509K c/s real, 1065K c/s virtual
Only one salt: 5207K c/s real, 656587 c/s virtual
That's roughly a 50x speedup - again, for unoptimized DragonFly hashing
vs. optimized FreeBSD hashing.
With full optimizations, the difference will be more like 500x for the
SHA-256 flavor.
Please let us know if you're going to do anything about these issues.
Thanks,
Alexander
On Tue, Nov 15, 2011 at 06:35:02AM +0400, Solar Designer wrote:
> Hi,
>
> Matthew - when I read that DragonFly moved to using SHA-256 for
> passwords by default, I thought this was referring to the SHA-256 based
> flavor of Ulrich Drepper's SHA-crypt. This would not be the best choice
> to make, in my opinion, but it would not be that bad. However, I just
> found this:
>
> http://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/lib/libcrypt
>
> Are these crypt-sha256.c and/or crypt-sha512.c files actually in use?
> I hope not... They do not include any password stretching, resulting in
> password hashes that are much quicker to crack than MD5-crypt's.
>
> There's also minor weirdness in the code - such as two local pointer
> variables being declared static seemingly for no reason, and only
> "final" but not "ctx" being zeroized in the end. But even this lack of
> proper cleanup is very minor compared to the lack of stretching.
>
> Oh, also the "$3$" prefix was apparently previously used for NTLM:
>
> http://en.wikipedia.org/wiki/Crypt_(Unix)#NT_Hash_Scheme
>
> "FreeBSD used the $3$ prefix for this."
>
> http://search.cpan.org/~zefram/Authen-Passphrase/lib/Authen/Passphrase/NTHash.pm
>
> "... crypt string must consist of "$3$$" (note the extra "$") followed
> by the hash in lowercase hexadecimal."
>
> BTW, I looked at DragonFly's code while analyzing a more subtle issue
> with Ulrich's SHA-crypt:
>
> http://www.openwall.com/lists/oss-security/2011/11/15/1
>
> I thought that maybe you reimplemented it in a better fashion avoiding
> that issue, but I found this... %-)
>
> 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.
