Bug 7808 - crypt(3) does not fail for invalid salts
Summary: crypt(3) does not fail for invalid salts
Status: RESOLVED FIXED
Alias: None
Product: uClibc
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All Linux
: P5 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-19 13:40 UTC by Nikos Mavrogiannopoulos
Modified: 2015-01-19 16:32 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments
Reproducer (514 bytes, text/x-c)
2015-01-19 13:40 UTC, Nikos Mavrogiannopoulos
Details

Note You need to log in before you can comment on or make changes to this bug.
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,