Repository navigation
OpenSSL sec releases upcoming #29445
Description
Activity
@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").
@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?
- added a commit that references this issue
on Sep 5, 2019 Node-v8 would be affected by CVE-2019-1552 and I submitted #29455 for the fix.
+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.
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.
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 ofOPENSSL_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.
Reacted by Tobias Nießen-
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?
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.
Sam is right, we only fork-then-exec so no problem there.
- added a commit that references this issue
on Sep 12, 2019
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.