(Update 11-July-2017) Security releases available

Summary

Updates are now available for all active Node.js release lines as well as the 7.x line. These include the fix for the high severity vulnerability identified in the initial announcement, one additional lower priority Node.js vulnerability in the 4.x release line, as well as some lower priority fixes for Node.js dependencies across the current release lines.

We recommend that users of all these release lines upgrade as soon as possible.

Note: The 0.10.x and 0.12.x release lines are also vulnerable to the Constant Hashtable Seeds vulnerability. We recommend that users of these release lines upgrade to one of the supported LTS release lines.

Node.js-specific security flaws

Constant Hashtable Seeds (CVE-2017-11499)

Node.js was susceptible to hash flooding remote DoS attacks as the HashTable seed was constant across a given released version of Node.js. This was a result of building with V8 snapshots enabled by default which caused the initially randomized seed to be overwritten on startup. Thanks to Jann Horn of Google Project Zero for reporting this vulnerability.

Application code that allows the auth field of the options object used with http.get() to be set to a number can result in an uninitialized buffer being created/used as the authentication string. For example:

Parsing of the auth field has been updated in the 4.x release so that a TypeError will be thrown if the auth field is a number when http.get() is called.

This is a low severity defect and only applies to the 4.x release line.

Vulnerabilities in dependencies

The releases for the affected Node.js release lines have been updated to include the patches need to address the following issues in Node.js dependencies. These are all considered to be low severity for Node.js due to the limited impact or likelihood of exploit in the Node.js environment.

CVE-2017-1000381 - c-ares NAPTR parser out of bounds access

A security vulnerability has been discovered in the c-ares library that is bundled with all versions of Node.js. Parsing of NAPTR responses could be triggered to read memory outside of the given input buffer through carefully crafted DNS reponse packets. The patch recommended in CVE-2017-1000381 has been added to the version of c-ares in Node.js in these releases.

This is a low severity defect and affects all active release lines (4.x, 6.x and 8.x) as well as the 7.x line.

Original post is included below

Summary

The Node.js project will be releasing new versions across all of its active release lines (4.x, 6.x, 8.x) as well as 7.x the week of July 10th 2017 to incorporate a security fix.

Denial of Service Vulnerability

All current versions of v4.x through to v8.x inclusive are vulnerable to an issue that can be used by an external attacker to cause a denial of service. The severity of this vulnerability is high and users of the affected versions should plan to upgrade when a fix is made available.

Impact

Versions 4.x of Node.js are vulnerable

Versions 6.x of Node.js are vulnerable

Versions 7.x of Node.js are vulnerable

Versions 8.x of Node.js are vulnerable

Release timing

Releases will be available at, or shortly after, Tuesday the 11th of July along with disclosure of the details for the vulnerability in order to allow for complete impact assessment by users.

While this is not a critical update, all users of these release lines should upgrade at their earliest convenience.

Original post is included below

The OpenSSL project has announced the immediate availability of OpenSSL version 1.0.2k.

Although the OpenSSL team have determined a maximum severity rating of "moderate", the Node.js crypto team (Ben Noordhuis, Shigeki Ohtsu and Fedor Indutny) have determined the impact to Node users is "low". Details on this determination can be found below.

We will therefore be scheduling releases of all active release lines (7 "Current", 6 "LTS Boron", 4 "LTS Argon") on Tuesday the 31st of January. As releases are made, they will appear on the nodejs.org news feed and this post will also be updated with details.

Node.js Impact Assessment

This is a moderate severity flaw in OpenSSL. By default, Node.js disables RC4 so most users are not affected. As RC4 can be enabled programmatically, it is possible for a Node.js developer to craft code that may be vulnerable to this flaw. Any user activating RC4 in their codebase should prioritise this update.

All active versions of Node.js are affected, but the severity is very low for most users.

As noted by the OpenSSL team, the likelihood of being able to craft a practical attack that uses this flaw is very low. In addition, Node.js enables SSL_OP_SINGLE_DH_USE, further decreasing the chance of a successful exploit of this vulnerability in a Node.js service.

All active versions of Node.js are affected, but the severity is very low for Node.js users.

Some calculations, when run on an Intel Broadwell or later CPU, can produce in erroneous results. This flaw has been previously discussed by the Node.js team on GitHub. It is not believed that practical attacks can be crafted to exploit this vulnerability except in very specific circumstances. Therefore this is a low severity flaw.

All active versions of Node.js are affected, but the severity is very low for Node.js users.

While this is not a critical update, all users of these release lines should upgrade at their earliest convenience.

In addition, our new Node.js v6 LTS "Boron" release line is available beginning with Node.js v6.9.0 (LTS "Boron"). Along with the transition to Long Term Support, this release also contains the following security fixes, specific to v6.x:

