Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
Thorsten Glaser <tg@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: