#include <stdio.h> #include <unistd.h> int main() { char *p; p = crypt("12345678", "1234"); printf("hash = %s\n", p); } The result is sha512 hash = $6$1234$YlCaDQ/VIZKWwIo2tmk5UTOuoVbHSCBk8.4kcEXuwEVM2CDbAJOGIIPDK5DYedDT0Es/Rj2CSoD8LCpLhu8gy1 According man page, it should return DES format hash. This is serious regression, it can result in buffer overflow in old applications that don't expect anything else (I have been beaten by one such). IMHO historically incompatible behavior can happen only in Modular case. Both Modular and Traditional format salt should result with DES format hash in default case (without crypt_set_format) exactly like man page says: man 3 crypt Traditional crypt: The algorithm used will depend upon whether crypt_set_format() has been called and whether a global default format has been specified. Unless a global default has been specified or crypt_set_format() has set the for- mat to something else, the built-in default format is used. This is cur- rently DES if it is available, or MD5 if not.
Created attachment 145169 [details] Change DES back to the default password format
IMHO it's a bug with your application as it blindly assumes that crypt(3) returns a constant length string and copies it to a buffer with that. However, on the other hand this can be seen as a slight ABI breakage, which should not happen in -STABLE branches. I think the attached patch should be applied against stable/9. We do want to change the default algorithm, for -HEAD, though. It looks like the manual page should be updated by the way. Assigning to des@ for his decision.
IMHO changing a global default is not ABI breakage. If there is a user tweak able setting which changes the output of crypt, the application must be capable of dealing with it.
(In reply to Eitan Adler from comment #3) > IMHO changing a global default is not ABI breakage. If there is a user tweak > able setting which changes the output of crypt, the application must be > capable of dealing with it. Well, a side effect of that change is the output length have been changed. No, I'm not saying the application is not at fault, and by all means that *should* be fixed, however, I believe this still counts as an ABI change, subtle -- maybe, not our fault -- true, but that's still a change. For -STABLE branches, our promise is not to break ABI until next release unless there is very good reasons, by not breaking ABI, the user can reasonably expect applications used to work on previous -STABLE release work without problem on newer -STABLE release without change, if it's of the same major version.
The crypt(3) C library routine is used by Perl/PHP. This change has broken a large number of other things. While there is no argument about the 'strength' of the hash/encryption, the documentation states that it will behave in a specific manner, and as far as I can tell with a quick scan of the FreeBSD archives, there has been no disussion of the impact of making this change. I am surprised that one of the core functions behavior (crypt) was modified and this was not put into the FreeBSD 9.3 release notes. I would strongly suggest that you publicize this and send out instructions on how to a) make the 'des' encryption the default b) recompile everything that uses crypt and is statically linked c) warn Perl and PHP users about this impact so they can update their Perl and PHP. (Note, I might be wrong about PHP, but I checked Perl and it uses the -lcrypt library).
I concede that the man page should have been updated (I thought I'd taken care of it), but any application that copies the hash into a buffer without either checking its length first or using strlcpy() and checking the return value is broken.
Nobody mentioned the worst thing - you cannot portably force the traditional behaviour. If you present the old format salt, you expect the old des hash. If you want some new hash, you can always put $6$ in salt to get such result. I really don't understand why this change was done and how it was accepted. This doesn't have anything common with system default password encryption, this is realised using /etc/login.conf and applications like passwd, etc. The crypt_set_format() function is a FreeBSD invention and you cannot use it portably. For me, this change is like changing printf() to generate always UTF-16 characters without any way to force it portably to other charater set :-(
Regressions in existing applications with unpatched FreeBSD 9.3 RELEASE 1) SQL-Queries with ENCRYPT() in mysql*-server fail. 2) Authentication in in OTRS (Perl crypt()) Please add this issue to Errata: https://www.freebsd.org/releases/9.3R/errata.html
Created attachment 148061 [details] Revert to DES as the default Moving DES to the top of the list breaks the algorithm guessing logic in crypt(3). The attached patch instead sets the default algorithm to the last one in the list and moves SHA512 down so that it becomes the default if libcrypt is compiled without -DHAS_DES.
A commit references this bug: Author: des Date: Thu Oct 9 16:45:12 UTC 2014 New revision: 272830 URL: https://svnweb.freebsd.org/changeset/base/272830 Log: Change the hardcoded default back from SHA512 to DES. PR: 192277 MFC after: 3 days Changes: head/lib/libcrypt/crypt.c
*** Bug 192431 has been marked as a duplicate of this bug. ***
A commit references this bug: Author: delphij Date: Tue Oct 21 21:09:55 UTC 2014 New revision: 273425 URL: https://svnweb.freebsd.org/changeset/base/273425 Log: MFC r272830 (des): Change the hardcoded default back from SHA512 to DES. This will become EN-14:11.crypt. PR: 192277 Changes: _U stable/9/lib/libcrypt/ stable/9/lib/libcrypt/crypt.c
Fix committed to all affected stable branches and 9.3 errata branch (the EN notice will be out soon).
*** Bug 189958 has been marked as a duplicate of this bug. ***