New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRYPT password hash with asterisk #4817
Comments
|
@mreynolds389 We can adjust to 1.4.2 if you need to still support that version too :) |
Actually 1.4.3 is out of support too. We can backport a fix but there are no more releases being made. |
|
I need to double check what SUSE is doing but 15.2 may still be in support for us. Happy to just manage this myself, we wont need a release to apply this. Anyway, I've written a test and I'm going to investigate this today. EDIT: Opps, 1.4.3 is what 15.2 has, so that's fine there. We don't need it for 1.4.2. |
|
Okay, it looks like the fault is here Were trying to set the salt into crypt_r from dbpwd, but in this case dbpwd is "*", which means that the result that is emitted as cp is "*0". Then ct_memcmp is using the length of dbpwd, which is 1, so we only check the '*'. There are quite a number of hardening changes here that can prevent this. |
…words Bug Description: Due to mishanding of short dbpwd hashes, the crypt_r algorithm was misused and was only comparing salts in some cases, rather than checking the actual content of the password. Fix Description: Stricter checks on dbpwd lengths to ensure that content passed to crypt_r has at least 2 salt bytes and 1 hash byte, as well as stricter checks on ct_memcmp to ensure that compared values are the same length, rather than potentially allowing overruns/short comparisons. fixes: 389ds#4817 Author: William Brown <william@blackhats.net.au> Review by: ???
Like I said we can still backport fixes to 1.4.3 (assuming they cleanly apply), and if it helps we can tag them, but there will be no fedora/centos releases. |
…words (#4819) Bug Description: Due to mishanding of short dbpwd hashes, the crypt_r algorithm was misused and was only comparing salts in some cases, rather than checking the actual content of the password. Fix Description: Stricter checks on dbpwd lengths to ensure that content passed to crypt_r has at least 2 salt bytes and 1 hash byte, as well as stricter checks on ct_memcmp to ensure that compared values are the same length, rather than potentially allowing overruns/short comparisons. fixes: #4817 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389
…words (389ds#4819) Bug Description: Due to mishanding of short dbpwd hashes, the crypt_r algorithm was misused and was only comparing salts in some cases, rather than checking the actual content of the password. Fix Description: Stricter checks on dbpwd lengths to ensure that content passed to crypt_r has at least 2 salt bytes and 1 hash byte, as well as stricter checks on ct_memcmp to ensure that compared values are the same length, rather than potentially allowing overruns/short comparisons. fixes: 389ds#4817 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389
…words (389ds#4819) Bug Description: Due to mishanding of short dbpwd hashes, the crypt_r algorithm was misused and was only comparing salts in some cases, rather than checking the actual content of the password. Fix Description: Stricter checks on dbpwd lengths to ensure that content passed to crypt_r has at least 2 salt bytes and 1 hash byte, as well as stricter checks on ct_memcmp to ensure that compared values are the same length, rather than potentially allowing overruns/short comparisons. fixes: 389ds#4817 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389
…words (#4819) Bug Description: Due to mishanding of short dbpwd hashes, the crypt_r algorithm was misused and was only comparing salts in some cases, rather than checking the actual content of the password. Fix Description: Stricter checks on dbpwd lengths to ensure that content passed to crypt_r has at least 2 salt bytes and 1 hash byte, as well as stricter checks on ct_memcmp to ensure that compared values are the same length, rather than potentially allowing overruns/short comparisons. fixes: #4817 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389
|
@rwinter77 I'll get these patches into leap in the coming days |
|
Downstream bug for RHDS: |
…words (#4819) Bug Description: Due to mishanding of short dbpwd hashes, the crypt_r algorithm was misused and was only comparing salts in some cases, rather than checking the actual content of the password. Fix Description: Stricter checks on dbpwd lengths to ensure that content passed to crypt_r has at least 2 salt bytes and 1 hash byte, as well as stricter checks on ct_memcmp to ensure that compared values are the same length, rather than potentially allowing overruns/short comparisons. fixes: #4817 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389
|
Hello, I was looking into CVE-2021-3652, which seems to be the one associated with this issue, as well as looking at CVE-2017-15135. Checking out the patches for both CVEs, the fix that has been presented here, and the fix in https://bugzilla-attachments.redhat.com/attachment.cgi?id=1388078, they seem to be very similar, or at least we have a situation where the patch for CVE-2017-15135 also fixes this issue here. I was wondering if I could get more insight on what happened to the fix that addressed CVE-2017-15135 (it seems to not be included in the code here), and if it indeed fixed the same problem that is CVE-2021-3652. If they are equivalent fixes, CVE-2021-3652 might be a duplicate. |
…words (389ds#4819) Bug Description: Due to mishanding of short dbpwd hashes, the crypt_r algorithm was misused and was only comparing salts in some cases, rather than checking the actual content of the password. Fix Description: Stricter checks on dbpwd lengths to ensure that content passed to crypt_r has at least 2 salt bytes and 1 hash byte, as well as stricter checks on ct_memcmp to ensure that compared values are the same length, rather than potentially allowing overruns/short comparisons. fixes: 389ds#4817 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389
…words (389ds#4819) Bug Description: Due to mishanding of short dbpwd hashes, the crypt_r algorithm was misused and was only comparing salts in some cases, rather than checking the actual content of the password. Fix Description: Stricter checks on dbpwd lengths to ensure that content passed to crypt_r has at least 2 salt bytes and 1 hash byte, as well as stricter checks on ct_memcmp to ensure that compared values are the same length, rather than potentially allowing overruns/short comparisons. fixes: 389ds#4817 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389
Issue Description
If an entry contains an asterisk as the crypted password hash, binding is possible with any password for this entry
userPassword: {CRYPT}*
Package Version and Platform:
Steps to Reproduce
Steps to reproduce the behavior:
Expected results
I would expect to fail the binding with any password because the asterisk is not a vaild character in a crypted password.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Problem occured after importing entries from a NIS database. In NIS (and in /etc/shadow), the asterisk is often used for special users like "nobody".
The text was updated successfully, but these errors were encountered: