nodejs August 2014

nodejs@lists.fedoraproject.org

3 participants
3 discussions

Planning for Node.js 0.12.x
by Stephen Gallagher 18 Aug '14

18 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was talking with Igor Gnatenko today about libuv 0.11.x. He has a package (neovim) that requires the newer libuv to operate. I explained to him that updating libuv to 0.11.x in Fedora would necessitate the chain-reaction of updating Node.js, npm and many if not most of the packages that depend on it. Igor suggested that we could start doing this in Rawhide now, post-branch. I'm a little bit wary of doing this directly in Rawhide, primarily because Joyent has provided no clear target date for the stable release of 0.12.x (and I'm concerned that if it's not ready in time for Fedora 22 Alpha, we might have a problem). Igor and I have contacted Joyent to ask them if they can put a ballpark date on the release. In the meantime, I'm going to start putting together a COPR repository[1] containing the unstable bits. I think it's probably a good idea for us to at least start exploring what set of packages will work with the new Node.js and which ones are going to break. I'm definitely the wrong person to do most of this, so I'd like to ask any subscriber on this list who is interested in helping to respond with their FAS ID so I can add them to the permission list on the COPR. Then they can start performing builds in the COPR. I will hopefully start with libuv and Node.js 0.11.x this afternoon or tomorrow morning. [1] http://copr.fedoraproject.org/coprs/sgallagh/nodejs-0.12/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO9orQACgkQeiVVYja6o6MAZgCdHjdz6tAAcRDt267IyfhvhDQd WdwAnirQdcA4ZFpHzaiHp+sQ+GHFQ0ar =wr4t -----END PGP SIGNATURE-----

2 2

lodash-node
by Tom Hughes 15 Aug '14

15 Aug '14

I have an existing package that has a new version with a dependency on lodash-node so I was trying to package it but ran into the question of exactly what it is and how to deal with it... We have lodash packaged already and as bast I can figure out lodash-node is the result of using lodash-cli to build node modules from lodash. Though I'm not sure what that means when lodash is already a node module?!? In any case does that mean I should package lodash-cli first and then make the lodash-node package do that build step? Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

3 9

V8 Memory Corruption and Stack Overflow security vulnerability
by T.C. Hollingsworth 01 Aug '14

01 Aug '14

Node.js upstream announced a security release this afternoon. See the forwarded message below for details. 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 All users of Node.js on Fedora should upgrade to one of the above packages as soon as possible. nodejs-0.10.30 and libuv-0.10.28 updates are forthcoming that will contain only the bugfixes from the upstream release. -T.C. ---------- Forwarded message ---------- From: Timothy J Fontaine <tjfontaine(a)gmail.com> Date: Thu, Jul 31, 2014 at 11:59 AM Subject: [nodejs] Node.js Security Release of v0.10.30 and v0.8.28 (V8 Memory Corruption and Stack Overflow) To: "nodejs(a)googlegroups.com" <nodejs(a)googlegroups.com>, nodejs-sec(a)googlegroups.com 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/530af9cb8e700e7596b3ec812bad123c9fa06… 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` -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscribe(a)googlegroups.com. To post to this group, send email to nodejs(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAFkHtM46voS3nPY5%2BR6p9gavcxQD%2B…. For more options, visit https://groups.google.com/d/optout.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs August 2014