Disable auto-loading of openssl.cnf: Don't automatically attempt to load an OpenSSL configuration file, from the OPENSSL_CONF environment variable or from the default location for the current platform. Always triggering a configuration file load attempt may allow an attacker to load compromised OpenSSL configuration into a Node.js process if they are able to place a file in a default location.

Create a unique v8_inspector WebSocket address: Generate a UUID for each execution of the inspector. This provides additional security to prevent unauthorized clients from connecting to the Node.js process via the v8_inspector port when running with --inspect. Since the debugging protocol allows extensive access to the internals of a running process, and the execution of arbitrary code, it is important to limit connections to authorized tools only. Note that the v8_inspector protocol in Node.js is still considered an experimental feature. Vulnerability originally reported by Jann Horn.

All of these vulnerabilities are considered low-severity for Node.js users, however, users of Node.js v6.x should upgrade at their earliest convenience.

Original post is included below

Node.js v6 LTS security inclusions

Next week, on Tuesday the 18th (late evening UTC), the Node.js Foundation will be launching its second new LTS release line, a continuation of the v6.x series of releases. This line will be codenamed "Boron" and the first version will be v6.9.0.

In addition to a change to introduce the process.release.lts property, set to 'Boron', we will also be including 3 low-severity security patches that only apply to the v6.x release series.

The security vulnerabilities being addressed are all low-severity and arise from Node.js dependencies:

These patches will also be included in the new v7.x Current (non-LTS) release series which is due to be launched later this month.

Node.js v6 is affected

Node.js v4 (LTS "Argon") is not affected

Node.js v0.12 (Maintenance) is not affected

Node.js v0.10 (Maintenance) is not affected

CVE-2016-5180 "ares_create_query single byte out of buffer write"

A security vulnerability has been discovered in the c-ares library that is bundled with all versions of Node.js. Due to the difficulty of triggering and making use of this vulnerability we currently consider this a low-severity security flaw for Node.js users.

The patch has already been included in Node.js v6 and we will ensure that patched versions of the remaining affected versions are made available by Tuesday the 18th.

Updates are now available for all active Node.js release lines. These include the recently published versions of OpenSSL 1.0.1 and 1.0.2 as well as fixes for some Node.js-specific security-related defects.

The OpenSSL security fixes included in these updates that impact Node.js are:

Additionally, OpenSSL 1.0.2j was released yesterday and included a fix for CVE-2016-7052. This flaw was introduced in last week's 1.0.2i release, and therefore does not directly impact Node.js.

Node.js-specific security flaws

Also included, are a number of fixes unrelated to the recent OpenSSL releases.

CVE-2016-7099: Wildcard certificates not properly validated

This is a high severity defect that would allow a malicious TLS server to serve an invalid wildcard certificate for its hostname and be improperly validated by a Node.js client. This is due to a flaw in the validation of *. in the wildcard name string.

Originally reported by Alexander Minozhenko and James Bunton (Atlassian).

This is a low severity security defect that that may make HTTP response splitting possible under certain circumstances. If user-input is passed to the reason argument to writeHead() on an HTTP response, a new-line character may be used to inject additional responses.

The fix for this defect introduces a new case where throw may occur when configuring HTTP responses. Users should already be adopting try/catch here.

This was originally reported independently by Evan Lucas and Romain Gaucher.

All versions of Node.js are affected.

Remove support for loading dynamic third-party engine modules

This is a low severity security defect. By default, OpenSSL will load a list of third-party engine modules when the ENGINE_load_builtin_engines() function is used. These are normally not present on a user's system. An attacker may be able to make Node.js load malicious code by masquerading it as one of the dynamic engine modules.

This defect primarily impacts Windows due to the standard DLL search paths. However, UNIX users may also be at risk with a poorly configured LD_LIBRARY_PATH environment variable or /etc/ld.so.conf path list.

Downloads

Please note that this may be the final release of the v0.10 line as support ends in October. Please upgrade to v4 or above if you have not already done so.

Original post is included below

The Node.js project has scheduled updates for all of its active release lines to patch a number of security flaws. These flaws include some of those announced by the OpenSSL project as well as a number of Node.js-specific issues. We do not consider any of these updates to be critical. However, it is strongly recommended that all production instances of Node.js be upgraded when the releases are made available.

We intend to make releases available on or soon after the evening of Tuesday, the 27th of September, 2016, UTC (midday US time).

We consider some of the patches in these releases to be API breaking changes which would normally warrant an increase in the major-version number of Node.js. However, in accordance with our security procedures, we will be delivering these changes in minor-version increases (the y in x.y.z) where appropriate, and patch-version increases in v0.10 an v0.12 releases.

These are the expected version numbers for the releases:

Node.js v6.7.0 (Current)

Node.js v4.6.0 (LTS "Argon")

Node.js v0.12.16 (Maintenance)

Node.js v0.10.47 (Maintenance)

Additional notes:

As per our LTS schedule, support for Node.js v0.10 will cease in October. Therefore, this may be the final release of Node.js v0.10. If you are still using v0.10 in production, it is essential that you plan for a migration to v4 (LTS "Argon") or v6 (LTS to be announced in October) as soon as possible.

In accordance with our security release procedures, we will be limiting changes included in the LTS and Maintenance lines (v4, v0.12, and v0.10) for these updates to only security-related and other critical fixes that provide for maximum stability for users.

Node.js-specific security flaws

Included in these releases will be a number of fixes unrelated to the recent OpenSSL releases. These include:

A high-severity flaw relating to the processing of TLS certificates, impacting all versions of Node.js

A low-severity native code injection vulnerability on Windows, impacting all versions of Node.js

A low-severity HTTP validation error, impacting all versions of Node.js

Full disclosure of fixed vulnerabilities will be provided after all releases are made available for download.

September OpenSSL Releases

The OpenSSL project has announced the general availability of versions 1.0.2i (to be included in Node.js v4 and above) and 1.0.1u (to be included in Node.js v0.10 and v0.12). Our crypto team (Shigeki Ohtsu, Fedor Indutny, and Ben Noordhuis) have performed an analysis of the defects addressed in the OpenSSL releases to determine their impact on Node.js. The results of this analysis are included below.

SWEET32 is a new attack on older block cipher algorithms that use a block size of 64 bits.

As mitigation, OpenSSL has moved DES-based ciphers from the HIGH to MEDIUM group. As Node.js includes HIGH, but not MEDIUM, in its default suite, affected ciphers are no longer included unless the default suite is not used. Node's default TLS cipher suite can be found in the API documentation.

Assessment: All versions of Node.js are affected by this vulnerability.

An overflow can occur in MDC2_Update() under certain circumstances resulting in an out of bounds (OOB) error. This attack is impractical on most platforms due to the size of data required to trigger the OOB error.

Node.js is impacted by this flaw but due to the impracticalities of exploiting it and the very low usage of of MDC-2, it is very low severity for Node.js users.

Assessment: All versions of Node.js are affected by this vulnerability.

An out of bounds (OOB) write can occur in BN_bn2dec() if an application uses this function with an overly large BIGNUM. TLS is not affected because record limits will reject an oversized certificate before it is parsed.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations. This has been demonstrated through a cache-timing attack to be sufficient for an attacker to recover the private DSA key.

This is very low severity for Node.js users due to the difficulty in taking advantage of this attack and because DSA is very rarely used.

Assessment: All versions of Node.js are affected by this vulnerability.

In a DTLS connection where handshake messages are delivered out-of-order, those messages that OpenSSL is not yet ready to process will be buffered for later use. This can be exploited to cause a denial of service (DoS) via memory exhaustion.

As Node.js does not support DTLS, users are not impacted by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

A flaw in the DTLS replay attack protection mechanism that would allow an attacker to force a server to drop legitimate packets for a DTLS connection, resulting in a denial of service (DoS) for that connection.

As Node.js does not support DTLS, users are not impacted by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

Some missing message length checks can result in out of bounds (OOB) reads of up to 2 bytes beyond an allocated buffer. There is a theoretical denial of service (DoS) risk. This only impacts a client or a server which enables client authentication.

Node.js is impacted by this low severity flaw.

Assessment: All versions of Node.js are affected by this vulnerability.

After a thorough assessment of the fixes we were planning on including, we have decided to scale back this security update to only include a subset. We are deferring some fixes while we improve the required API changes in order to decrease the disruption that it may cause to users. The vulnerabilities that the deferred fixes address are low severity.

Note that there is no Node.js v6 release in this set of updates as it is not impacted by the vulnerabilities being patched.

Under certain conditions, V8 may improperly expand memory allocations in the Zone::New function. This could potentially be used to cause a Denial of Service via buffer overflow or as a trigger for a remote code execution.

Although this bug is marked as high severity in the corresponding Chromium release (50.0.2661.102), our assessment is that this is low severity for Node.js users due to the level of difficulty in making use of this vulnerability. However, users are encouraged to upgrade their Node.js installation to ensure they are properly protected.

Node.js v6 (Current) is not affected as of v6.2.0 due to an update to V8 5.0.71.47, versions prior to v6.2.0 are affected

Node.js v5 is affected

Node.js v4 (LTS "Argon") is affected

Node.js v0.12 (Maintenance) is affected

Node.js v0.10 (Maintenance) is affected

CVE-2014-9748 Unsafe use of read/write locks on Windows 2003 and XP in libuv

Prior to libuv version 1.7.4, a flaw in the read/write locks implementation for Windows XP and Windows 2003 could lead to unlocking a CRITICAL_SECTION on the wrong thread, resulting in undefined and potentially unsafe behavior. This problem was identified by Zhou Ran. Node.js v4 and later are not affected as the usage of read/write was replaced with simple mutexes. Further details can be found on the libuv repository.

