Bug 1000036

Summary: devel:languages:nodejs/nodejs: CA certificates broken on SLE11
Product: [openSUSE] openSUSE.org Reporter: Andrew Daugherity <adaugherity>
Component: 3rd party softwareAssignee: Adam Majer <amajer>
Status: RESOLVED FIXED QA Contact: E-mail List <opensuse-communityscreening>
Severity: Normal    
Priority: P5 - None CC: amajer, meissner, mrueckert
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: SLES 11   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on: 1001707    
Bug Blocks:    

Description Andrew Daugherity 2016-09-20 21:45:22 UTC
After https://build.opensuse.org/request/show/424285 was added, anything using the system CA certificate directory is broken on SLE_11_SP4 (simple test: 'npm ping', which fails with 'Error: unable to get local issuer certificate').  npm is unable to access the registry, and anything in Node making SSL connections fails.

This appears to be because the certificate hashing algorithm changed between openssl 0.9.8 (shipped in SLES 11) and 1.0+ (1.0.2 is bundled with Node.js) -- see the -subject_hash and -subject_hash_old options in x509(1ssl).  Running npm under strace confirms this:
==== SLES 11 ====
npm http request GET https://registry.npmjs.org/-/ping?write=true
stat("/etc/ssl/certs/4a6481c9.0", 0x7fffdc5e9fb0) = -1 ENOENT (No such file or directory)
stat("/etc/ssl/certs/73af33e2.0", 0x7fffdc5e9fb0) = -1 ENOENT (No such file or directory)

==== Leap 42.1 ====
stat("/etc/ssl/certs/4a6481c9.0", {st_mode=S_IFREG|0444, st_size=1354, ...}) = 0ches userconfig)
====

On 42.1, that is a symlink to GlobalSign_Root_CA_-_R2.pem, which is indeed the CA for registry.npmjs.org.  On SLES 11, however, the hash link is "111e6273.0", which matches the "subject_hash_old":
====
leap421:/etc/ssl/certs $ openssl x509 -noout -subject_hash -subject_hash_old  -in GlobalSign_Root_CA_-_R2.pem
4a6481c9
111e6273
====

Workarounds include copying the CA certificate directory from a Leap/SLE12 machine, or copying the SLE11 certs to a newer machine, running c_rehash, and copying back (optionally to a new directory we point node at); this is better than disabling 'strict-ssl' in npm but not great.

Since the system CA cert dir from SLE11 is not usable by the openssl bundled with Node, it's probably best to disable the "use-system-ca-store" patch for SLE11 and let Node.js use its built-in bundle.  I'll submit a request in OBS if this is an acceptable solution.
Comment 1 Adam Majer 2016-09-21 14:06:57 UTC
If the patch is reverted, then the CA store that is used is upstream's bundled CA blob and system CA store is ignored, which is not very good.

I think the best way would be to patch OpenSSL shipped with NodeJS, just for the SLE11 people, so that that the certificate hash function is the same as in the old version of OpenSSL. Now I'm not certain of the amount of work required for this, but if it's not too much, then this may be better option. But then this has problems because SLE11 apparently has OpenSSL 1.x in its security module. So...

Another option would be to ship c_rehash binary from NodeJS in-tree version in libexec path that then can be used by users still on SLE11 and affected to relink things.
Comment 2 Marcus Meissner 2016-09-21 14:45:47 UTC
We have already a method for that with the SECURITY Module and its openssl1 version.

If that openssl1 package is installed, it will create both hashes.
Comment 3 Adam Majer 2016-09-21 14:50:40 UTC
Thank you. Then the solution is add depend on openssl1 for SLE11.
Comment 4 Andrew Daugherity 2016-09-21 23:21:04 UTC
I just tested enabling the SLE11-Security-Module repo and installing the 'openssl1' package, and the openssl1 hashes were NOT automatically created.  The %post/%postun scripts of the openssl-certs package will generate the hashes if openssl1 is already present, but there's no trigger to do this upon installation of openssl1.  (Doing a force reinstall of openssl-certs does generate both styles of hashes.)

Because of this, just having nodejs depend on openssl1 won't directly solve the issue, and creates new ones -- how do we tell users to enable the SLE11-Security-Module, let alone reinstall openssl-certs?  If someone just searches OBS for nodejs and then attempts to install the package from d:l:nodejs, it will fail with missing deps of openssl1.

