oss-security - Re: weird crypt-sha* in DragonFly BSD

Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.