Red Hat Bugzilla – Bug 479886
keyutil segfaults when trying to create certificate
Last modified: 2009-03-16 15:44:01 EDT
Description of problem: keyutil segfaults when trying to create certificate Version-Release number of selected component (if applicable): crypto-utils-2.4.1-2.i386 nss-3.12.2.0-3.fc10.i386 nss_ldap-261-4.fc10.i386 nss-mdns-0.10-6.fc10.i386 How reproducible: Always (both on x86-64 and i386) Steps to Reproduce: 1. run keyutil -c makecert -g 1024 "CN=127.0.0.1, OU=TEST, O=Test, L=Test, ST=Test, C=SE" -v 1 -a -o test.cert -k priv.cert 2. Hammer the keyboard 3. Press Enter and wait for segmentation fault Actual results: $ gdb --args keyutil -c makecert -g 1024 "CN=127.0.0.1, OU=TEST, O=Test, L=Test, ST=Test, C=SE" -v 1 -a -o test.cert -k priv.cert GNU gdb Fedora (6.8-29.fc10) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (gdb) r Starting program: /usr/bin/keyutil -c makecert -g 1024 CN=127.0.0.1,\ OU=TEST,\ O=Test,\ L=Test,\ ST=Test,\ C=SE -v 1 -a -o test.cert -k priv.cert [Thread debugging using libthread_db enabled] cmdstr: makecert cmd_CreateNewCert command: makecert keysize = 1024 bits valid for 1 months output will be written to test.cert output key written to priv.cert [New Thread 0xb7fed940 (LWP 7507)] A random seed must be generated that will be used in the creation of your key. One of the easiest ways to create a random seed is to use the timing of keystrokes on a keyboard. To begin, type keys on the keyboard until this progress meter is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD! Continue typing until the progress meter is full: |************************************************************| Finished. Press enter to continue: Generating key. This may take a few moments... Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/i386/i486/strlen.S:69 69 L(1): movl (%eax), %ecx /* get word (= 4 bytes) in question */ Current language: auto; currently asm (gdb) bt #0 strlen () at ../sysdeps/i386/i486/strlen.S:69 #1 0x051e8bff in CERT_AsciiToName (string=0x0) at alg1485.c:520 #2 0x0804c62c in keyutil_main (certHandle=0x8060bc8, noisefile=0x0, access_pwd_file=<value optimized out>, key_pwd_file=0x0, cert_to_renew=0x0, input_key_file=0x0, cacert=0, subjectstr=0x0, keysize=1024, warpmonths=0, validityMonths=1, ascii=1, certreqfile=0x8052a0b "tmprequest", certfile=0x8059018 "test.cert", keyoutfile=0x8059028 "priv.cert") at /builddir/build/SOURCES/keyutil.c:1516 #3 0x0804daa3 in main (argc=Cannot access memory at address 0x0 ) at /builddir/build/SOURCES/keyutil.c:1820 (gdb) bt full #0 strlen () at ../sysdeps/i386/i486/strlen.S:69 No locals. #1 0x051e8bff in CERT_AsciiToName (string=0x0) at alg1485.c:520 name = <value optimized out> #2 0x0804c62c in keyutil_main (certHandle=0x8060bc8, noisefile=0x0, access_pwd_file=<value optimized out>, key_pwd_file=0x0, cert_to_renew=0x0, input_key_file=0x0, cacert=0, subjectstr=0x0, keysize=1024, warpmonths=0, validityMonths=1, ascii=1, certreqfile=0x8052a0b "tmprequest", certfile=0x8059018 "test.cert", keyoutfile=0x8059028 "priv.cert") at /builddir/build/SOURCES/keyutil.c:1516 cert = (CERTCertificate *) 0x0 outFile = <value optimized out> subject = <value optimized out> privkey = (SECKEYPrivateKey *) 0x806bc48 pubkey = (SECKEYPublicKey *) 0x806b428 slot = (PK11SlotInfo *) 0x80604b0 pwdata = {source = PW_NONE, data = 0x0} rv = <value optimized out> nullextnlist = {0 <repeats 13 times>} __PRETTY_FUNCTION__ = "keyutil_main" #3 0x0804daa3 in main (argc=Cannot access memory at address 0x0 ) at /builddir/build/SOURCES/keyutil.c:1820 optc = <value optimized out> rv = <value optimized out> cmdstr = 0x8059008 "makecert" noisefile = 0x0 keysize = 1024 validity_months = 1 keyfile = 0x0 outfile = 0x8059018 "test.cert" cert_to_renew = 0x0 subject = 0x0 access_pwd_file = 0x0 key_pwd_file = 0x0 keyoutfile = 0x8059028 "priv.cert" ascii = 1 cacert = 0 certHandle = (CERTCertDBHandle *) 0x0 status = <value optimized out> cmd = cmd_CertReq __PRETTY_FUNCTION__ = "main" (gdb) Expected results: A pair of certificate files Additional info: Selinux is on, but no AVC denials can be seen. $ uname -a Linux Test 2.6.27.9-159.fc10.i686 #1 SMP Tue Dec 16 15:12:04 EST 2008 i686 i686 i386 GNU/Linux
The command invocation keyutil -c makecert -g 1024 "CN=127.0.0.1, OU=TEST, O=Test, L=Test, ST=Test, C=SE" -v 1 -a -o test.cert -k priv.cert is missing a -s before the subject. The options parsing code doesn't detect the -s and keyutil ends up passing a NULL to CERT_AsciiToName() causing the segmentation fault. The tool needs to do command line argument validation. Other errors in keyutil need to be fixed with this one.
Re-assigned to nss since this isn't related to crypto-utils as far as I can see.
Created attachment 329031 [details] proposed fix Joe, it is indeed a bug in crypto-utils' keyutil. The user forgot to include the -s flag before the subject string which caused the subject string to be null. In the attached patch keyutil now checks the subject string and prints an error message if null and bails out. Another hidden bug was that NULL was passed down to the Create Cert routine instead of the extension list.
assigning back to crypto-utils based on Elio's analysis
Assigning it to Bob Relyea for code review.
Question: Did keyutil support a NULL subject before the conversion? It's technically possible to have a cert with a NULL subject as long as there is a real subject in the subject alt extention (it's rare and weird, but legal). bob
(In reply to comment #6) > Question: Did keyutil support a NULL subject before the conversion? By the conversion, do you mean the conversion to using NSS? If so, the answer would be no as keyutil did not exist before that. The user user invoked genkey which is a perl script that via TUI prompted the user for certificate information and passed it down to openssl. The subject was included. After moving to NSS genkey is continues to function in the same manner. If the the NSS database is used genkey calls certutil behind the cover while if Openssl compatibility (pem files) is desired genkey calls keuytil behind the covers. keyutil was intended to be a back-end to genkey. The user in this case called it directly. From my examination of what's supplied he intended to supply a subject but apparently due to a typo the -s was missing before the subject string which tripped keyutil. > > It's technically possible to have a cert with a NULL subject as long as there > is a real subject in the subject alt extention (it's rare and weird, but > legal). > Would the subject alt extension be what in cerutil we pass via the -7 option? keyutil does not support it as it was designed to be the simplest possible application just to support genkey's needs. Nor does it support certificate extensions either as that information wasn't collected by genkey. Once NSS has better PEM support and we could migrate the code to certutil where it probably belongs and keyutil could be retired we would restore some of genkey's earlier simplicity.
OK, then your patch looks good. r+ relyea.
submitted crypto-utils-2.4.1-10 to the Fedora 10 updates-testing repository.
crypto-utils-2.4.1-10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update crypto-utils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1305
Adding comment on build here as I get a error when trying to feedback on the page referenced above. Thanks! The update fixes segfault but I have still two problems, first one is minor; 1. Does not bail out due to missing subject until after random seed have been generated. Should preferably bail out before generating random seed. 2. Does not generate private key file despite writing out that it have done so if given the line: keyutil -c makecert -g 1024 -s "CN=127.0.0.1, OU=TEST, O=Test, L=Test, ST=Test, C=SE" -v 1 -a -o test.cert -k priv.cert
Created attachment 331213 [details] Fix test for Base64 encoding so key gets output.
Thank you Henning. Indeed, the test and bail out should definitely occur before key generation. I have now addressed items 1 and 2 and resubmitted to updates-testing. A Fedora update system notification should be coming soon.
I have tested crypto-utils-2.4.1-12.i386 and there is no change in behavior from crypto-utils-2.4.1-10, concerning the two issues above. Is the patch not applied or missing in the build maybe?
Indeed, the source change never got checked in, sorry. Redid it, tagged crypto-utils-2.4.1-13 and submitted an update to Bodhi. It will take a while to show up. Thanks.
crypto-utils-2.4.1-13.i386 tested from koji build. The early bailout is now working but second issue (missing priv.cert) is still there. Tested both as root and regular user.
crypto-utils-2.4.1-15 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update crypto-utils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1983
crypto-utils-2.4.1-15 tested, still no sign of a priv.cert...
It did when I tested but when using the test release as you do I don't get the private key file just like it happens to you. In gdb I see it bailing out of the key exporting function after generating some random bytes for a temporary password I use to encrypt and then decrypt the key so I can write it the clear (An ugly trick to bypass NSS restrictions on exporting private keys in the clear). I added some innocent-looking print statements to report intermediate failures such as this and the key now shows up. Thank you Henning for your patience and giving me unbiased testing. Let me test and investigate some more.
crypto-utils-2.4.1-16 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/crypto-utils-2.4.1-16
crypto-utils-2.4.1-16 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update crypto-utils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2162
Steps I followed to Verify the fix: installed it with su -c 'yum --enablerepo=updates-testing update crypto-utils'. 0. Created an nss database configiration directory certutil -N -d . (did it without a password) 1. Generated the certificate keyutil -c makecert -g 1024 -s "CN=127.0.0.1, OU=TEST, O=Test, L=Test, ST=Test, C=SE" -v 1 -a -o test.cert -k test.key 2. Hammered the keyboard and pressed Enter and waited for for keyutil to finish The test.key and test./cert did show up and were not empty Does the contents looks okay? 5. The cert and the key should be displayable using the unsupported tool pp /usr/lib64/nss/unsupported-tools/pp -t private-key -a -i test.key /usr/lib64/nss/unsupported-tools/pp -t private-key -a -i test.key pp displayed sensioble output The key and cert should be importable. Just like we import keys from OpenSSL 4. consolidated the two files into a pem file (added a newline at the end of the first) cat test.cert test.key > test.pem 5. Using OpenSSL created a pkcs #12 file openssl pkcs12 -export -in test.pem -out test.p12 -name "Test" 6. Imported the key/cert into NSS with pk12util, you will be prompted for the p12 files passwords (hit enter) and the db password ("test" is as good as any) pk12util -i test.p12 -d . I should say import successfull 7. I was able to list the cert and key using certutil commands certutil -L -d . certutil -L -d Name certutil -K -d . certutil -K -d . -n Test I will push the fix to stable next.
crypto-utils-2.4.1-16 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.