Re: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software

[Thorsten Glaser <tg at mirbsd dot de>]

Aurelien Jarno dixit:

>I am not sure we want to fix that. This behaviour has been introduced
>voluntarily to fix some issues with the previous code:
>
>  http://sourceware.org/ml/libc-alpha/2012-05/msg00893.html
[â]
>The current behavior, while unpleasant, can lead to a DoS, but not to a
>security issue, as the only thing you can access is the 0 address which
>is not accessible as we now have the mmap_min_addr feature since Lenny.

Right, but a DoS is still an issue.

>I am waiting for your inputs for proposal on how to fix that, if
>possible in a way that doesn't lower the security.

Right. Iâm back now, and have looked at the above-mentioned eMail
and the code and diff in question, and Iâd basically change the
code so that every return (NULL) gets replaced by the equivalent
of:

	somebuf[0] = *salt == 'x' ? '*' : 'x';
	somebuf[1] = 0;
	return (somebuf);

This would always avoid returning a NULL value, thus unbreaking
all applications that use that assumption.

Now, on to the separate NULL cases:

â returning NULL if FIPS is enabled and MD5 or DES are requested:
  these seem like a good thing at first, and backed by POSIX, until
  you realise that they do not only depend on system state (the
  /proc/sys/crypto/fips_enabled entry) but also on the input (since
  crypt() will still not return NULL if e.g. SHA-256 is used),
  which makes the argument that crypt() must either always return
  NULL or never, but not depending on its arguments, combined with
  the historical practice of assuming it never returns NULL âor one
  has more problems than that anyway since crypt() is dysfunctionalâ,
  more valid

â 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.

Thatâs why I believe that crypt() should just _never_ return NULL.
The scheme of returning '*' or 'x', which are never valid matches,
distinguishing which one to return so that it never matches the
value passed, comes from dalias from musl, and I think itâs the
best compromise/solution.

Hence, Cc upstream, so that this can be discussed and, ideally,
implemented in both upstream and Debian.

Thanks,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
	-- Tonnerre Lombard in #nosec