Downloads

Please note that this may be the final release of the v5.x line as support ends on the 30th of June.

(Update 16-June-2016) Adjusted release schedule

Unfortunately we have to announce that we are delaying our security releases by a week. We have concluded that pushing forward with the releases this week would unnecessarily compromise the quality of the fixes we intended to include. Instead, we will be taking the extra time to be sure that we are delivering the stability and quality that Node.js users expect.

We now intend to make releases available on or soon after Thursday, the 23rd of June, 2016, UTC.

Original post is included below

The Node.js project has scheduled updates for all of its active release lines to patch two security flaws and one security-related usability flaw. We do not consider any of our updates to be critical, however, it is recommended that all production instances of Node.js be upgraded when the releases are made available.

We intend to make releases available on or soon after Thursday, the 16th of June, 2016, UTC.

We consider some of the patches in these releases to be API breaking changes which would normally warrant an increase in the major-version number of Node.js. However, in accordance with our security procedures we will be delivering these changes in minor-version increases (the y in x.y.z) where appropriate, and patch-version increases in v0.10 an v0.12 releases.

Therefore, we expect to be releasing:

Node.js v6.3.0 (Current)

Node.js v5.12.0

Node.js v4.5.0 (LTS "Argon")

Node.js v0.12.15 (Maintenance)

Node.js v0.10.46 (Maintenance)

While we anticipate minimal impact from the breaking changes, please be sure to review the details once they are released and make an assessment regarding the impact on your applications.

Additional notes:

It is our intention to stop releasing critical updates for the v5 release line at the end of this month, you should migrate to to v6 or v4 LTS if you have not already done so.

In accordance with our security release procedures, we will be limiting changes included in the LTS and Maintenance lines (v4, v0.12 and v0.10) for these updates to only security-related and critical fixes to provide maximum stability for users.

V8 security defect

The V8 team has identified and patched a potential security vulnerability. We will be backporting the fix to all active release lines of Node.js. Our current assessment is that this vulnerability should be considered low-severity for Node.js users with an exploit being very difficult to develop and execute.

All versions of Node.js are affected.

HTTP processing security defect (CVE-2016-5325)

We will be including fixes 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.

Security-related HTTP client usability flaw

We intend to also include a patch for HTTP client in Node.js. While we do not consider this to be strictly a security concern for Node.js core, it poses a usability concern that may easily enable users to write code that exposes vulnerabilities in their applications.

The following releases have been made available to include the security updates to OpenSSL discussed in the post below. Please upgrade your Node.js installation as soon as possible in order to be protected against the disclosed vulnerabilities.

Original post is included below, along with an update containing a risk assessment

The OpenSSL project has announced that that they will be releasing versions 1.0.1t and 1.0.2h this week, on Tuesday the 3rd of May, UTC. The releases will fix "several 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, v5 and v6 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. We will 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, v5 and v6 soon after Tuesday, the 3rd of May. It is likely that if upgrades are required that they will be ready on or after Thursday, the 5th of May.

Note that Node.js v5 will be supported until June and will therefore be included in this set of releases.

(Update 4-May-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.2h and 1.0.1t. The results of this analysis are included below.

We will be producing new versions this week for all of our active release lines containing the new versions of OpenSSL in order to provide security assurance. We will provide an update here once all releases are available. We anticipate that they will be available on, or soon after, Thursday the 5th of May, UTC.

A man-in-the-middle (MITM) attacker may be able to execute a padding oracle attack to decrypt traffic when a connection uses an AES-CBC cipher and the server runs on an Intel CPU supporting AES-NI. This is a common configuration for TLS servers.

The OpenSSL project has labelled this vulnerability high severity.

Assessment: All versions of Node.js are affected by this vulnerability.

An overflow can occur in the OpenSSL EVP_EncodeUpdate() function which is used for Base64 encoding of binary data. An attacker must be able to supply large amounts of input data in order to cause an overflow.

Node.js uses the EVP_EncodeUpdate() internally during calls to crypto.Certificate#exportPublicKey() for SPKAC Certificate Signing Requests. User-supplied data must be passed to this method for applications to be vulnerable. This method has been available since Node.js v0.12.

The primary npm registry has, since late 2014, used HTTP bearer tokens to authenticate requests from the npm command-line interface. Due to a design flaw in the CLI, these bearer tokens were sent with every request made by the CLI for logged-in users, regardless of the destination of the request. They should instead only be included for requests made against the registry or registries used for the current install.

This flaw allows an attacker to set up an HTTP server that could collect authentication information they could use to impersonate the users whose tokens they collected. This impersonation would allow them to do anything the compromised users could do, including publishing new versions of packages.

This flaw has been fixed in npm@2.15.1 (npm LTS) and npm@3.8.3. The npm CLI team believes that the fix won't break any existing registry setups, but due to the large number of registry software suites in the wild, it's possible that this change will be breaking in some cases. If so, please file an issue describing the software you're using and how it broke, and the team will work with you to mitigate the breakage.

If you believe that your bearer token may have been leaked, it should be sufficient to invalidate your current npm bearer tokens and to rerun npm login to generate new tokens. Keep in mind that this may cause continuous integration builds in services like Travis to break, in which case you'll need to update the tokens in your CI server's configuration.

Thanks to Mitar, Will White & the team at Mapbox, Max Motovilov, and James Taylor for reporting this vulnerability to npm.

As Node.js ships with npm, releases for the active lines will be made available shortly for your convenience. Please watch the Node.js news feed for the following releases:

v0.10 (Maintenance): Node.js v0.10.44 includes npm LTS v2.15.1. This is a major upgrade of npm from v1 which has previously been deprecated. No fix is being made available for npm v1, please upgrade to npm v2 as soon as possible.

Update: Unfortunately the version of npm that was bundled with Node.js version v0.10.44, v0.12.13 and v4.4.2 did not include the correct version string, npm -v reports 2.15.0, however the code is v2.15.1.

Note that you can upgrade your installed version of npm manually without requiring a Node.js update by using the command npm install npm@2 -g for npm LTS v2.15.2 or npm install npm@3 -g for npm v3.8.5.

]]>https://nodejs.org/en/blog/vulnerability/npm-tokens-leak-march-2016https://nodejs.org/en/blog/vulnerability/npm-tokens-leak-march-2016Thu, 31 Mar 2016 10:41:46 GMT(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.

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

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

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.

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.

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.

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.

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.

]]>https://nodejs.org/en/blog/vulnerability/openssl-march-2016https://nodejs.org/en/blog/vulnerability/openssl-march-2016Mon, 29 Feb 2016 02:08:06 GMTTwo weeks ago we announced the planned release of updates to all active release lines, v0.10, v0.12, v4 and v5, to fix HTTP related vulnerabilities and to upgrade the bundled versions of OpenSSL.

Upon release of the OpenSSL updates we posted an impact assessment for Node.js users. We noted that the updates contained only one minor change that impacted Node.js users.

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.

]]>https://nodejs.org/en/blog/vulnerability/february-2016-security-releaseshttps://nodejs.org/en/blog/vulnerability/february-2016-security-releasesTue, 09 Feb 2016 17:40:00 GMT(Updates to this post, including a schedule change are included below)

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, the exact nature of these defects is uncertain as well as the 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.

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/#!forum/nodejs-sec

(Update 29-Jan-2016) OpenSSL Impact Assessment

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/#!forum/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 (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.

(Update 30-Jan-2016) 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.

]]>https://nodejs.org/en/blog/vulnerability/openssl-and-low-severity-fixes-jan-2016https://nodejs.org/en/blog/vulnerability/openssl-and-low-severity-fixes-jan-2016Wed, 27 Jan 2016 11:34:41 GMTLast week we announced the planned release of patch updates to the v0.12.x, v4.x and v5.x lines to fix two vulnerabilities. That was further amended by the announcement of OpenSSL updates with fixes for vulnerabilities labelled medium severity. The OpenSSL update impacts all active release lines, including v0.10.x.

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-2015-8027 Denial of Service Vulnerability

This critical denial of service (DoS) vulnerability impacts all versions of v0.12.x through to v5.x, inclusive. The vulnerability was discovered by Node.js core team member Fedor Indutny and relates to HTTP pipelining. Under certain conditions an HTTP socket may no longer have a parser associated with it but a pipelined request can trigger a pause or resume on the non-existent parser thereby causing an uncaughtException to be thrown. As these conditions can be created by an external attacker and cause a Node.js service to be shut down we consider this a critical vulnerability. It is recommended that users of impacted versions of Node.js exposing HTTP services upgrade to the appropriate patched versions as soon as practical.

CVE-2015-6764 V8 Out-of-bounds Access Vulnerability

A bug was discovered in V8's implementation of JSON.stringify() that can result in out-of-bounds reads on arrays. The patch was included in this week's update of Chrome Stable. While this bug is high severity for browsers, it is considered lower risk for Node.js users as it requires the execution of third-party JavaScript within an application in order to be exploitable.

Node.js users who expose services that process untrusted user-supplied JavaScript are at obvious risk. However, we recommend that all users of impacted versions of Node.js upgrade to the appropriate patched version in order to protect against malicious third-party JavaScript that may be executed within a Node.js process by other means.

A bug exists in OpenSSL v1.0.2 in the Montgomery squaring procedure on the x64 architecture that expose potential attack vectors. Attacks against RSA and DSA are considered possible but with a very high degree of difficulty. Attacks against DHE key exchange is considered feasible but difficult. EC algorithms are not vulnerable. Node.js TLS servers using DHE key exchange are considered at highest risk although it is believed that Node.js' existing use of SSL_OP_SINGLE_DH_USE may make DHE attacks impractical. Details are available at http://openssl.org/news/secadv/20151203.txt.

OpenSSL v1.0.2 is used in Node.js v4.x LTS and v5.x. It is strongly recommended that Node.js users exposing TLS servers upgrade to patched versions as soon as practical.

A bug exists in OpenSSL v1.0.1 and v1.0.2 that may cause a crash during certificate verification procedures when supplied with a malformed ASN.1 signature using the RSA PSS algorithm. This may be used as a the basis of a denial of service (DoS) attack against Node.js TLS servers using client authentication. Node.js TLS clients are also impacted if supplied with malformed certificates for verification. Details are available at http://openssl.org/news/secadv/20151203.txt.

OpenSSL v1.0.0 is used in Node.js v0.10.x and v0.12.x. OpenSSL v1.0.2 is used in Node.js v4.x LTS and v5.x. It is strongly recommended that Node.js users employing either TLS client or server code upgrade as soon as practical.

Note: Node.js users are not considered vulnerable to the two additional announced OpenSSL vulnerabilities: CVE-2015-3195 "X509_ATTRIBUTE memory leak" and CVE-2015-3196 "Race condition handling PSK identify hint". However, fixes for these bugs are included with the new versions of OpenSSL bundled with the newly patched versions of Node.js.

]]>https://nodejs.org/en/blog/vulnerability/december-2015-security-releaseshttps://nodejs.org/en/blog/vulnerability/december-2015-security-releasesFri, 04 Dec 2015 03:05:00 GMTThe OpenSSL project announced today that they will be releasing security updates for versions 1.0.2, 1.0.1, 1.0.0 and 0.9.8 on the 3rd of December UTC. The updates will fix a number of security defects, the highest of which is classified as "moderate" severity according to their severity scale:

MODERATE Severity. This includes issues like crashes in client applications, flaws in protocols that are less commonly used (such as DTLS), and local flaws. These will in general be kept private until the next release, and that release will be scheduled so that it can roll up several such flaws at one time.

Node.js versions v0.10.x and v0.12.x depend on OpenSSL v1.0.1 and versions v4.x (LTS Argon) and v5.x depend on OpenSSL v1.0.2. As the Node.js build process statically links OpenSSL into binaries, we will be required to release patch-level updates to all of our actively supported versions to include the upstream fixes. While we are unaware of the exact nature of the OpenSSL vulnerabilities being fixed, we must consider it likely that Node.js releases will be required in order to protect users.

Since the OpenSSL release schedule is two days after our announced updates for v0.12.x, v4.x and v5.x, we have decided to postpone our security releases to coincide with OpenSSL release availability. We will also be including v0.10 in our set of releases.

Therefore, we are moving our planned security releases for Node.js from Wednesday the 2nd of December 2015, UTC to the Friday, the 4th of December 2015, UTC(Thursday the 3rd of December US time). We understand that the timing of this during the work-week is unfortunate but we must take into account the possibility of introducing a vulnerability gap between disclosure of OpenSSL vulnerabilities and patched releases by Node.js and therefore must respond as quickly as practical. Please be aware that patching and testing of OpenSSL updates is a non-trivial exercise and there will be significant delay after the OpenSSL releases before we can be confident that Node.js builds are stable and suitable for release.

An updated summary of the release inclusions is available below:

CVE-2015-8027 Denial of Service Vulnerability

A bug exists in Node.js, all versions of v0.12.x through to v5.x inclusive, whereby an external attacker can cause a denial of service. The severity of this issue is high and users of the affected versions should plan to upgrade when a fix is made available.

Versions 0.10.x of Node.js are not affected.

Versions 0.12.x of Node.js are vulnerable.

Versions 4.x, including LTS Argon, of Node.js are vulnerable.

Versions 5.x of Node.js are vulnerable.

CVE-2015-6764 V8 Out-of-bounds Access Vulnerability

An additional bug exists in Node.js, all versions of v4.x and v5.x, whereby an attacker may be able to trigger an out-of-bounds access and/or denial of service if user-supplied JavaScript can be executed by an application. The severity of this issue is considered medium for Node.js users, but only under circumstances where an attacker may cause user-supplied JavaScript to be executed within a Node.js application. Fixes will be shipped for the v4.x and v5.x release lines along with fixes for CVE-2015-8027.

Versions 0.10.x of Node.js are not affected.

Versions 0.12.x of Node.js are not affected.

Versions 4.x, including LTS Argon, of Node.js are vulnerable.

Versions 5.x of Node.js are vulnerable.

OpenSSL Moderate Severity Update

The OpenSSL project has announced a set of releases which contain fixes for multiple vulnerabilities, the highest severity being labelled "moderate". Consult the OpenSSL security policy for details on this definition. New releases of all actively maintained Node.js release lines are required in order to protect users against potential vulnerabilities in their applications. We do not have details on the nature of any of the included vulnerabilities or their fixes, users should plan for upgrades as soon as practical.

CVE-2015-8027 Denial of Service Vulnerability

Description and CVSS Score

A bug exists in Node.js, all versions of v0.12.x through to v5.x inclusive, whereby an external attacker can cause a denial of service. The severity of this issue is high (see CVSS scoring below) and users of the affected versions should plan to upgrade when a fix is made available.

Versions 0.10.x of Node.js are not affected.

Versions 0.12.x of Node.js are vulnerable.

Versions 4.x, including LTS Argon, of Node.js are vulnerable.

Versions 5.x of Node.js are vulnerable.

Full details of this vulnerability are embargoed until new releases are available on Wednesday the 2nd of December 2015, UTC(Tuesday the 1st of December US time).

CVE-2015-6764 V8 Out-of-bounds Access Vulnerability

Description and CVSS Score

An additional bug exists in Node.js, all versions of v4.x and v5.x, whereby an attacker may be able to trigger an out-of-bounds access and/or denial of service if user-supplied JavaScript can be executed by an application. The severity of this issue is considered medium for Node.js users (see CVSS scoring below), but only under circumstances where an attacker may cause user-supplied JavaScript to be executed within a Node.js application. Fixes will be shipped for the v4.x and v5.x release lines along with fixes for CVE-2015-8027.

Versions 0.10.x of Node.js are not affected.

Versions 0.12.x of Node.js are not affected.

Versions 4.x, including LTS Argon, of Node.js are vulnerable.

Versions 5.x of Node.js are vulnerable.

Full details of this vulnerability are embargoed until new releases are available on Wednesday the 2nd of December 2015, UTC(Tuesday the 1st of December US time).

Action and updates

New releases of v0.12.x, v4.x and v5.x on Wednesday the 2nd of December 2015, UTC will be made available with appropriate fixes for CVE-2015-8027 and CVE-2015-6764 (for v4.x and v5.x only) along with disclosure of the details of the bug to allow for complete impact assessment by users.

Contact and future updates

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

]]>https://nodejs.org/en/blog/vulnerability/cve-2015-8027_cve-2015-6764https://nodejs.org/en/blog/vulnerability/cve-2015-8027_cve-2015-6764Wed, 25 Nov 2015 22:06:05 GMTA memory corruption vulnerability, which results in a denial-of-service, was
identified in the versions of V8 that ship with Node.js 0.8 and 0.10. In
certain circumstances, a particularly deep recursive workload that may trigger
a GC and receive an interrupt may overflow the stack and result in a
segmentation fault. For instance, if your work load involves successive
JSON.parse calls and the parsed objects are significantly deep, you may
experience the process aborting while parsing.

This issue was identified by Tom Steele of ^Lift
Security and Fedor Indunty, Node.js Core Team member
worked closely with the V8 team to find our resolution.

Remediation

Mitigation

To mitigate against deep JSON parsing you can limit the size of the string you
parse against, or ban clients who trigger a RangeError for parsing JSON.

There is no specific maximum size of a JSON string, though keeping the max to
the size of your known message bodies is suggested. If your message bodies
cannot be over 20K, there's no reason to accept 1MB bodies.

For web frameworks that do automatic JSON parsing, you may need to configure
the routes that accept JSON payloads to have a maximum body size.

First and foremost these releases address the current OpenSSL vulnerability
CVE-2014-0224,
for both 0.8 and 0.10 we've upgraded the version of the bundled OpenSSL to
their fixed versions v1.0.0m and v1.0.1h respectively.

Additionally these releases address the fact that V8 UTF-8 encoding would allow
unmatched surrogate pairs. That is to say, previously you could construct a
valid JavaScript string (which are stored internally as UCS-2), pass it to a
Buffer as UTF-8, send and consume that string in another process and it would
fail to interpret because the UTF-8 string was invalid.

Note, the results encoded by V8 in this case are exactly what was passed into
the encoding routine. There is no overflow, underflow, or the inclusion of
other arbitrary memory, merely an unmatched UTF-8 surrogate resulting in
invalid UTF-8.

As of these releases, if you try and pass a string with an unmatched surrogate
pair, Node will replace that character with the unknown unicode character
(U+FFFD). To preserve the old behavior set the environment variable
NODE_INVALID_UTF8 to anything (even nothing). If the environment variable is
present at all it will revert to the old behavior.

This breaks backward compatibility for the specific reason that unsanitized
strings sent as a text payload for an RFC compliant WebSocket implementation
should result in the disconnection of the client. If the client attempts to
reconnect and receives another invalid payload it must disconnect again. If
there is no logic to handle the reconnection attempts, this may lead to a
denial of service attack. For instance socket.io attempts to reconnect by
default.

