Bug 1510641
Summary: | rh-nodejs4 encounters a SEGFAULT in SSL_CTX_use_certificate_chain [rhscl-3.1.0] | |||
---|---|---|---|---|
Product: | Red Hat Software Collections | Reporter: | Kyle Walker <kwalker> | |
Component: | nodejs | Assignee: | Zuzana Svetlikova <zsvetlik> | |
Status: | CLOSED ERRATA | QA Contact: | Mirek Długosz <mzalewsk> | |
Severity: | high | Docs Contact: | ||
Priority: | urgent | |||
Version: | rh-nodejs4 | CC: | glamb, jorton, mzalewsk, zsvetlik | |
Target Milestone: | alpha | Flags: | zsvetlik:
needinfo+
|
|
Target Release: | 3.1 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: |
Prior to this update, the Node.js server was unable to correctly handle certificate chains. As a consequence, the Node.js server terminated unexpectedly with a segmentation fault. This bug has been fixed, and users are now able to authenticate using certificate chains.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1513065 1513067 1589027 (view as bug list) | Environment: | ||
Last Closed: | 2017-11-20 14:04:45 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1513065 |
Description
Kyle Walker
2017-11-07 21:47:43 UTC
Just to elaborate, the end failure is specifically in the following code snippet when a connection is accepted. ssl_add_cert_chain() <snip> 1141 for (i = 0; i < sk_X509_num(extra_certs); i++) { 1142 x = sk_X509_value(extra_certs, i); 1143 if (!ssl_add_cert_to_buf(buf, l, x)) 1144 return 0; 1145 } <snip> (gdb) f #11 0x00007ffff6d329dd in ssl_add_cert_to_buf (buf=buf@entry=0x11e4610, l=l@entry=0x7fffffff7200, x=0x12431f0) at ssl_cert.c:1059 1059 n = i2d_X509(x, NULL); (gdb) p *x $11 = { cert_info = 0x7ffff6f5a710 <ssl3_ciphers+10384>, sig_alg = 0x7ffff6f5a5b0 <ssl3_ciphers+10032>, signature = 0x7ffff6f5a768 <ssl3_ciphers+10472>, valid = -151673336, references = 32767, name = 0x7ffff6f596e8 <ssl3_ciphers+6248> "\001", ex_data = { sk = 0x7ffff6f5a450 <ssl3_ciphers+9680>, dummy = -151679760 }, ex_pathlen = 140737336681640, ex_pcpathlen = 140737336675920, ex_flags = 140737336681288, ex_kusage = 140737336680672, ex_xkusage = 140737336679792, ex_nscert = 140737336678736, skid = 0x7ffff6f598a0 <ssl3_ciphers+6688>, akid = 0x7ffff6f597f0 <ssl3_ciphers+6512>, policy_cache = 0x7ffff6f59740 <ssl3_ciphers+6336>, crldp = 0x7ffff6f58df8 <ssl3_ciphers+3960>, altname = 0x7ffff6f58da0 <ssl3_ciphers+3872>, nc = 0x7ffff6f58d48 <ssl3_ciphers+3784>, rfc3779_addr = 0x7ffff6f58820 <ssl3_ciphers+2464>, rfc3779_asid = 0x7ffff6f587c8 <ssl3_ciphers+2376>, sha1_hash = "p\207\365\366\377\177\000\000\030\207\365\366\377\177\000\000\030\250\365\366", aux = 0x7ffff6f5a6b8 <ssl3_ciphers+10296> } The upstream node revision does not suffer from the same issue as the openssl libraries are statically linked in and presumed to be a specific version/API. Therefore, they do not need to override the SSL_CTX_use_certificate_chain() behaviour as the indicated *-Disable-openssl.patch does below: @@ -521,9 +621,20 @@ int SSL_CTX_use_certificate_chain(SSL_CTX* ctx, for (int i = 0; i < sk_X509_num(extra_certs); i++) { X509* ca = sk_X509_value(extra_certs, i); - // NOTE: Increments reference count on `ca` - r = SSL_CTX_add1_chain_cert(ctx, ca); - +#if OPENSSL_VERSION_NUMBER >= 0x10002000L + // If ctx->cert->key != NULL create ctx->cert->key->chain if not + // already there, push 'ca' to this chain and finally increment the ca + // reference count by 1 (this is the diff between *_add1_* and *_add0_* + // - the later increments by 0 ;-)) and return 1. Otherwise or if + // something fails in between, return 0. + r = SSL_CTX_add1_chain_cert(ctx, ca); +#else + // Create ctx->extra_certs if not already there, just push 'ca' to this + // chain and return 1. If something fails, return 0. + // NOTE: 1.0.1- does not support multiple certs having its own chain in + // a single context. There is just one: extra_chain! + r = SSL_CTX_add_extra_chain_cert(ctx, ca); +#endif if (!r) { ret = 0; *issuer = nullptr; Kyle Walker Senior Software Maintenance Engineer - SEG North America Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:3249 |