A buffer overflow flaw was found in the V8 component of the Chromium browser. Upstream bug(s): https://code.google.com/p/chromium/issues/detail?id=606115 External References: http://googlechromereleases.blogspot.com/2016/05/stable-channel-update.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Supplementary Via RHSA-2016:1080 https://rhn.redhat.com/errata/RHSA-2016-1080.html
Created v8 tracking bugs for this issue: Affects: fedora-all [bug 1353620] Affects: epel-all [bug 1353623]
Created nodejs tracking bugs for this issue: Affects: fedora-all [bug 1353619] Affects: epel-all [bug 1353622]
Nodejs advisory: https://nodejs.org/en/blog/vulnerability/june-2016-security-releases/
V8 upstream commit and review request: https://chromium.googlesource.com/v8/v8/+/3a9bfecfe41737aaf0dbf92ce68352f8acaaaf73%5E%21/#F0 https://codereview.chromium.org/1930873002 Node.js backport of the fix to the embedded V8: https://github.com/nodejs/node/commit/fcb9145e291e8cb82164bc1fe3db1c1dae219b55 Fixed in Node.js versions 0.10.46, 0.12.15, 4.4.6, 5.12.2 and 6.2.0.
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS Via RHSA-2017:0002 https://rhn.redhat.com/errata/RHSA-2017-0002.html
It is my belief that OSP 7-10 are not affected: 1) We ship v8 v8-3.14.5.10-18.el7ost, which is much older than v5.1.128 2) There is no Zone::New() method specifically defined in v3.14.15.10 3) The Zone::NewExpand() method takes an int as size_t (ok, whatever), and calls directly to malloc(). Here's the entire function from 3.14.5.10: // Creates a new segment, sets it size, and pushes it to the front // of the segment chain. Returns the new segment. Segment* Zone::NewSegment(int size) { Segment* result = reinterpret_cast<Segment*>(Malloced::New(size)); adjust_segment_bytes_allocated(size); if (result != NULL) { result->Initialize(segment_head_, size); segment_head_ = result; } return result; } Here's what Malloced::New(size) does (from allocation.cc): void* Malloced::New(size_t size) { void* result = malloc(size); ... 5) In later versions of v8, they tried to be efficient with calls to glibc malloc/free and got things wrong, exposing the issue: // Compute the new segment size. We use a 'high water mark' // strategy, where we increase the segment size every time we expand // except that we employ a maximum segment size when we delete. This // is to avoid excessive malloc() and free() overhead. These later versions of v8 are not shipped in RHEL OSP 7-10, so I don't think this product is affected. Please correct me if I'm wrong.
That is, the overflow in NewExpand() would be because we tried to expand past the bounds of the previously-allocated block on v5. In v3.14.5.10, we always call malloc(), so this issue doesn't occur. Since there's no Zone::New() in v3.14.5.10, this function also can't be affected.
Whoops, wrong function :)
So, ignore point (3) (wrong function) and (5) (NewExpand does try to preserve some memory). Points (1) and (2) are still valid. There is no Zone::New() in v8 3.14.5.10 The patch that is added to NewExpand() adds a DCHECK() line which does not do anything on production builds (only debug builds).
Nope, theory disproved: [root@localhost ~]# d8 V8 version 3.14.5.10 [console: readline] d8> var r2 = new RegExp("(?=)*", "g"); d8> var s0 = s0 = Array(220000700).join('a'); d8> result = s0.match(r2) [ 301.477942] d8[2486]: segfault at 7f3f71ad7000 ip 00007f3f7f4f3ceb sp 00007ffecb537d98 error 7 in libc-2.17.so[7f3f7f465000+1b6000] Segmentation fault (core dumped)
The backtrace is completely different, but it's still falling apart. OK, we'll fix it.
Created attachment 1263179 [details] 314 patch
Created attachment 1263290 [details] Patch for old v8 v3.14.5.10
This issue has been addressed in the following products: Red Hat OpenStack Platform 10.0 (Newton) Via RHSA-2017:0882 https://access.redhat.com/errata/RHSA-2017:0882
This issue has been addressed in the following products: Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL 7 Via RHSA-2017:0881 https://access.redhat.com/errata/RHSA-2017:0881
This issue has been addressed in the following products: Red Hat OpenStack Platform 8.0 (Liberty) Via RHSA-2017:0879 https://access.redhat.com/errata/RHSA-2017:0879
This issue has been addressed in the following products: Red Hat OpenStack Platform 9.0 (Mitaka) Via RHSA-2017:0880 https://access.redhat.com/errata/RHSA-2017:0880
Created nodejs tracking bugs for this issue: Affects: openshift-1 [bug 1470299]
This issue has been addressed in the following products: Red Hat Satellite 6.3 for RHEL 7 Via RHSA-2018:0336 https://access.redhat.com/errata/RHSA-2018:0336
Openshift Enterprise 3.7 is using RHSCL latest image which includes Node 4.6.2. See: https://github.com/openshift/library/blob/master/official/nodejs/imagestreams/nodejs-rhel7.json Openshift also includes the v8 engine embedded in MongoDB. However it's not possible to exploit this issue via the mongodb shell because the execute the 'eval' function: sh-4.2$ mongo -u admin -p $MONGODB_ADMIN_PASSWORD admin MongoDB shell version: 2.6.9 connecting to: admin ... > function bar() { ... var r2 = new RegExp("(?=)*", "g"); ... var s0 = Array(220000700).join('a'); ... result = s0.match(r2) ... } > > db.eval(bar,'') 2018-04-03T02:08:29.557+0000 { "ok" : 0, "errmsg" : "not authorized on admin to execute command { $eval: function bar() {\n var r2 = new RegExp(\"(?=)*\", \"g\");\n var s0 = Array..., args: [ \"\" ] }", "code" : 13 } at src/mongo/shell/db.js:403 The v8 engine has been removed from MongoDB 3.1 onwards, see: https://jira.mongodb.org/browse/SERVER-19376 Marking Openshift Enteprise 3 as not affected and closing the linked tracking bugs.