Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
>From the 2.17 NEWS:
* The `crypt' function now fails if passed salt bytes that violate the
specification for those values. On Linux, the `crypt' function will
consult /proc/sys/crypto/fips_enabled to determine if "FIPS mode" is
enabled, and fail on encrypted strings using the MD5 or DES algorithm
when the mode is enabled.
> tst(" ", "%qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d");
This string contains invalid salt crypt character.
POSIX says:
~~~
Otherwise, it shall return a null pointer and set errno to indicate the error.
~~~
Therefore returning null and setting errno is entirely appropriate.
All conforming applications should check for NULL.
Conforming implementations may return additional errors to those
listed by POSIX
It is only a problem if you don't return the listed errno for the same error.
> if (strcmp(p->pw_passwd, crypt(oldpasswd, p->pw_passwd)) == 0) {
Examples are non-normative. They are simply informative and may assume things
like always using valid salt characters.
> If this is an error at all… on wheezy it was none, and BSD agrees:
It is not an error. You can't use invalid salt strings.
> Please fix this to at least never return NULL with something
> else than an ENOSYS condition (crypt(3) not implemented at all),
> because this *will* break unrelated software.
That will not get accepted upstream.
Please fix your application to conform with POSIX.
You must check the result and act appropriately when you see a NULL return
including cleaning the input to contain only valid salt characters.
Cheers,
Carlos.
Reply to: