March 2018 Node.js security releases are now available. See below for full disclosure of the inclusions and please plan to upgrade your deployed applications.
Summary
Updates are now available for all active Node.js release lines. These include the fix for the vulnerabilities identified in the initial announcement (below).
In addition to the vulnerabilities in the initial announcement, we have also included a fix for a vulnerability in the Node.js inspector functionality. This is described in detail below.
We recommend that all users upgrade as soon as possible.
Downloads & release details
OpenSSL 1.0.2o
OpenSSL version 1.0.2o was released this week. It fixed a
flaw that primarily relates to PKCS#7 that may be used to cause a denial of service (DoS) attack (CVE-2018-0739). As PKCS#7 is not currently supported by Node.js and this flaw does not impact SSL/TLS functionality, our crypto team do not believe this has any impact on Node.js users.
OpenSSL 1.0.2o also contains a small number of code changes that are part of the OpenSSL project's continued code cleanup efforts. It is included in the releases for all Node.js release lines regardless of security impact.
Node.js Inspector DNS rebinding vulnerability (CVE-2018-7160)
Node.js 6.x and later include a
debugger protocol (also known as "inspector") that can be activated by the
--inspect and related command line flags. This debugger service was vulnerable to a
DNS rebinding attack which could be exploited to perform remote code execution.
The attack was possible from malicious websites open in a web browser on the same computer, or another computer with network access to the computer running the Node.js process. A malicious website could use a DNS rebinding attack to trick the web browser to bypass
same-origin-policy checks and to allow HTTP connections to localhost or to hosts on the local network. If a Node.js process with the debug port active is running on localhost or on a host on the local network, the malicious website could connect to it as a debugger, and get full code execution access.
We updated the inspector implementation with an additional check for the browser provided Host header. If the connection is via a hostname, i.e. subject to DNS resolution, we ensure that the connection is to either localhost or localhost6 precisely.
Note that this mitigation may affect some remote debugging scenarios. For example it may no longer be possible to debug a remote computer by using a hostname. Either connect using the IP address or use an ssh-tunnel to work around this additional security check. This change is therefore a
"breaking change", however, as per the
Node.js release plan, we are including this as a security fix on all impacted release lines as a
semver-minor rather than semver-major increment.
Node.js versions 4.x were not vulnerable as the inspector debug protocol is not available in that release line.
The severity of this vulnerability is HIGH due to remote code execution risk. However, the impact should be limited to environments (e.g. development) where debuggers are typically used.
This vulnerability was reported by Timo Schmid.
'path' module regular expression denial of service (CVE-2018-7158)
The
'path' module in the
Node.js 4.x release line contains a potential regular expression denial of service (
ReDoS) vector. The code in question was replaced in Node.js 6.x and later so this vulnerability only impacts all versions of Node.js 4.x.
The regular expression, splitPathRe, used within the 'path' module for the various path parsing functions, including path.dirname(), path.extname() and path.parse() was structured in such a way as to allow an attacker to craft a string, that when passed through one of these functions, could take a significant amount of time to evaluate, potentially leading to a full denial of service.
We have determined the security risk of this vulnerability to Node.js users to be HIGH and recommend upgrading your Node.js 4.x installations as soon as possible.
This vulnerability was reported by James Davis of Virginia Tech.
Spaces in HTTP Content-Length header values are ignored (CVE-2018-7159)
The HTTP parser in all current versions of Node.js ignores spaces in the Content-Length header, allowing input such as Content-Length: 1 2 to be interpreted as having a value of 12. The HTTP specification does not allow for spaces in the Content-Length value and the Node.js HTTP parser has been brought into line on this particular difference.
We have determined the security risk of this flaw to Node.js users to be VERY LOW as it is difficult, and may be impossible, to craft an attack that makes use of this flaw in a way that could not already be achieved by supplying an incorrect value for Content-Length. Vulnerabilities may exist in user-code that make incorrect assumptions about the potential accuracy of this value compared to the actual length of the data supplied. Node.js users crafting lower-level HTTP utilities are advised to re-check the length of any input supplied after parsing is complete.
This change is a
"breaking change" as
Content-Length values containing internal spaces are now rejected in the same way that non-numeric values are rejected. However, as per the
Node.js release plan, we are including this as a security fix on all release lines as a
semver-minor rather than semver-major increment.
This flaw was reported by Сковорода Никита Андреевич (Nikita Skovoroda /
@ChALkeR)
Update root certificates
All releases also include an update to the root certificates that are bundled in the Node.js binary. This includes 8 new additional certificates and the removal of 30 certificates. Details are available in on the public Node.js repository at
https://github.com/nodejs/node/pull/19322.
Node.js uses Mozilla's
NSS root certificate database. Certificates are regularly added to and removed from this database. Occasionally, certificates are revoked due to compliance or trust concerns, as is the case for the
WoSign / StartCom certificates that are being removed in this update.
Please note that the
NODE_EXTRA_CA_CERTS environment variable may be used to add back in certificates that have been removed if required (although this is not advised). In addition the
ca option may be used when creating TLS or HTTPS servers to provide a custom list of trusted certificates.
This update was submitted by Ben Noordhuis.