OpenSSL upgrade low-severity Node.js security fixes

1,917 views
Skip to first unread message

Rod Vagg

unread,
Jan 27, 2016, 6:28:20 AM1/27/16
to nodejs-sec
Summary

The Node.js project will be releasing new versions across all of its active release lines early next week (possibly sooner, pending full impact assessment) to incorporate upstream patches from OpenSSL and some additional low-severity fixes relating to HTTP handling. Please read on for full details.

OpenSSL

The OpenSSL project announced this week that they will be releasing versions 1.0.2f and 1.0.1r on the 28th of January, UTC. The releases will fix two security 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 are normally 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.

Low-severity Node.js security fixes

In addition, we have some fixes to release relating to Node.js HTTP processing. We categorise these as low-severity and are not aware of any existing exploits leveraging the defects. Full details are embargoed until new releases are available.

Common Vulnerability Scoring System (CVSS) v3 Base Score:

| Metric                      | Score                      |
|-----------------------------|----------------------------|
| **Base Score:**             | 4.8 (Medium)               |
| **Base Vector:**            | CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
| **Attack Vector:**          | Network (AV:N)             |
| **Attack Complexity:**      | High (AC:H)                |
| **Privileges Required:**    | None (PR:N)                |
| **User Interaction:**       | None (UI:N)                |
| **Scope of Impact:**        | Unchanged (S:U)            |
| **Confidentiality Impact:** | Low (C:L)                  |
| **Integrity Impact:**       | Low (I:L)                  |
| **Availability Impact:**    | None (A:N)                 |


Refer to the CVSS v3 Specification for details on the meanings and application of the vector components.

Impact

Both the OpenSSL updates and the Node.js fixes affect all actively maintained release lines of Node.js.

  • Versions 0.10.x of Node.js are affected.
  • Versions 0.12.x of Node.js are affected.
  • Versions 4.x, including LTS Argon, of Node.js are affected.
  • Versions 5.x of Node.js are affected.

Release timing

As the OpenSSL release is planned for late in the week, we are currently planning on deferring Node.js releases until early next week due to the complexity of the upgrade process and a preference for not releasing security fixes at the end of the work-week or on the weekend.

Releases will be available at, or shortly after, Monday the 1st of February, 11pm UTC (Monday the 1st of February, 3pm Pacific Time) along with disclosure of the details defects to allow for complete impact assessment by users.

However, when details of the OpenSSL defects are released on the 28th, our crypto team will be making a more detailed assessment on the likely severity for Node.js users. In the event that the team determines that the fixes are critical in nature for Node.js users we may choose to expedite releases for Friday or Saturday in order to ensure that users have the ability to protect their deployments against a disclosed vulnerability.

Please monitor the nodejs-sec Google Group for updates, including a decision within 24 hours after the OpenSSL release regarding release timing, and full details of the defects upon eventual release: https://groups.google.com/forum/#!topic/nodejs-sec

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact secu...@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 organisation.

Rod Vagg

unread,
Jan 29, 2016, 6:20:58 AM1/29/16
to nodejs-sec
OpenSSL Impact Assessment

OpenSSL versions 1.0.1r and 1.0.21 have been released, the announcement can be found here: https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html

