Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
On Thu, Jun 27, 2013 at 12:28:22AM +0000, Thorsten Glaser wrote:
> Aurelien Jarno dixit:
>
> >ambiguity that crypt can return NULL for any failure (i.e. not
> >successful completion):
>
> Indeed, but, one, it doesn’t list any other error code (nor do
> the glibc manpages) and two, there _is_ something called common
> law: it’s been like this for decades.
>
> >This is *your* interpretation of POSIX. Quoting it, there is no
>
> Do you, by inaction, want to sign responsible for all security
> holes introduced into previously-working code in the archive
> that now, without even a recompilation, breaks?
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
In short, beside fixing FIPS compliance the above patch also fixed out
of bound access to the salt string, which can be used for DoS or for a
security attack.
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.
Also detecting unsalted or weakly salted encrypted data before releasing
them to the world looks to me a security measure in the good direction.
Therefore I am now convinced we should not rush for a fix there before
studying the consequences of it with upstream, and I am also convinced
that your threat about being hold responsible for security holes is
void, as the new behaviour has actually reduced the security risk
compared to the previous one.
I am waiting for your inputs for proposal on how to fix that, if
possible in a way that doesn't lower the security.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: