Bug 7808

Summary:	crypt(3) does not fail for invalid salts
Product:	uClibc	Reporter:	Nikos Mavrogiannopoulos <nmav>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED FIXED
Severity:	normal	CC:	uclibc-cvs
Priority:	P5
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	Linux
Host:		Target:
Build:
Attachments:	Reproducer

Description Nikos Mavrogiannopoulos 2015-01-19 13:40:45 UTC

Created attachment 5816 [details]
Reproducer

crypt(3) in uclibc does not fail if $5$ is provided and sha2crypt is disabled.

That according to:
http://git.uclibc.org/uClibc/tree/libcrypt/crypt.c

will proceed into running __des_crypt with the invalid salt (the dollar '$' character is invalid for descrypt), and produce some invalid value - e.g. $5yVOkTkyRzn. - which can only be checked back with uclibc's crypt(). The reason the dollar sign was used as separator in blowfish crypt and then md5crypt was the fact that it would be found as invalid by descrypt.

The important side effect, is that it is impossible to runtime query the capabilities of uclibc crypt(). In fact I found this bug because my software wouldn't fallback to md5crypt if sha2crypt wasn't supported.

I attach a test case which reproduces the issue.

Comment 1 Bernhard Reutner-Fischer 2015-01-19 14:52:23 UTC

So what do you suggest?

	if (salt[0] == '$' && salt[2] == '$') {
[handle 1, 5, 6]
            else {
                __set_errno(EINVAL);
                return NULL;
            }
        }
        return __des_crypt(ukey, usalt);
}

?

Comment 2 Nikos Mavrogiannopoulos 2015-01-19 15:10:50 UTC

I think your snippet is correct. Returning NULL when having the '$' would solve that issue.

Comment 3 Bernhard Reutner-Fischer 2015-01-19 16:32:19 UTC

78b154a95b507c205241dd883396952e0dfbede7

thanks,