As promised, the Node.js Foundation updated all maintenance, long-term-support, and stable releases of Node.js to address two critical vulnerabilities.
The patches were announced a week ago and were expected earlier this week, but the Foundation held back the release in order to include the latest OpenSSL version, also patched this week. Node.js 0.10.x (Maintenance) and 0.12.x (LTS) depend on OpenSSL 1.0.1, and Node.js 4.x (LTS Argon) and 5.x depend on OpenSSL 1.0.2.
The latest Node.js versions, 0.10.41 (Maintenance), 0.12.9 (LTS), 4.2.3 Argon (LTS), and 5.1.1 (Stable), address fixes for denial-of-service and out-of-bound access vulnerabilities and are also compiled with the latest OpenSSL libraries, Rod Vagg, the technical steering committee director at Node.js Foundation, wrote in a blog post.
The fact that Node.js Foundation chose to delay its patches to incorporate OpenSSL fixes highlights the reality of open source code. There are so many dependencies between various projects that maintainers have to track bugs in related libraries along with vulnerabilities in their own code. Modern software development typically consists of only 10 percent original code and 90 percent from third-party libraries, said Caleb Fenton, a security researcher with SourceClear. It's the developer's responsibility to make sure the applications don't link to vulnerable libraries.
"It doesn't matter if the vulnerability is a third-party library. Customers will blame the organization if the application gets owned," Fenton said.
Vulnerabilities in Node.js
The Node.js vulnerabilities affected only the LTS and Stable releases, according to Vagg's blog post.
The denial-of-service vulnerability (CVE-2015-8027) impacted all versions of Node.js from v0.12.x to v5.x, inclusive, and was related to HTTP pipelining. The Foundation rated the flaw as critical because an external attacker could create those conditions and shut down the Node.js service running on the targeted system.
"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," Vagg wrote.
Users of impacted versions of Node.js exposing HTTP services should upgrade to the patched versions as soon as it is practical to do so:
- Node.js 0.12.x should upgrade to Node.js 0.12.9 (LTS).
- Node.js 4.x, including LTS Argon, should upgrade to Node.js 4.2.3 Argon (LTS).
- Node.js 5.x should upgrade to Node.js 5.1.1 (Stable).
The out-of-bounds access vulnerability (CVE-2015-6764) was found in V8's implementation of JSON.stringify(). The same issue was patched in this week's update of Chrome Stable and is considered high severity for browsers. The vulnerability poses lower risk for Node.js users as it requires third-party JavaScript to be executed within the application in order to be exploitable, Vagg said.
Node.js users who expose services that process untrusted user-supplied JavaScript are at obvious risk, but all users should update to the new versions since attackers can go with other means to execute third-party JavaScript within a Node.js process:
- Node.js 4.x, including LTS Argon, should upgrade to Node.js 4.2.3 Argon (LTS)
- Node.js 5.x should upgrade to Node.js 5.1.1 (Stable)
Issues in OpenSSL impact Node.js
Even though Node.js 0.10.x (Maintenance) was not impacted by the above-mentioned vulnerabilities, users should still upgrade to the new Maintenance version because it depends on OpenSSL v.1.0.1. The vulnerability in OpenSSL v1.0.1 and 1.0.2 (CVE-2015-3194 ) may cause a crash during certificate verification procedures when supplied with a malformed ASN.1 signature using the RSA PSS algorithm. Attackers would be able to use the flaw as a basis of a denial-of-service attack against Node.js TLS servers using client authentication. Node.js TLS client would also be impacted if malformed certificates are supplied for verification.
Node.js 4.x LTS 5.x was also affected by the bug in the Montgomery squaring procedure in OpenSSL 1.0.2. Attacks against RSA and DSA are considered possible, but "with a very high degree of difficulty," and attacks against DHE key exchange is considered "feasible but difficult."
"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," Vagg said.
Spaghetti code requires coordination
Node.js Foundation has jurisdiction over the popular server-side JavaScript platform. OpenSSL is a completely separate project and maintained by its own team. However, as Heartbleed showed, OpenSSL is widely used in all kinds of applications, so updates to OpenSSL typically cause a ripple effect, which is exactly what happened here.
The Node.js Foundation did the responsible thing by delaying the Node.js release to include the new OpenSSL, since developers now have to update their libraries only once. It's hard enough getting everyone to stay current with patches -- if the Foundation had released the updates as planned, then released another version a few days later with the fixed OpenSSL, that would have caused more disruption. Some developers may miss notification about the second update, or not realize the implications of having an outdated OpenSSL.
Many developers don't even know all the components being used in their applications, making it difficult to tell when a vulnerability in a project actually impacts their code. They may be aware of the libraries they're calling, but not what additional libraries those libraries are including, and the nesting can be several layers deep. And some of those buried libraries may never show up in the program's dependency tree.
Open source code is tightly connected and pervasive. "A vulnerability may have considerable 'reach' into apps far removed," Fenton said. The responsibility for making sure the application contains updated code lies on each library maintainer, the application developer, and everyone else part of the chain. Focusing on just known dependencies or just the original code is shortsighted and doesn't help improve overall application security.