Our team has made an assessment of the impact of the disclosed defects and concluded that there is no urgency in releasing patched versions of Node.js in response to this release. Therefore, we will be proceeding as planned and attempt to release new versions of each of our active release lines on or after Monday the 1st of February, 11pm UTC (Monday the 1st of February, 3pm Pacific Time). Please note that this is simply an approximation of release timing. Please tune in to nodejs-sec (https://groups.google.com/forum/#!topic/nodejs-sec) where we will announce the availability of releases.

Details

DH small subgroups (CVE-2016-0701)

Node.js v0.10 and v0.12 are not affected by this defect.

Node.js v4 and v5 use the SSL_OP_SINGLE_DH_USE option already and are therefore not affected by this defect.

SSLv2 doesn't block disabled ciphers (CVE-2015-3197)

Node.js v0.10 and v0.12 disable SSLv2 by default and are not affected unless the --enable-ssl2 command line argument is being used (not recommended).

Node.js v4 and v5 do not support SSLv2.

An update on DHE man-in-the-middle protection (Logjam)

Previous releases of OpenSSL, included since Node.js v0.10.39, v0.12.5 and v4.0.0, mitigated against Logjam for TLS clients by rejecting connections from servers where Diffie-Hellman parameters were shorter than 768-bits. The new OpenSSL releases, for Node.js v0.10, v0.12 and v4, increases this to 1024-bits.

Node v5 includes a minDHSize option to limit TLS client connections, the default is already 1024-bits.

Note that this item only impacts TLS clients connecting to servers with weak DH parameter lengths.

Rod Vagg

unread,
Jan 31, 2016, 5:42:01 AM1/31/16
to nodejs-sec
Release postponement

The announced security releases will not go ahead for the 1st of February as previously announced. Instead, our new target for release will be on or shortly after Tuesday, the 9th of February, 11pm UTC (Tuesday, the 9th of February, 3pm Pacific Time).

The planned fixes include a backward-incompatible change that, under normal circumstances, would be deferred until the next major-version of Node.js, v6. However, because the fix addresses a security concern that exists across all release lines (including our LTS lines: v4, v0.12 and v0.10) we require the additional time to further review the changes and consider how best to achieve minimal impact to users.

We apologise for any inconvenience this schedule change may cause.

Please tune in to nodejs-sec (https://groups.google.com/forum/#!topic/nodejs-sec) to be notified of any further updates.

Rod Vagg

unread,
Feb 9, 2016, 5:17:42 PM2/9/16
to nodejs-sec

We are pleased to announce the release of Node.js v0.10.42 (Maintenance), v0.12.10 (LTS), v4.3.0 "Argon" (LTS) and v5.6.0 (Stable) with fixes for the announced vulnerabilities and updates to OpenSSL. Please note that our LTS "Argon" release line has moved from v4.2.x to v4.3.x due to the security fixes enclosed. There will be no further updates to v4.2.x. Users are advised to upgrade to v4.3.0 as soon as possible. For the purpose of understanding the impact that the fixed vulnerabilities have on your Node.js deployment and the urgency of the upgrades for your circumstances we are providing details below. CVE-2016-2086 Request Smuggling Vulnerability Régis Leroy reported defects in Node.js that can make request smuggling attacks possible under certain circumstances. To fix these defects, HTTP header parsing in Node.js, for both requests and responses, is moving closer to the formal HTTP specification in its handling of `Content-Length`. While the impact of this vulnerability is application and network dependent, it is likely to be difficult to assess whether a Node.js deployment is vulnerable to attack. We therefore recommend that all users upgrade.

CVE-2016-2216 Response Splitting Vulnerability

Сковорода Никита Андреевич (Nikita Skovoroda / @ChALkeR) and Amit Klein (of Safebreach) separately reported ways in which HTTP header parsing in Node.js can be used to perform response splitting attacks (new-line / CRLF injection). While Node.js has been protecting against response splitting attacks by checking for CRLF characters, it is possible to compose response headers using Unicode characters that decompose to these characters, bypassing the checks previously in place.

To fix this defect, HTTP header parsing in Node.js, for both requests and responses, is moving closer to the formal HTTP specification. HTTP headers containing characters outside of the valid set for tokens will be rejected. This check is performed for both requests and responses, for Node.js HTTP servers and clients.

It is possible that there exist Node.js applications that rely on the lax behaviour of HTTP header parsing for Node.js clients and/or servers. This change is therefore a breaking change that would normally be reserved for a semver-major version increment. However, as per our LTS policy, we are introducing this change as a semver-minor in Node.js v4 (hence the move from v4.2.x to v4.3.x) and v5 and semver-patch in v0.10 and v0.12.

Node.js LTS releases, v0.10.42, v0.12.10 and v4.3.0 (but not v5.6.0) also include a new command-line argument that can be used to turn off this new strict header parsing. By supplying `--security-revert=CVE-2016-2216` when starting Node.js, the previous lenient HTTP header character checks will be used instead. Use of this option is not recommended and should only be used as a temporary migration tool where the implications of reverting the new behavior are fully understood.

We recommend that all users upgrade to receive this fix.

OpenSSL upgrade summary

Node.js v0.10.42 and v0.12.10 upgrades the bundled version of OpenSSL from 1.0.1q to 1.0.1r. Full details can be found in the OpenSSL 1.0.1 changelog.

Node.js v4.3.0 and v5.6.0 upgrades the bundled version of OpenSSL from 1.0.2e to 1.0.2f. Full details can be found in the OpenSSL 1.0.2 changelog.

As per our previous impact assessment, the following applies to these releases:

DH small subgroups (CVE-2016-0701)

Node.js v0.10 and v0.12 are not affected by this defect.

Node.js v4 and v5 use the `SSL_OP_SINGLE_DH_USE` option already and are therefore not affected by this defect.

SSLv2 doesn't block disabled ciphers (CVE-2015-3197)

Node.js v0.10 and v0.12 disable SSLv2 by default and are not affected unless the `--enable-ssl2` command line argument is being used (not recommended).

Node.js v4 and v5 do not support SSLv2.

An update on DHE man-in-the-middle protection (Logjam)


Previous releases of OpenSSL (since Node.js v0.10.39, v0.12.5, v4.0.0 and v5.0.0) mitigated against Logjam for TLS clients by rejecting connections from servers where Diffie-Hellman parameters were shorter than 768-bits.

The new OpenSSL release, for all Node.js lines, increases this to 1024-bits. The change only impacts TLS clients connecting to servers with weak DH parameter lengths.

Reply all
Reply to author
Forward
0 new messages