Bug#714219: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
On Jul 1, 2013, Thorsten Glaser <tg@mirbsd.de> wrote:
> This would always avoid returning a NULL value, thus unbreaking
> all applications that use that assumption.
It seems to me that this would turn a very visible fault into a silent
fault. In general, the former is more desirable; consider how much
headscratching would ensue should a password mysteriously fail to be
recognized, compared with that resulting from a segfault for
dereferencing the result of crypt.
> the argument that crypt() must either always return NULL or never,
That argument is only valid as long as you're within standard-specified
boundaries. The standard specifies a limited alphabet for the salt, and
if you pass in arguments that don't satisfy the specified requirements,
all best are off as far as the standard is concerned. It's undefined
behavior, that could take such forms as returning NULL or any random
pointer to garbage, crashing, running DES or any other algorithm on the
inputs disregarding or not the salt, stealing your life partner or
destroying the universe ;-)
Indeed, once we frame the situation as “POSIX crypt implements DES”, and
combine that with “FIPS mandates no DES”, the only possible outcome of
combining both requirements is to conclude that POSIX crypt must be
disabled altogether, which is perfectly compatible with returning NULL
and setting errno when crypt is called in a standard-compliant way: that
functionality is not available.
Now, once you bring extensions to the standard into the picture, then
the requirements from the standard are no longer strictly applicable.
That's why the choice of alternate encryption algorithms is done using
salt characters that are outside the POSIX mandated alphabet. Under the
“undefined behavior” rule in the standard, it is perfectly acceptable
for the implementation to behave however it likes; under the rules of
each individual extension, it is perfectly ok for the implementation to
recognize the requests for the extension to be used and proceed to
encrypt accordingly.
Which leaves us with the cases of an extension that is disabled, not
implemented, or not even known of. I see no reason to treat them
differently it from the case in which DES crypt is requested but it's
not available (disabled or not implemented): return NULL, setting errno
accordingly.
> • returning NULL if it’s not valid DES (or an otherwise unrecognised
> algorithm, e.g. #if !__OPTION_EGLIBC_CRYPT_UFC, probably too) is
> just the wrong thing to do, and it does break GNU CVS, among others.
While I had a great concern with this sort of breakage, to the point of
having voiced concerns when I first proposed the patch, and when we
first encountered regressions in applications because of it, I also have
concern for silent failures that might arise at the introduction or
removal of additional extensions selected by out-of-std-alphabet salt.
If, when we fail to recognize an extension, we fallback to DES crypt, we
generate encrypted passwords that will fail to verify by implementations
that recognize the extension, and vice-versa. This is a far more
confusing failure mode, which makes it far less desirable to me.
At this point, I'd rather we took the opportunity to fix code that makes
unsafe assumptions about the behavior of crypt than push the problem on
for users to figure out when a glibc upgrade causes passwords to fail to
be recognized because the salt suggests the use of a different,
newly-recognized encryption algorithm.
This is my current rationale for the current implementation, after two
rounds of discussion on its merits. I must admit I'm not comfortable
with the change that was made to out-of-alphabet DES salt, but ATM I'm
even less comfortable with the alternatives. I didn't always favor the
current situation, and that might change again depending on arguments I
get. But then, I don't have the final word on any of this ;-)
So, if the rationale above doesn't make you as (un)happy as I am about
the current state of crypt in glibc, please bring forth your
counterarguments and let's see if we can all come to a sensible
agreement.
Anyway, thanks for the report,
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Reply to: