Node: OpenSSL sec releases upcoming

[sam-github]

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t.

These releases will be made available on 10th September 2019 between
approximately 1200-1600 UTC.

These are security fix releases. The highest severity security issue fixed by
these releases is rated as LOW.

• https://mta.openssl.org/pipermail/openssl-announce/2019-September/000156.html

FYI. This will affect all release lines. Since the highest severity is LOW, I propose we handle these not as security releases, but as patch updates to the relevant release lines, using the normal release process.

@nodejs/tsc @nodejs/security @nodejs/security-release @nodejs/security-triage and @rvagg: opinions?

8, 10, and 12.x of Node.js will all need updating.

[rvagg]

@sam-github reasonable proposal.

FYI, though in the past, for this kind of thing, we've announced that we will wait for the releases, make an impact assessment within 24 (or 48?) hours, and decide how to proceed from there. Flag that a likely outcome is that they will be rolled into the normal release process, but depending on the impact assessment we might choose to push out dedicated security releases.

The OpenSSL designations can be a bit sketchy as far as our use of OpenSSL goes, so it might be best not to read too much into "LOW" (as far as Node is concerned it may range from "zero impact cause we don't touch any of these things" to "concerning enough that users will probably want this asap").

[sam-github]

@rvagg in that case, should we make a blog post in the sec category to give a heads up that this is coming, and we'll make an evaluation when we get the releases?

[shigeki]

Node-v8 would be affected by CVE-2019-1552 and I submitted https://github.com/nodejs/node/pull/29455 for the fix.

[mhdawson]

+1 to trying to use regular releases first, and agree we should put out note to nodejs-sec mailing list to give people a heads up.

[addaleax]

If we do bring out security releases, could we add #29399 and #29459 to the releases? They address regressions from the August security releases, so I think that would make sense.

[rvagg]

sorry, was offline for the weekend. all looks good @sam-github and +1 on those two http/2 cleanups from @addaleax, loose ends aren't happy.

[shigeki]

Security Advisory was announced in https://www.openssl.org/news/secadv/20190910.txt.

Here are my assessments.

• ECDSA remote timing attack (CVE-2019-1547)
  Not affected. Node supports only named curves for ECDSA signing.
• Fork Protection (CVE-2019-1549)
  Affected. We do not have the crypto initialization of OPENSSL_INIT_ATFORK. Child processes would have the same random state as the parent. But I think it would be hard to attack it.

• Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey (CVE-2019-1563)
  Not affected. Node does not support PCKS7 and CMS.

[sam-github]

I don't think the fork protection affects us, even theoretically. We do fork, but we always exec after fork. We don't fork and continue running and using the OpenSSL PRNG's forked state.

/to @bnoordhuis @rvagg, thoughts?

[rvagg]

hm, I guess you're right @sam-github, I can't think of a way you could reuse OpenSSL state at all in a forked process but I'm no expert in the code that touches fork / uv_spawn / whatever.

Unless someone comes up with a more definitive agreement either way, I think you could just put out a statement saying something to the effect of

Here's the issues they announced, we're not impacted by 1547, 1563 and we don't _believe_ there's a path to usefully exploit 1549 with Node.js. So we won't be doing dedicated releases but will get this update out with the next version for each release line.

[bnoordhuis]

Sam is right, we only fork-then-exec so no problem there.