Support for modern Spidermonkey versions?

[ghost]

Spidermonkey 1.8.5, currently recommended by the CouchDB 2.1.1 documentation, was released in March of 2011 along with Firefox 4. At the time of this writing, the engine appears to be slightly more than seven years old. I just have a couple quick informational questions if you have a moment:

1. Is there any supported way to build CouchDB using a modern version of SpiderMonkey, or any plans to support this in the near future? Failing that, is there a supported method of relying on Node and/or V8 instead of Spidermonkey 1.8.5?

2. Has the CouchDB team checked Spidermonkey 1.8.5 against the MITRE CVE repository for vulnerabilities? If so, have any security fixes been backported?

Thanks in advance. If I'm missing a piece of documentation or a detail, apologies; I tried to scour pretty hard before opening a ticket.

[wohali]

Hi @browndav ,

1. Sadly, there is no way to build CouchDB's couchjs binary against any newer version of SpiderMonkey. There are a number of reasons, but the most compelling is that the current specification of a design document map / reduce function as a bare function () {...} is no longer syntactically valid any modern JavaScript engine.

To move to a newer version, we must either deprecate the current design document syntax, or auto-transform/auto-wrap JS functions within it. The problem with the latter approach is that a small percentage of users have stuck other stuff ahead of the function declaration in their map / reduce / etc. functions, such as variable declarations or library imports, that would break with a simple auto-rewrite wrapper.

With the very next release of CouchDB binaries, Apache CouchDB will be supplying pre-built SM1.8.5 binaries via our own open build chain. This is to ensure that the most popular platforms (Debian, Ubuntu, CentOS, RedHat, Windows, docker) have the library built with the right options. This is motivated by recent distributions dropping support for SM1.8.5, or changing build-time options such that instability is introduced.

There was an experimental Node-based replacement for the SM 1.8.5 view server in 1.x, but the "extreme sandboxing" we accomplish with Spidermonkey is not there, meaning that the Node-based viewserver is a gaping security hole, and violates the view server specification (no side effects are allowed!) As such we can't recommend you use it anywhere. The effort is abandoned.

The current plan forward is two-fold.

First, the team is working as hard as possible on improving mango, the in-built declarative solution, to provide coverage of as many boilerplate secondary indexes as possible. Foremost, Mango is inherently faster than any external query server can ever be. This reduces the need for JavaScript overall. Users can also add the dreyfus / clouseau add-on from Cloudant to enable Lucene-powered full-text search as another kind of secondary index.

Second, we've had (thanks to @dmunch) initial good experiences with the Microsoft ChakraCore engine. Unlike V8/Node, ChakraCore is lightweight, small, and intended to be embedded in other systems directly. Microsoft's own Cosmos DB (formerly Document DB) was inspired by Apache CouchDB, and uses ChakraCore extensively as its JS engine, as does the new Edge browser.

@dmunch's experimental ChakraCore-based query server already solves both the sandboxing and the anonymous function concerns, and has a number of other exciting features as well. It is also compatibly licensed (ALv2.0) as is ChakraCore itself (MIT).

Such a major change - swapping out SM1.8.5 - that induces any sort of backwards incompatibility can't occur until a major version release, so the earliest I'd expect to see anything like this in CouchDB would be the 3.0 release. If we can solve the remaining TODOs for the couch-chakra solution, we could drop it in sooner (maybe 2.3.0). We'd welcome any help you might be able to give us on this!

2. Yes, we keep tabs on the MITRE CVEs for vulnerabilities. We also welcome any security reports at our (security email address)[[email protected]]. Because of the aforementioned sandboxing, and the fact that couchjs wraps SM1.8.5 in a very constrained environment, the very large proportion of exploits possible with a JS engine are effectively mitigated.

For bookkeeping, I'm going to close this ticket out and open forward-looking tickets that make more sense for our plans, but I'm happy to continue this discussion here or in those tickets.

Can I ask - other than being successful deploying SM1.8.5 easily, are there any other concerns you or your team have? For instance, are you writing complex JS views that require newer ECMAScript functionality? Or are you trying to achieve something else with a view?

[ghost]

The concern that first sent me down this path was CVE-2014-1513, which IIRC was full RCE demonstrated at pwn2own in 2014. It wasn't clear to me how javascript sandboxing would mitigate a heap overflow, and I wasn't able to easily find any relevant mitigations or backported patches in the source .deb packages for libmozjs185. I may be missing something.

[wohali]

That particular exploit doesn't go as far back as 1.8.5; the affected file (TypedArrayObject.cpp) is newer than 1.8.5.

See https://bugzilla.mozilla.org/show_bug.cgi?id=982974 and:

$ tar xfz js185-1.0.0.tar.gz
$ cd js-1.8.5/
$ find . -name TypedArrayObject.cpp
$

[ghost]

Thanks, I missed that; that's super-helpful. Do you know off the top of your head if CVE-2013-5619 is in the same situation?

[wohali]

Specifically the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=917841 refers only to files that aren't in SM 1.8.5, but the general principle might apply.

The CVE is labelled medium priority. No known exploits were out there - this was a preventative change. I wouldn't consider this critical enough for our use of the library to patch.

[marcosbc]

It seems like this was fixed here: #1875 / #2345