February 29th, 2016(Updates to this post, including a schedule change are included below) The OpenSSL project has announced that that they will be releasing versions 1.0.2g and 1.0.1s this week, on Tuesday the 1st of March, UTC. The releases will fix "several defects" that are labelled as "high" severity under their security policy, meaning they are:
... issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable.Node.js v0.10 and v0.12 both use OpenSSL v1.0.1 and Node.js v4 and v5 both use OpenSSL v1.0.2 and releases from nodejs.org and some other popular distribution sources are statically compiled. Therefore, all active release lines are impacted by this update. At this stage, due to embargo, it is uncertain the exact nature of these defects, nor what impact they will have on Node.js users, if any. As we already had minor, non-security releases scheduled for each of our active release lines during this week and next, we will be adjusting our schedule to adapt to the OpenSSL releases depending on their impact on Node.js users. We will therefore proceed as follows: Within approximately 24 hours of the OpenSSL releases, our crypto team will make an impact assessment for Node.js users of the OpenSSL releases. This information may vary depending for the different active release lines and will be posted here. As part of that impact assessment we will announce our release plans for each of the active release lines to take into account any impact. Please be prepared for the possibility of important updates to Node.js v0.10, v0.12, v4 and v5 soon after Tuesday, the 1st of March. https://github.com/nodejs/node/pull/5404. Node.js v0.10 users are encouraged to test the release candidate build to ensure compatibility with existing deployments. If the OpenSSL 1.0.1s release contains important fixes that impact Node.js v0.10 we will endeavour to ensure that our v0.10.43 release contains the update. https://github.com/nodejs/node/pull/5403. Node.js v0.12 users are encouraged to test the release candidate build to ensure compatibility with existing deployments. If the OpenSSL 1.0.1s release contains important fixes for Node.js v0.12 we will endevour to ensure that our v0.12.11 release contains the update. https://github.com/nodejs/node/pull/5301. If the OpenSSL 1.0.2g update includes important fixes that impact Node.js v4, we may release a v4.3.2 this week with only the security updates in order to provide a low-risk path for Node.js v4 users. If the OpenSSL 1.0.2g update does not include important fixes that impact Node.js v4, we will continue with our planned v4.4.0 release and also attempt to include the OpenSSL 1.0.2g upgrade. Users of Node.js v4 can then upgrade to v4.4.0 in their own time and allow for proper testing of the changes included. https://github.com/nodejs/node/pull/5464. We are excluding any semver-minor changes from this release although it has fixes for some regressions If the OpenSSL 1.0.2g release contains important fixes for Node.js v5, we will endevour to ensure that our v5.7.1 release contains the update.
- Expect an impact assessment of the OpenSSL updates within 24 hours of their release
- Expect releases of Node.js v0.10, v0.12 and v5 this week, possibly containing important security releases
- Expect a Node.js v4.4.0 release next with the possibility of a v4.3.2 security update this week
- v0.10.43 (Maintenance) will proceed as planned for this week, it includes fixes for domains and an important fix for a regression in http_parser that was introduced in v0.10.42. It will also now include an upgrade of OpenSSL to 1.0.1s. An important change will be the complete removal of SSLv2 support, see CVE-2016-0800 below.
- v0.12.11 (LTS) will proceed as planned for this week, it includes fixes for domains, an important fix for a regression in http_parser that was introduced in v0.12.10, and some other minor fixes. It will also now include an upgrade of OpenSSL to 1.0.1s. An important change will be the complete removal of SSLv2 support, see CVE-2016-0800 below.
- v4.4.0 (LTS Argon) will proceed as planned for next week and will include an upgrade of OpenSSL to 1.0.2g. We will also produce a v4.3.2 this week with only the OpenSSL upgrade in order to provide a more conservative upgrade path for users wishing to use the new OpenSSL without having to also include all of the additional non-security fixes in v4.4.0.
- v5.7.1 (Stable) will proceed as planned for this week and will include fixes for a number of regressions introduced in v5.7.0 as well as an upgrade of OpenSSL to 1.0.2g.
CVE-2016-0800: Disable SSLv2 default build, default negotiation and weak ciphersAssessment:
- Node.js v0.10 an v0.12 are unaffected, unless manually enabling SSLv2 with
- Node.js v4 and v5 are unaffected
Modern servers and clients use the TLS encryption protocol. However, due to misconfigurations, many servers also still support SSLv2, a 1990s-era predecessor to TLS. This support did not matter in practice, since no up-to-date clients actually use SSLv2. Therefore, even though SSLv2 is known to be badly insecure, until now, merely supporting SSLv2 was not considered a security problem, because clients never used it. DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.It is important to note that simply supporting SSLv2 on an HTTPS socket enables this vulnerability, regardless of whether clients are actively using SSLv2. Since Node.js v0.10.29, SSLv2 and SSLv3 have been disabled by default. It has remained possible to enable them with the
--enable-ssl3command-line arguments to
node. As these protocols have consistently been demonstrated to be insecure, keeping SSLv2 and SSLv3 disabled has been strongly encouraged. If you are using the
--enable-ssl2command-line argument with
nodethen HTTPS servers are vulnerable to this attack. You should stop using this argument to avoid potential decryption of your secure data. SSLv2 support is being removed Given the additional barriers introduced in OpenSSL 1.0.1s to retaining SSLv2 support and the long list of known SSLv2 vulnerabilities, Node.js v0.10.43 and v0.12.11 will be completely remove SSLv2 support and the
CVE-2016-0705: Fix a double-free in DSA codeAssessment: All versions of Node.js are affected, with low severity This defect allows the use of malformed DSA to be used as a potential Denial of Service (DoS) vector or for causing memory corruption. However it is likely to be very difficult to use in practice and is therefore considered low severity for Node.js users.
CVE-2016-0798: Disable SRP fake user seed to address a server memory leakAssessment: All versions of Node.js are unaffected The Secure Remote Password (SRP) feature of OpenSSL is not exposed via Node.js, therefore all versions are unaffected by this defect.
CVE-2016-0797: Fix BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruptionAssessment: All versions of Node.js may be affected, with low severity This defect can cause memory corruption in certain very rare cases. Additionally, the
BN_dec2bn()functions are not explicitly used in Node.js, however they are used internally by OpenSSL for some APIs. While we are unable to confirm with certainty at this stage, we believe that Node.js is not invoking the code paths that use these functions. Combined with the difficulty of exploiting this defect and the likelihood that Node.js is not using APIs that require the internal use of these functions, this defect is considered to have a very low severity for Node.js users.
CVE-2016-0799: Fix memory issues in BIO_*printf functionsAssessment: All versions of Node.js are unaffected This defect can serve as a potential Denial of Service (DoS) vector or be used for causing memory corruption. The
BIO_*printf()functions are used internally by OpenSSL, however the only path by which an API call by Node.js invokes these functions has a default certificate size limit, which is not changed by Node.js, that removes the possibility of exploiting this defect. Therefore we believe that Node.js is unaffected by this defect.
CVE-2016-0702: Fix side channel attack on modular exponentiationAssessment: All versions of Node.js are affected, with low severity This defect has been labelled the CacheBleed Attack. This defect enables attackers to execute side-channel attacks leading to the potential recovery of entire RSA private keys. It only affects the Intel Sandy Bridge (and possibly older) microarchitecture when using hyper-threading. Newer microarchitectures, including Haswell, are unaffected. Disabling hyper-threading is an option for mitigating against this attack.