Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
Thorsten Glaser <firstname.lastname@example.org> 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 (email@example.com) <http://www.eyrie.org/~eagle/>