+++ This bug was initially created as a clone of Bug #811753 +++ Description of problem: crypt() returns NULL in fipsmode crypt returned NULL for salt $6$FOOBAR crypt returned NULL for salt $5$FOOBAR Expected results: $6$FOOBAR$yPOQuPE1ruwOrYiApWDYw9BxeLk/oIjajCgzubzO0PYEos/vnqpTnNI12VIdiUF8hiHT9bMslahk/0Oikb.nA. $5$FOOBAR$cDCnc4lB6JRog7XV9JxxoKiWTHbH09P9xkfnf237ke7 --- Additional comment from aoliva on 2012-06-05 18:14:33 EDT --- FWIW, I've managed to duplicate the problem on a F16-ish box, with glibc master (with or without my patches) and nss-softokn-{freebl,debuginfo}-3.13.4-1.fc16.x86_64 I didn't have FIPS enabled, so I used gdb to pretend it was enabled, setting a breakpoint on nsslowhash.c:305 and setting d to '1' before proceeding (that's where it tests what it read from /proc/sys/crypto/fips_enabled). Then I stepped into freebl_fips_SHA_PowerUpSelfTest, only run when FIPS is enabled, and noticed the problem was that the SHA224 self-test was failing: SHA224_HashBuf set sha_computed_digest to a bitstream completely different from sha224_known_digest. I'm not sufficiently familiar with these crypto algorithms to tell whether it is the test or the implementation that is broken, but I'm pretty sure that once either of them is fixed, SHA256 and SHA512 password crypto is going to work with glibc's crypt() build with --enable-nss-crypt. So, I'm going to clone this bug and assign the clone to nss-softokn, so that this one remains about the glibc crypt changes.
Though we can't currently enable system wide fips mode by doing a buildwith tis change - if (!post && nsslow_GetFIPSEnabled()) { + if (!post && (1 || nsslow_GetFIPSEnabled())) { /* force the test to be run always */ crv = freebl_fipsPowerUpSelfTest(); if (crv != CKR_OK) { post_failed = 1; that forces execution of the powerup slef-tests regradless I can reproduce the problem. I booted in single user mode okay and when to run level 3 where authetication of root failed, likewise on run level 5 I could gogin as regular user. I checkd the expected anwser and it matches a value from http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA224.pdf so the computed value is indeed wrong. I'll work on this and log the corresponding bug.
Created attachment 590229 [details] nss test sample C file I'm confused then. The attached nss-example.c runs fine in fips mode. If the fips self test is supposed to fail over the bad sha2 selftest, why does this example run fine in fips mode?
The problem isn't in softoken. Softoken in Fips mode works fine. The problem is in the direct to freebl interface in FIPS mode (think libgcrypt). bob
It also only affects softoken 3.13.x, so there is no issue with RHEL5 or RHEL6. bob
Created attachment 591327 [details] minimalist bug reproducer See the comments at the top of the file wit the steps to reproduce it. Since fedora isn't quite ready for fips mode I turn it on and off by devious means. Proceed with care. I followed the steps and traced execition with gdb and saw the sha224 power-up self-test fail the compare. I have submitted a patch to the upstream bug and along with it a full test suite for the nss low hash api.
Created attachment 591352 [details] nss-softokn sha224 fips self test fix This patch does fix my issue, and nss works properly in fips mode
It also properly handles the crypt() calls now via freebl for $5$ and $6$ salts.
Thank you Paul for verifiying the fix and attaching a downstream version of the upstream patch - they are effectively the same. The fix consists of using for the nss lowhash self-tests the same expected value as used in softoken .
Created attachment 591641 [details] patch as it was checked in - same as applied upstream
nspr-4.9.1-1.fc17,nss-util-3.13.5-1.fc17,nss-softokn-3.13.5-1.fc17,nss-3.13.5-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/nspr-4.9.1-1.fc17,nss-util-3.13.5-1.fc17,nss-softokn-3.13.5-1.fc17,nss-3.13.5-1.fc17
Package nspr-4.9.1-1.fc17, nss-util-3.13.5-1.fc17, nss-softokn-3.13.5-1.fc17, nss-3.13.5-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nspr-4.9.1-1.fc17 nss-util-3.13.5-1.fc17 nss-softokn-3.13.5-1.fc17 nss-3.13.5-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10451/nspr-4.9.1-1.fc17,nss-util-3.13.5-1.fc17,nss-softokn-3.13.5-1.fc17,nss-3.13.5-1.fc17 then log in and leave karma (feedback).
Package nspr-4.9.1-2.fc17, nss-util-3.13.5-1.fc17, nss-softokn-3.13.5-1.fc17, nss-3.13.5-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nspr-4.9.1-2.fc17 nss-util-3.13.5-1.fc17 nss-softokn-3.13.5-1.fc17 nss-3.13.5-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10451/nspr-4.9.1-2.fc17,nss-util-3.13.5-1.fc17,nss-softokn-3.13.5-1.fc17,nss-3.13.5-1.fc17 then log in and leave karma (feedback).
nspr-4.9.1-2.fc16,nss-util-3.13.5-1.fc16,nss-softokn-3.13.5-1.fc16,nss-3.13.5-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/nspr-4.9.1-2.fc16,nss-util-3.13.5-1.fc16,nss-softokn-3.13.5-1.fc16,nss-3.13.5-1.fc16
confirmed working on f16 and f17. Thanks!
nspr-4.9.1-2.fc17, nss-util-3.13.5-1.fc17, nss-softokn-3.13.5-1.fc17, nss-3.13.5-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
nspr-4.9.1-2.fc16, nss-util-3.13.5-1.fc16, nss-softokn-3.13.5-1.fc16, nss-3.13.5-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 903144 has been marked as a duplicate of this bug. ***