Description of problem: I'm seeing a segfault when attempting to use a slightly malformed PEM key. The PEM key is legit except it does not contain any newline characters. The OpenSSL command line tool handles this appropriately by printing "unable to load Private Key" instead of seg faulting. Version-Release number of selected component (if applicable): nss-3.12.3.99.3-2.11.3.fc11.i586 How reproducible: Always Steps to Reproduce: 1. Remove the newlines in the attached key file. 2. Use key file. 3. Passphrase: test Actual results: Segmentation fault Expected results: "Invalid PEM key" or some other type of error message.
Created attachment 353923 [details] test ssl certs ...and I forgot the attachment...
Michael, thank you for the report! Could you please attach the malformed key file? I haven't been able to reproduce the SEGFAULT yet, but valgrind reports "Conditional jump or move depends on uninitialised value(s)". So there is definitely something wrong happening.
Minimal example: $ printf %s '-----BEGIN RSA PRIVATE KEY-----' > test-key.pem
Created attachment 353955 [details] proposed patch patch ready
Created attachment 353960 [details] regression test
Sorry, do you still need my malformed key? You can just take the "test.pem" from my first attachment and backspace through the newlines making one long line. Your minimal example should have the same effect though. It looks like your patch should solve this. I'll test it when there's a build available.
+r
(In reply to comment #6) A scratch build is now available http://koji.fedoraproject.org/koji/taskinfo?taskID=1480334
Created attachment 354050 [details] gdb backtrace The new build seems to bypass the original key SEGFAULT, but now I'm getting a SEGFAULT in another area of nss.
(In reply to comment #9) > The new build seems to bypass the original key SEGFAULT, but now I'm getting a > SEGFAULT in another area of nss. Thanks for your feedback! Willing to open separate bug with some steps to reproduce?
Just for summary, the updated package should fail correctly with the malformed key, does it actually? If yes, I am presuming you are not using the malformed key and then it seems to be not related to the patch and/or the original bug report.
For what's worth, here is scratch build with optimizations turned off http://koji.fedoraproject.org/koji/taskinfo?taskID=1480590
(In reply to comment #11) > Just for summary, the updated package should fail correctly with the malformed > key, does it actually? > I did a little more testing. I can only reproduce this new SEGFAULT with my custom program. If I use my test-libcurl testcase from bug 453612 I cannot reproduce the new SEGFAULT. This bug is FIXED, but I do not have enough info for a new bug on the new SEGFAULT as of yet. I'll try out Elio's new build and open a new bug when I find the time. Thanks.
If you manage to narrow your custom program to a minimal example, it will definitely accelerate the bug fix. Looking at the backtrace I can see you are using curl. Then please report the version of curl, too. Maybe you could try the latest rawhide curl which has slightly improved NSS-related code. I am also going to build new release of rawhide curl next week.
Created attachment 358208 [details] git patch
nss-3.12.4-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/nss-3.12.4-1.fc11
nss-3.12.4-1.fc11 has been pushed to the Fedora 11 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 nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9593
nss-3.12.4-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/nss-3.12.4-2.fc11
nss-3.12.4-2.fc11 has been pushed to the Fedora 11 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 nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9687
nss-3.12.4-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/nss-3.12.4-3.fc11?_csrf_token=d6eee54945d598c83d89d6481b2a20cf972bc76b
nss-3.12.3.99.3-2.10.6.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/nss-3.12.3.99.3-2.10.6.fc10?_csrf_token=316f4db77f425c9db8051b00e270dfcd1200be13
nss-3.12.3.99.3-2.10.6.fc10 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 nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9790
nss-3.12.4-3.fc11 has been pushed to the Fedora 11 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 nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9794
nss-3.12.3.99.3-2.10.6.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.12.4-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
This is still an issue. Just had libnss3.so segfault on CentOS 7.1 system after slapd attempted to do a TLS cert exchange with a key file as follows: -----BEGIN PRIVATE KEY----- key -----END PRIVATE KEY----- system/issue details: CentOS Linux release 7.2.1511 (Core) nss-3.19.1-19.el7_2.x86_64 openldap-2.4.40-8.el7.x86_64 openldap-clients-2.4.40-8.el7.x86_64 openldap-servers-2.4.40-8.el7.x86_64 kernel: slapd[2648]: segfault at 0 ip 00007f0af036c25c sp 00007f0ac0ea6610 error 4 in libnss3.so[7f0af0340000+11e000]
CentOS 7.2 to be correct; typo on my first sentence. Once I repaired the key file with a valid key - slapd TLS works like normal BTW. No more issues but definitely a reproducible segfault w/ details above. Thanks. Tehmasp Chaudhri tehmasp
I am not able to repeat the crash. Does curl crash if you pass such a key file to the --key option (together with --cert and an https:// URL)?
This isn't reproducible via curl. I verified just now and curl does not crash. But specifically when slapd (openldap) is running on a server and using the bad key file then something in the code path causes a segfault in libnss3.so. There's some edge case in libnss (in conjunction w/ how slapd w/ TLS) causes a segfault. My setup is an openldap provider server (w/ bad slapd.key) and an openldap consumer server. When the consumer connects to the provider server which is using the key example above it crashes the openldap provider server. Here are the journal provider slapd.service logs: Jan 19 21:01:20 gcestg-openldap-provider-use1c-01 systemd[1]: Started OpenLDAP Server Daemon. Jan 19 21:01:27 gcestg-openldap-provider-use1c-01 slapd[867]: conn=1000 fd=28 ACCEPT from IP=10.240.0.19:43420 (IP=0.0.0.0:10389) Jan 19 21:01:27 gcestg-openldap-provider-use1c-01 slapd[867]: conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 19 21:01:27 gcestg-openldap-provider-use1c-01 slapd[867]: conn=1000 op=0 STARTTLS Jan 19 21:01:27 gcestg-openldap-provider-use1c-01 slapd[867]: conn=1000 op=0 RESULT oid= err=0 text= Jan 19 21:01:29 gcestg-openldap-provider-use1c-01 systemd[1]: slapd.service: main process exited, code=killed, status=11/SEGV Jan 19 21:01:29 gcestg-openldap-provider-use1c-01 systemd[1]: Unit slapd.service entered failed state. Jan 19 21:01:29 gcestg-openldap-provider-use1c-01 systemd[1]: slapd.service failed. /// Thus, we've got 2 issues IMO (and this may not be the best place to capture all of this) but libnss3.so segfaults and an important piece of software in the RedHat ecosystem - ldap - segfaults badly when consumer servers connect to it. Would hate for someone else to hit up against this issue. Let me know how I can help more. If I somehow find the time I might be able to create a multi-VM vagrant env for repro purposes. Again, we're using the latest CentOS 7.2 w/ updates as of yesterday. Cheers, Tehmasp
So it fails the first time the key is used? It doesn't fail on server startup? (I'm not familiar with openssl cert/key handling). A stacktrace would be incredibly helpful. I'm not sure how the value of "key" could get past the base64 decoding.
Correct; it fails exactly after the ACCEPT from the consumer server. I tested via telnet connecting to the provider server on port 10389 (albeit w/o TLS) and that ACCEPT was all good. As soon as the consumer connects and after the ACCEPT line in the provider's journal slapd.service log the server crashes. Something w/ decoding the key like you say would be my guess as well.
Any chance on getting a stacktrace of the core?
Let me work on this - I need to recreate the environment now as the previous servers are now in active use :)
OK - had to learn how to enable coredumps w/ systemd :) got a couple of coredumps with a bunch of gdb info - particularly: (gdb) bt (gdb) bt full (gdb) info threads (gdb) thread apply all bt (gdb) thread apply all bt full gdb trace w/o debuginfo installed: https://gist.github.com/tehmaspc/1b238c1766549fc5f72f gdb trace w/ debuginfo installed: https://gist.github.com/tehmaspc/67e7c80efb63e1d6fada Thanks, Tehmasp Chaudhri
BTW - this new recreated environment (provider/consumer server) was built w/ my same config management (Salt) tools; same everything to allay any concerns w/ these environments. Reproduced the segfault exactly the same way.
That seems to confirm my suspicions. The bad base64 data isn't being detected and when it is eventually pulled apart as an RSA key it blows up spectacularly.
@Rob - cool; I'll leave it in your court for now. Let me know if I can help further! Cheers, Tehmasp Chaudhri
I have created bug #1300652 to track the newly discovered issue separately.