Thorsten Glaser <t...@mirbsd.de> writes: > The glibc people decision to return NULL in crypt(3) has led to several > (plural) CVEs in other software, such as cyrus-sasl2 and xlockmore, > already and breaks the GNU CVS testsuite.
crypt returning NULL transforms various obscure but more serious problems into a denial of service attack (dereferencing a NULL pointer). I think it's movement in the right direction. Yes, it required changes in the downstream users to fix handling of a NULL return, but POSIX already said that a NULL return was possible, so those were existing latent bugs (consider resource exhaustion errors in the crypt implementation, for example). It's a simple failure, as opposed to the more obscure failures possible with the previous implementation. This change also sets us up for a possible future where we decide that DES is sufficiently insecure that we want to refuse to ever use a DES hash. Your proposed solution on libc-alpha was ingenious, but I think it breaks the crypt contract in even more serious ways, since it means that crypt could now return a string matching the disabled password field in /etc/shadow. I bet there's at least one program out there that would then let people authenticate to locked accounts. It's at least extremely surprising and not clearly better than returning NULL. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo3imcj2....@windlord.stanford.edu