// Prior to these releases:newBuffer('ab\ud800cd','utf8');// <Buffer 61 62 ed a0 80 63 64>// After this release:newBuffer('ab\ud800cd','utf8');// <Buffer 61 62 ef bf bd 63 64>// This is an explicit conversion to a Buffer, but the implicit// .write('ab\ud800cd') also results in the same pattern
websocket.write(newBuffer('ab\ud800cd','utf8'));// This would result in the client disconnecting.

Node's default encoding for strings is UTF-8, so even if you're not
explicitly creating Buffers out of strings, Node may be doing so under the
hood. If what you're passing is not actually UTF-8 then when you call
.write(str) you could be specific and say .write(str, 'binary') which
signals Node to pass the string through without interpreting it.

You can also mitigate this in pure JavaScript by sanitizing your strings, as an
example see
node-unicode-sanitize
which will similarly replace unmatched surrogate pairs with the unknown unicode
character.

Thanks to Node.js alum Felix Geisendörfer for finding, getting the fixes
upstreamed, and helping
with the testing and mitigation. Also for helping to inform and improve the
process for Node.js security issues.

To float these fixes in your own builds you can apply the following patch with
git am

]]>https://nodejs.org/en/blog/vulnerability/openssl-and-utf8https://nodejs.org/en/blog/vulnerability/openssl-and-utf8Mon, 16 Jun 2014 15:46:10 GMTNode.js is vulnerable to a denial of service attack when a client
sends many pipelined HTTP requests on a single connection, and the
client does not read the responses from the connection.

We recommend that anyone using Node.js v0.8 or v0.10 to run HTTP
servers in production please update as soon as possible.

This is fixed in Node.js by pausing both the socket and the HTTP
parser whenever the downstream writable side of the socket is awaiting
a drain event. In the attack scenario, the socket will eventually
time out, and be destroyed by the server. If the "attacker" is not
malicious, but merely sends a lot of requests and reacts to them
slowly, then the throughput on that connection will be reduced to what
the client can handle.

There is no change to program semantics, and except in the
pathological cases described, no changes to behavior.

If upgrading is not possible, then putting an HTTP proxy in front of
the Node.js server can mitigate the vulnerability, but only if the
proxy parses HTTP and is not itself vulnerable to a pipeline flood
DoS.

For example, nginx will prevent the attack (since it closes
connections after 100 pipelined requests by default), but HAProxy in
raw TCP mode will not (since it proxies the TCP connection without
regard for HTTP semantics).

A carefully crafted attack request can cause the contents of the HTTP parser's buffer to be appended to the attacking request's header, making it appear to come from the attacker. Since it is generally safe to echo back contents of a request, this can allow an attacker to get an otherwise correctly designed server to divulge information about other requests. It is theoretically possible that it could enable header-spoofing attacks, though such an attack has not been demonstrated.

Versions affected: All versions of the 0.5/0.6 branch prior to 0.6.17, and all versions of the 0.7 branch prior to 0.7.8. Versions in the 0.4 branch are not affected.

Details

A few weeks ago, Matthew Daley found a security vulnerability in Node's HTTP implementation, and thankfully did the responsible thing and reported it to us via email. He explained it quite well, so I'll quote him here:

There is a vulnerability in node's http_parser binding which allows information disclosure to a remote attacker:

In node::StringPtr::Update, an attempt is made at an optimization on certain inputs (node_http_parser.cc, line 151). The intent is that if the current string pointer plus the current string size is equal to the incoming string pointer, the current string size is just increased to match, as the incoming string lies just beyond the current string pointer. However, the check to see whether or not this can be done is incorrect; "size" is used whereas "size_" should be used. Therefore, an attacker can call Update with a string of certain length and cause the current string to have other data appended to it. In the case of HTTP being parsed out of incoming socket data, this can be incoming data from other sockets.

Normally node::StringPtr::Save, which is called after each execution of http_parser, would stop this from being exploitable as it converts strings to non-optimizable heap-based strings. However, this is not done to 0-length strings. An attacker can therefore exploit the mistake by making Update set a 0-length string, and then Update past its boundary, so long as it is done in one http_parser execution. This can be done with an HTTP header with empty value, followed by a continuation with a value of certain length.

The fix landed on 7b3fb22 and c9a231d, for master and v0.6, respectively. The innocuous commit message does not give away the security implications, precisely because we wanted to get a fix out before making a big deal about it.

The first releases with the fix are v0.7.8 and 0.6.17. So now is a good time to make a big deal about it.

If you are using node version 0.6 in production, please upgrade to at least v0.6.17, or at least apply the fix in c9a231d to your system. (Version 0.6.17 also fixes some other important bugs, and is without doubt the most stable release of Node 0.6 to date, so it's a good idea to upgrade anyway.)

I'm extremely grateful that Matthew took the time to report the problem to us with such an elegant explanation, and in such a way that we had a reasonable amount of time to fix the issue before making it public.