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 +, 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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130627231943.gm13...@hall.aurel32.net
Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
Debian Bug Tracking System dixit: If you wish to submit further information on this problem, please send it to 714...@bugs.debian.org. Oh well, a '%' is not in the list of DES inputs, so differing is permitted, but returning NULL is so very not nice. Shortening the string shows “DES” can be done on it, so do it; just return * (or x if the input is * so it never matches) if you absolutely can’t return anything else useful. (We continued this discussion in IRC…) bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306262247030.3...@herc.mirbsd.org
Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
On Wed, Jun 26, 2013 at 10:48:55PM +, Thorsten Glaser wrote: Debian Bug Tracking System dixit: If you wish to submit further information on this problem, please send it to 714...@bugs.debian.org. Oh well, a '%' is not in the list of DES inputs, so differing is permitted, but returning NULL is so very not nice. Shortening the string shows “DES” can be done on it, so do it; just return * (or x if the input is * so it never matches) if you absolutely can’t return anything else useful. (We continued this discussion in IRC…) As the function is POSIX compliant, it looks like to me a documentation issue. Should this bug be reassigned to manpages-dev to mention the fact that the function might return NULL in case of error? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626233558.ga13...@hall.aurel32.net
Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
Aurelien Jarno dixit: As the function is POSIX compliant, it looks like to me a documentation issue. Should this bug be reassigned to manpages-dev to mention the fact that the function might return NULL in case of error? The NULL-in-case-of-error mentioned by POSIX is when the function is not implemented *at all*, i.e. all calls to it would fail independent of the input (and then, you’d have bigger problems). Even the example code given in POSIX uses crypt() without checking for NULL explicitly, assuming it’ll always get a string out that just won’t compare equally if it’s not a valid password. There’s bound to be lots of software that uses crypt() like this, especially as this behaviour has been in existence for *decades* literally, and will continue to be on other OSes. This probably *will* introduce security holes, especially when the password hash is user-controlled; libc should behave sanely here and just fall back to “DES”. Or just return * unless the argument is * in which case it can return x. I find it especially poor form of GNU when the GNU libc breaks other GNU software… bye, //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 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306262348430.3...@herc.mirbsd.org
Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
On Wed, Jun 26, 2013 at 11:53:39PM +, Thorsten Glaser wrote: Aurelien Jarno dixit: As the function is POSIX compliant, it looks like to me a documentation issue. Should this bug be reassigned to manpages-dev to mention the fact that the function might return NULL in case of error? The NULL-in-case-of-error mentioned by POSIX is when the function is not implemented *at all*, i.e. all calls to it would fail independent of the input (and then, you’d have bigger problems). This is *your* interpretation of POSIX. Quoting it, there is no ambiguity that crypt can return NULL for any failure (i.e. not successful completion): | Upon successful completion, crypt() shall return a pointer to the | encoded string. The first two bytes of the returned value shall be those | of the salt argument. Otherwise, it shall return a null pointer and set | errno to indicate the error. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130627001037.ge13...@hall.aurel32.net
Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
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? Or will you add some small patch fixing this behaviour and feed that patch also upstream? I do not disagree that user programs “probably” “should” check for NULL, but let’s face reality. And libc *also* has some part in the job: it should not make userspace’s live too hard. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (260 (281) bugs: 0 RC, 182 (196) IN, 78 (85) MW, 0 (0) FP) ‣ src:dash (87 (103) bugs: 3 RC, 41 (46) IN, 43 (54) MW, 0 FP) ‣ src:mksh (2 bugs: 0 RC, 0 IN, 2 MW, 0 FP, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306270024230.3...@herc.mirbsd.org
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 +, 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? Or will you add some small patch fixing this behaviour and feed that patch also upstream? Please provide a patch, and I will add it in the next upload. If you don't, you will sign responsible for all security holes introduced into previously-working code in the archive. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130627004702.gi13...@hall.aurel32.net
Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
Aurelien Jarno dixit: Please provide a patch, and I will add it in the next upload. If you don't, you will sign responsible for all security holes introduced into previously-working code in the archive. It's freaking late at night, and I just spent hours fighting with gnulib and *then* hours I'd rather be doing something else discovering, analysing and discussing it, so gimme a rest, I've got to work for money romoeeow. You responded first that's why I wrote that. If you dont have a patch tomorrow evening i'll try to oblige. //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306270100220.3...@herc.mirbsd.org
