
Remote Code Execution in CouchDB (and Privilege Escalation in the Npm Registry) - justicz
https://justi.cz/security/2017/11/14/couchdb-rce-npm.html
======
justicz
Here's CouchDB's official announcement of the vulnerabilities:

[https://blog.couchdb.org/2017/11/14/apache-couchdb-
cve-2017-...](https://blog.couchdb.org/2017/11/14/apache-couchdb-
cve-2017-12635-and-cve-2017-12636/)

I really appreciated the quick response of the CouchDB team and how they
handled rolling out the patch.

------
filmor
jsx (the pure Erlang JSON library) behaves the same way. In jsx at least,
passing the return_maps option will return

    
    
        > jsx:decode(<<"{\"foo\":\"bar\", \"foo\":\"baz\"}">>, [return_maps]).
    
        #{<<"foo">> => <<"baz">>}
    

The actual problem seems to me the difference in the model (list of items,
which "works" for duplicate keys, vs. maps).

------
perpetualcrayon
Given the ubiquity of JSON on the web, can anyone here think of any other
common JSON parsers for modern web languages that behave in these unexpected
ways?

~~~
mike_hearn
They are all in disagreement over various edge cases. JSON is just a very
weakly specified thing:

[http://seriot.ch/parsing_json.php](http://seriot.ch/parsing_json.php)

It's not just JSON by the way. URL parsers also differ in how they handle
malformed inputs, with potentially catastrophic results:

[https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-
Ne...](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-
SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf)

Basically the entire web stack is made up of protocols that are weakly
specified, open to interpretation, lacking reference implementations and are
therefore very hack prone.

------
btown
It doesn’t seem like disclosure was coordinated with NPM itself - which
usually wouldn’t be a problem as it’s the software user’s responsibility to
follow patches and stay up to date. But in this case it seems funny that NPM
wasn’t considered a principal party for responsible disclosure given the
entire context of the investigation.

~~~
justicz
I didn't mention it in the post, but npm was patched up before the update was
publicly released. The CouchDB team coordinated with some of the bigger
customers in advance (I also specifically requested that they do this in my
original bug report).

~~~
js4all
We are using many CouchDB servers and I can confirm that we got a heads-up
plus a patch several days before the 1.7.0 release. The CouchDB team and the
Hoodie team did a great job handling this issue.

------
Buttes
This would be solved by configuring jiffy to use maps instead of proplists.

------
nolok
I would like to comment that "there is a discrepancy between the Javascript
JSON parser (used in validation scripts) and the one used internally by
CouchDB [...] For a given key, the Erlang parser will store both values, but
the Javascript parser will only store the last one" should probably read "the
Erland parser is wrong".

I'm not saying what javascript does is smart, or the right way, or anything
like that, but JSON is defined specifically as "a subset of Javascript", as
such I find it normal to expect that javascript rules applies.

Of course, one could argue that a key being defined twice is undefined
behavior (is it ? I admit to not reading the javascript specs) and thus "what
the js implementations actually do" isn't a reference.

~~~
Zalastax
He links to a stack overflow question and I think this answer is pretty good
[https://stackoverflow.com/a/23195243/497116](https://stackoverflow.com/a/23195243/497116).

[https://www.ietf.org/rfc/rfc4627.txt](https://www.ietf.org/rfc/rfc4627.txt)
says "The names within an object SHOULD be unique".
[https://tools.ietf.org/html/rfc7159](https://tools.ietf.org/html/rfc7159) is
more lax and instead says "An object whose names are all unique is
interoperable in the sense that all software implementations receiving that
object will agree on the name-value mappings". It's unfortunate that the
correct behavior is not agreed on and today we saw the consequences of that.

~~~
sratner
From [https://www.ecma-
international.org/ecma-262/5.1/#sec-15.12](https://www.ecma-
international.org/ecma-262/5.1/#sec-15.12) \-- "NOTE: In the case where there
are duplicate name Strings within an object, lexically preceding values for
the same key shall be overwritten."

~~~
Zalastax
Yes, a good point! For interoperability it would be best if everyone followed
the ECMA standard for JSON from 2011. It seems like they forgot to even
mention duplicate keys in ECMA-404 from 2013 which seems very strange. RFC7159
uses the word SHOULD but I don't think the JSON parser Jiffy has actually
understood the full implications and carefully weighed before choosing to
allow duplicate elements.

