Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
Please see my bug report for CVS documenting this behavior as well as my patch: https://savannah.nongnu.org/bugs/?39040 --mancha -- 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/20130703164539.d386d60...@smtp.hushmail.com
Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
Dear all: You might be interested in a project of mine which humbly began as helping the Slackware Linux team patch their Shadow tools suite to properly handle possible NULL returns from glibc 2.17+ crypt(). It since has evolved into a larger project where I have been working with developers to introduce needed checks to prevent possible NULL pointer dereference situations in their programs. My progress is being documented in Slackware's de facto bug discussion forum (linuxquestions.org). You can view thread here: https://www.linuxquestions.org/questions/slackware-14/%5Bslackware- current%5D-glibc-2-17-shadow-and-other-penumbrae-4175461061/ Additionally, I have placed all patch files along with a signed digest file in a sourceforge project: https://sourceforge.net/projects/miscellaneouspa/files/glibc217/ The Debian security team might be interested in this given the security implications of some of these fixes. Please CC: me in any such correspondence. --mancha PGP Key ID: 0xB5ABF4FFF7048E92 Key fingerprint = 7F1F E9BF 77CF 15AC 8F6B C934 B5AB F4FF F704 8E92 -- 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/20130703191803.ca04f60...@smtp.hushmail.com
Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
Package: libc6
Version: 2.17-6
Severity: important
Hi,
GNU libc6 in sid is breaking GNU CVS; some operations can
cause a segfault. I’ve tracked it down to:
tglase@tglase:~ $ cat x.c
#define _GNU_SOURCE
#include errno.h
#include stdio.h
#include string.h
#include unistd.h
void tst(const char *, const char *);
void tst(const char *x, const char *y) {
const char *z;
int e;
z = crypt(x, y);
e = errno;
printf(tst(\%s\, \%s\)\n - %p %s\n - %s\n,
x, y, z, z?z:(null), z?(ok):strerror(e));
}
int main(void) {
tst(foo, xy7k69x/M/s7g);
tst(bar, xy7k69x/M/s7g);
tst( , %qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d);
return (0);
}
tglase@tglase:~ $ gcc -O2 -o x x.c -lcrypt
tglase@tglase:~ $ ./x
tst(foo, xy7k69x/M/s7g)
- 0xf77b7140 xy7k69x/M/s7g
- (ok)
tst(bar, xy7k69x/M/s7g)
- 0xf77b7140 xy5FOaP3Hea0k
- (ok)
tst( , %qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d)
- (nil) (null)
- Invalid argument
tglase@tglase:~ $ scp x ${wheezysystem}:
x
100% 5707 5.6KB/s 00:00
tglase@tglase:~ $ ssh ${wheezysystem} ./x
tst(foo, xy7k69x/M/s7g)
- 0xb7742140 xy7k69x/M/s7g
- (ok)
tst(bar, xy7k69x/M/s7g)
- 0xb7742140 xy5FOaP3Hea0k
- (ok)
tst( , %qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d)
- 0xb7742140 %q7LLO/mNILqg
- (ok)
POSIX says crypt(3) only fails with ENOSYS if it’s not supported
at all, but then it’d fail consistently:
ERRORS
The crypt() function shall fail if:
[ENOSYS]
The functionality is not supported on this implementation.
POSIX then goes on to use crypt() just like GNU CVS does:
if (strcmp(p-pw_passwd, crypt(oldpasswd, p-pw_passwd)) == 0) {
Other implementations (like BSD) also strongly suggest that,
unless a different algorithm is selected ($1$, $2a$, etc.)
DES is used, which the above example clearly states is supported,
and overlong salts are just cut off / their trail end ignored.
23:51⎜dalias in musl, we return * on error
If this is an error at all… on wheezy it was none, and BSD agrees:
tg@blau:~ $ uname -a; ./x
MirBSD blau.mirbsd.org 10 Kv#10uB2-20130517 GENERIC#1405 i386
tst(foo, xy7k69x/M/s7g)
- 0x23af3720 xy7k69x/M/s7g
- (ok)
tst(bar, xy7k69x/M/s7g)
- 0x23af3720 xy5FOaP3Hea0k
- (ok)
tst( , %qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d)
- 0x23af3720 %q3ge9F/nF3ec
- (ok)
Although the output on wheezy differs (it shouldn’t).
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.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Versions of packages libc6 depends on:
ii libgcc1 1:4.8.1-4
Versions of packages libc6 recommends:
ii libc6-i686 2.17-6
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.50
ii glibc-doc 2.17-6
ii locales-all [locales] 2.17-6
-- debconf information:
* glibc/upgrade: true
glibc/disable-screensaver:
glibc/restart-failed:
* glibc/restart-services: postfix openbsd-inetd cups cron
* libraries/restart-without-asking: true
--
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/20130626220647.9086.25208.report...@tglase.lan.tarent.de
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.
--
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/cae2ss1jpngrj9z2pezx3wewetahpyrzjcxlwmnidcete5qo...@mail.gmail.com
