OpenSSL updates, 1.0.2g and 1.0.1s

By Rod Vagg,

(Updates to this post, including a schedule change are included below)

The OpenSSL project has announced 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.

Node.js v0.10 (Maintenance)

A release of Node.js v0.10.43 has been proposed for this week, it currently contains fixes for domains and an important fix for a regression in http_parser that was introduced in v0.10.42. Details of the changes included in this release along with instructions on how to download and use a release candidate (v0.10.43-rc.1) can be found in 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.

Node.js v0.12 (LTS)

A release of Node.js v0.12.11 has been proposed for this week, it currently contains fixes for domains, an important fix for a regression in http_parser that was introduced in v0.12.10, and some other minor fixes. Details of the changes included in this release along with instructions on how to download and use a release candidate (v0.12.11-rc.1) can be found in 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 endeavour to ensure that our v0.12.11 release contains the update.

Node.js v4 (LTS "Argon")

A significant update to Node.js v4 has been proposed for next week, the 8th of March. You can read about what will be included in Node.js v4.4.0 and find release candidates to test against your deployments at 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.

Node.js v5 (Stable)

A regular update to Node.js v5 has been proposed for this week. You can read about what will be included in the proposed Node.js v5.7.1 at 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 endeavour to ensure that our v5.7.1 release contains the update.

Summary

  • 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

Please monitor the nodejs-sec Google Group for updates, including an impact assessment and updated details on release timing within approximately 24 hours after the OpenSSL release: https://groups.google.com/forum/#!forum/nodejs-sec

Contact and future updates

The current Node.js security policy can be found at https://github.com/nodejs/node/security/policy#security.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organization.

(Update 2-Mar-2016) OpenSSL Impact Assessment

Our crypto team (Ben Noordhuis, Shigeki Ohtsu and Fedor Indutny) have performed an analysis of the defects addressed in this week's OpenSSL releases, 1.0.2g and 1.0.1s. The results of this analysis are included below.

The overall impact to Node.js users is low, however we will be producing new versions this week for all of our release lines containing the new versions of OpenSSL in order to provide security assurance.

  • 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.

Release announcements for each of these will be made on the Node.js blog.

CVE-2016-0800: Disable SSLv2 default build, default negotiation and weak ciphers

Assessment:

  • Node.js v0.10 an v0.12 are unaffected, unless manually enabling SSLv2 with --enable-ssl2
  • Node.js v4 and v5 are unaffected

This vulnerability has been labelled the DROWN Attack and only impacts servers supporting SSLv2:

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-ssl2 and --enable-ssl3 command-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-ssl2 command-line argument with node then 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 --enable-ssl2 command-line argument.

CVE-2016-0705: Fix a double-free in DSA code

Assessment: 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 leak

Assessment: 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 corruption

Assessment: 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_hex2bn() and 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 functions

Assessment: 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 exponentiation

Assessment: 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.