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 [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
