Remote Code Execution in CouchDB (and Privilege Escalation in the Npm Registry) | Hacker News Reader

Remote Code Execution in CouchDB (and Privilege Escalation in the Npm Registry)

justi.cz

68 pointsjusticz12 comments

Here's CouchDB's official announcement of the vulnerabilities:

https://blog.couchdb.org/2017/11/14/apache-couchdb-cve-2017-...

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

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).

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?

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

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...

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.

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.

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).

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.

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

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.

He links to a stack overflow question and I think this answer is pretty good https://stackoverflow.com/a/23195243/497116.

https://www.ietf.org/rfc/rfc4627.txt says "The names within an object SHOULD be unique". 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.

From 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."

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.

Reply on news.ycombinator.com