TJ Fontaine of the Node.js project reports: A 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](https://liftsecurity.io/) and Fedor Indunty, Node.js Core Team member worked closely with the V8 team to find our resolution. The V8 issue is described here https://codereview.chromium.org/339883002 It has landed in the Node repository here: https://github.com/joyent/node/commit/530af9cb8e700e7596b3ec812bad123c9fa06356 And has been released in the following versions: * [v0.10.30](http://nodejs.org/dist/v0.10.30) http://blog.nodejs.org/2014/07/31/node-v0-10-30-stable/ * [v0.8.28](http://nodejs.org/dist/v0.8.28) http://blog.nodejs.org/2014/07/31/node-v0-8-28-maintenance/ ### The Fix The backport of the fix for Node.js is ```diff diff --git a/deps/v8/src/isolate.h b/deps/v8/src/isolate.h index b90191d..2769ca7 100644 --- a/deps/v8/src/isolate.h +++ b/deps/v8/src/isolate.h @@ -1392,14 +1392,9 @@ class StackLimitCheck BASE_EMBEDDED { public: explicit StackLimitCheck(Isolate* isolate) : isolate_(isolate) { } - bool HasOverflowed() const { + inline bool HasOverflowed() const { StackGuard* stack_guard = isolate_->stack_guard(); - // Stack has overflowed in C++ code only if stack pointer exceeds the C++ - // stack guard and the limits are not set to interrupt values. - // TODO(214): Stack overflows are ignored if a interrupt is pending. This - // code should probably always use the initial C++ limit. - return (reinterpret_cast<uintptr_t>(this) < stack_guard->climit()) && - stack_guard->IsStackOverflow(); + return reinterpret_cast<uintptr_t>(this) < stack_guard->real_climit(); } private: Isolate* isolate_; ``` ### Remediation The best course of action is to patch or upgrade Node.js. ### 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. * [expressjs](http://expressjs.com) and [krakenjs](http://krakenjs.com) used with the [body-parser](https://github.com/expressjs/body-parser#bodyparserjsonoptions) plugin accepts a `limit` parameter in your JSON config * [Hapi.js](http://hapijs.com) has `payload.maxBytes` https://github.com/spumko/hapi/blob/master/docs/Reference.md * [restify](http://mcavage.me/node-restify/#Bundled-Plugins) bundled `bodyParser` accepts a `maxBodySize` Source: https://groups.google.com/d/msg/nodejs/-siJEObdp10/2xcqqmTHiEMJ
This issue is resolved by the following updates in the listed Fedora releases: Fedora 20: https://admin.fedoraproject.org/updates/v8-3.14.5.10-11.fc20 Fedora 19: https://admin.fedoraproject.org/updates/v8-3.14.5.10-11.fc19 EPEL 6: https://admin.fedoraproject.org/updates/v8-3.14.5.10-11.el6 It is also resolved by the following builds in the listed unreleased products: Fedora Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=549584 Fedora 21 Branched: http://koji.fedoraproject.org/koji/buildinfo?buildID=549585 EPEL 7: http://koji.fedoraproject.org/koji/buildinfo?buildID=549589
Thanks for filing this and for the fixes! It looks like the nodejs packages in Fedora and EPEL use the system version, so those should be OK (if not, they have/are getting version 0.10.30 anyway)
Upstream blog post: http://blog.nodejs.org/2014/07/31/v8-memory-corruption-stack-overflow/
v8-3.14.5.10-11.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
v8-3.14.5.10-11.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
This was assigned CVE-2014-5256: http://seclists.org/oss-sec/2014/q3/505 Also note this comment made by MITRE: """ Also, the specific wording "A memory corruption vulnerability, which results in a denial-of-service, was identified in the versions of V8" was discussed with upstream. The information that we have is that the issue actually should not be considered a vulnerability in V8, and instead should be considered a vulnerability in Node.js. It is not a case where a CVE assignment by Google would have been expected. """
v8-3.14.5.10-11.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
IssueDescription: It was discovered that V8 did not properly check the stack size limit in certain cases. A remote attacker able to send a request that caused a script executed by V8 to use deep recursion could trigger a stack overflow, leading to a crash of an application using V8.
This issue has been addressed in the following products: Red Hat Software Collections 1 for Red Hat Enterprise Linux 7 Red Hat Software Collections 1 for Red Hat Enterprise Linux 6.5 EUS Red Hat Software Collections 1 for Red Hat Enterprise Linux 6.4 EUS Red Hat Software Collections 1 for Red Hat Enterprise Linux 6 Via RHSA-2014:1744 https://rhn.redhat.com/errata/RHSA-2014-1744.html
Statement: Red Hat Product Security has rated this issue as having Low security impact in Red Hat Enterprise Linux OpenStack Platform. This issue is not currently planned to be addressed in a future security update. Red Hat Satellite 6.5 ship v8 however has been rated as a security impact of Moderate, product version Satellite 6.6 onward is not affected. Satellite 6.5 is in Maintenance Support phase of the product life cycle and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Satellite 6 Life Cycle: https://access.redhat.com/support/policy/updates/satellite.