Bug 1125464 (CVE-2014-5256) - CVE-2014-5256 V8 Memory Corruption and Stack Overflow
Summary: CVE-2014-5256 V8 Memory Corruption and Stack Overflow
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2014-5256
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20140731,repor...
Depends On: 1139698
Blocks: 1126262 1139716
TreeView+ depends on / blocked
 
Reported: 2014-07-31 23:45 UTC by T.C. Hollingsworth
Modified: 2019-06-08 20:07 UTC (History)
48 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2014-10-30 12:59:34 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:1744 normal SHIPPED_LIVE Moderate: v8314-v8 security update 2014-10-30 16:08:15 UTC

Description T.C. Hollingsworth 2014-07-31 23:45:09 UTC
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

Comment 1 T.C. Hollingsworth 2014-08-01 01:48:10 UTC
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

Comment 2 Murray McAllister 2014-08-04 03:32:33 UTC
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)

Comment 3 Tomas Hoger 2014-08-04 12:31:53 UTC
Upstream blog post:
http://blog.nodejs.org/2014/07/31/v8-memory-corruption-stack-overflow/

Comment 4 Fedora Update System 2014-08-07 15:29:56 UTC
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.

Comment 5 Fedora Update System 2014-08-15 02:33:39 UTC
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.

Comment 6 Vincent Danen 2014-09-04 16:36:16 UTC
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.
"""

Comment 9 Fedora Update System 2014-09-24 03:43:23 UTC
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.

Comment 10 Garth Mollett 2014-10-08 04:49:17 UTC
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.

Comment 11 Martin Prpič 2014-10-22 07:58:33 UTC
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.

Comment 13 errata-xmlrpc 2014-10-30 12:09:28 UTC
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


Note You need to log in before you can comment on or make changes to this bug.