This would be a reasonable solution, if not for those issues...
Comment 5 Adam Majer 2016-09-27 15:10:35 UTC
Yes, I can confirm this problem. Installing openssl1 is insufficient. c_rehash1 is not run by openssl1 by default.

Marcus, what is the proper procedure here? Is this 

  1. a bug in openssl1, or 
  2. another package is missing, or 
  3. users of openssl1 should run c_rehash1 manually?
Comment 6 Marcus Meissner 2016-09-28 06:50:26 UTC
The c_rehash script of openssl will also generate openssl1 hashes when run and the openssl1 commandline tool is installed.


openssl-certs %post runs this script during install/update, but you can also run it if needed.

hmm.
Comment 7 Marcus Rückert 2016-09-28 14:39:27 UTC
(In reply to Marcus Meissner from comment #6)
> The c_rehash script of openssl will also generate openssl1 hashes when run
> and the openssl1 commandline tool is installed.
> 
> 
> openssl-certs %post runs this script during install/update, but you can also
> run it if needed.
> 
> hmm.

imho the only clean solution is to call c_rehash1 in the %post of openssl1.

having other packages call it, is putting the responsibility into the wrong places.
Comment 8 Marcus Meissner 2016-09-28 14:44:48 UTC
we can also do that additionaly, yes.
Comment 9 Adam Majer 2016-09-29 10:20:15 UTC
Andrew, the nodejs package is now fixed in the devel project. Bug will remain opened until it's fixed in the openssl1 package. Until then, the workaround is to run c_rehash manually after installing nodejs if it cannot find some certificates.
Comment 10 Adam Majer 2017-02-02 14:26:20 UTC
fixed when openssl1 gets through the QA process.
Comment 12 Swamp Workflow Management 2017-03-29 16:13:43 UTC
SUSE-SU-2017:0855-1: An update that solves three vulnerabilities and has one errata is now available.

Category: security (moderate)
Bug References: 1000036,1009528,1022085,1022086
CVE References: CVE-2016-7055,CVE-2017-3731,CVE-2017-3732
Sources used:
SUSE Linux Enterprise Module for Web Scripting 12 (src):    nodejs4-4.7.3-14.1
SUSE Enterprise Storage 4 (src):    nodejs4-4.7.3-14.1
Comment 13 Swamp Workflow Management 2017-04-05 16:20:27 UTC
openSUSE-SU-2017:0941-1: An update that solves three vulnerabilities and has one errata is now available.

Category: security (moderate)
Bug References: 1000036,1009528,1022085,1022086
CVE References: CVE-2016-7055,CVE-2017-3731,CVE-2017-3732
Sources used:
openSUSE Leap 42.2 (src):    nodejs4-4.7.3-5.3.1
Comment 14 Swamp Workflow Management 2018-09-20 13:10:06 UTC
This is an autogenerated message for OBS integration:
This bug (1000036) was mentioned in
https://build.opensuse.org/request/show/636889 42.3+Backports:SLE-12 / nodejs8
Comment 15 Swamp Workflow Management 2018-10-17 10:40:06 UTC
This is an autogenerated message for OBS integration:
This bug (1000036) was mentioned in
https://build.opensuse.org/request/show/642571 42.3+Backports:SLE-12 / nodejs8
Comment 16 Swamp Workflow Management 2018-11-16 14:00:06 UTC
This is an autogenerated message for OBS integration:
This bug (1000036) was mentioned in
https://build.opensuse.org/request/show/649577 Backports:SLE-12-SP2 / nodejs8
Comment 19 Swamp Workflow Management 2019-12-11 20:19:44 UTC
SUSE-SU-2019:14246-1: An update that fixes 118 vulnerabilities is now available.

Category: security (important)
Bug References: 1000036,1001652,1025108,1029377,1029902,1040164,104105,1042670,1043008,1044946,1047925,1047936,1048299,1049186,1050653,1056058,1058013,1066242,1066953,1070738,1070853,1072320,1072322,1073796,1073798,1073799,1073803,1073808,1073818,1073823,1073829,1073830,1073832,1073846,1074235,1077230,1079761,1081750,1082318,1087453,1087459,1087463,1088573,1091764,1094814,1097158,1097375,1097401,1097404,1097748,1104841,1105019,1107030,1109465,1117473,1117626,1117627,1117629,1117630,1120644,1122191,1123482,1124525,1127532,1129346,1130694,1130840,1133452,1133810,1134209,1138459,1140290,1140868,1141853,1144919,1145665,1146090,1146091,1146093,1146094,1146095,1146097,1146099,1146100,1149323,1153423,1154738,1447070,1447409,744625,744629,845955,865853,905528,917607,935856,937414,947747,948045,948602,955142,957814,957815,961254,962297,966076,966077,985201,986541,991344,998743
CVE References: CVE-2013-2882,CVE-2013-6639,CVE-2013-6640,CVE-2013-6668,CVE-2014-0224,CVE-2015-3193,CVE-2015-3194,CVE-2015-5380,CVE-2015-7384,CVE-2016-2086,CVE-2016-2178,CVE-2016-2183,CVE-2016-2216,CVE-2016-5172,CVE-2016-5325,CVE-2016-6304,CVE-2016-6306,CVE-2016-7052,CVE-2016-7099,CVE-2017-1000381,CVE-2017-10686,CVE-2017-11111,CVE-2017-11499,CVE-2017-14228,CVE-2017-14849,CVE-2017-14919,CVE-2017-15896,CVE-2017-15897,CVE-2017-17810,CVE-2017-17811,CVE-2017-17812,CVE-2017-17813,CVE-2017-17814,CVE-2017-17815,CVE-2017-17816,CVE-2017-17817,CVE-2017-17818,CVE-2017-17819,CVE-2017-17820,CVE-2017-18207,CVE-2017-3735,CVE-2017-3736,CVE-2017-3738,CVE-2018-0732,CVE-2018-1000168,CVE-2018-12115,CVE-2018-12116,CVE-2018-12121,CVE-2018-12122,CVE-2018-12123,CVE-2018-20406,CVE-2018-20852,CVE-2018-7158,CVE-2018-7159,CVE-2018-7160,CVE-2018-7161,CVE-2018-7167,CVE-2019-10160,CVE-2019-11709,CVE-2019-11710,CVE-2019-11711,CVE-2019-11712,CVE-2019-11713,CVE-2019-11714,CVE-2019-11715,CVE-2019-11716,CVE-2019-11717,CVE-2019-11718,CVE-2019-11719,CVE-2019-11720,CVE-2019-11721,CVE-2019-11723,CVE-2019-11724,CVE-2019-11725,CVE-2019-11727,CVE-2019-11728,CVE-2019-11729,CVE-2019-11730,CVE-2019-11733,CVE-2019-11735,CVE-2019-11736,CVE-2019-11738,CVE-2019-11740,CVE-2019-11742,CVE-2019-11743,CVE-2019-11744,CVE-2019-11746,CVE-2019-11747,CVE-2019-11748,CVE-2019-11749,CVE-2019-11750,CVE-2019-11751,CVE-2019-11752,CVE-2019-11753,CVE-2019-11757,CVE-2019-11758,CVE-2019-11759,CVE-2019-11760,CVE-2019-11761,CVE-2019-11762,CVE-2019-11763,CVE-2019-11764,CVE-2019-13173,CVE-2019-15903,CVE-2019-5010,CVE-2019-5737,CVE-2019-9511,CVE-2019-9512,CVE-2019-9513,CVE-2019-9514,CVE-2019-9515,CVE-2019-9516,CVE-2019-9517,CVE-2019-9518,CVE-2019-9636,CVE-2019-9811,CVE-2019-9812,CVE-2019-9947
Sources used:
SUSE Linux Enterprise Server 11-SP4-LTSS (src):    MozillaFirefox-68.2.0-78.51.4, MozillaFirefox-branding-SLED-68-21.9.8, firefox-atk-2.26.1-2.8.4, firefox-cairo-1.15.10-2.13.4, firefox-gcc5-5.3.1+r233831-14.1, firefox-gcc8-8.2.1+r264010-2.5.1, firefox-gdk-pixbuf-2.36.11-2.8.4, firefox-glib2-2.54.3-2.14.7, firefox-gtk3-3.10.9-2.15.3, firefox-harfbuzz-1.7.5-2.7.4, firefox-libffi-3.2.1.git259-2.3.3, firefox-libffi-gcc5-5.3.1+r233831-14.1, firefox-pango-1.40.14-2.7.4, mozilla-nspr-4.21-29.6.1, mozilla-nss-3.45-38.9.3

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.