Bug Description

Two security issues, both resolved upstream. native helper security issue only impacts earlier versions of MongoDB - 2.4.x uses libv8 instead of spidermonkey and does not have this function.

QA:

Works out-of-the-box from packaging.
Package ships a test suite (smoke) which is executed on all target platforms.
Generally well maintained in Debian and in Ubuntu (server team).
Issue with OpenSSL license compatibility needs to be resolved (upstream working on this).

Dependencies: All in main aside from libv8, snowball and gyp

Maintenance:

Upstream push out minor point releases for bug fixes (MRE will be applied for).
Packaging generally in good shape aside from static linking of client binaries (being worked on in Debian).

libv8 is something we've considered in the past as part of our webkit work and Ubuntu SDK audits. We can't effectively support libv8 because it is constantly changing. Therefore, backporting patches becomes infeasible very quickly and we are faced with having to use a new upstream release-- which would likely break anything that depends on it. NAK on libv8 in the archive.

What we did for the Ubuntu SDK is allow an embedded version of libv8-- this is guaranteed to always match with its consumer, but for this to work it must be demonstrated that libv8 does not process untrusted javascript. If it doesn't, there is no attack surface for the embedded libv8 and therefore it doesn't have to be kept up to date. If it does processed untrusted javascript, NAK.

On 28/06/13 12:32, Jamie Strandboge wrote:
> libv8 is something we've considered in the past as part of our webkit
> work and Ubuntu SDK audits. We can't effectively support libv8 because
> it is constantly changing. Therefore, backporting patches becomes
> infeasible very quickly and we are faced with having to use a new
> upstream release-- which would likely break anything that depends on it.
> NAK on libv8 in the archive.

OK - sounds entirely reasonable and this was something I was concerned
about.

> What we did for the Ubuntu SDK is allow an embedded version of libv8--
> this is guaranteed to always match with its consumer, but for this to
> work it must be demonstrated that libv8 does not process untrusted
> javascript. If it doesn't, there is no attack surface for the embedded
> libv8 and therefore it doesn't have to be kept up to date. If it does
> processed untrusted javascript, NAK.

mongodb ships an embedded version of libv8 within the upstream tarball;
we can switch back to using this so that we avoid libv8 being a
standalone library.

Re: it must be demonstrated that libv8 does not process untrusted javascript

libv8 is used to provide the scriptable shell in mongodb; access to the
shell is via the mongo client application. By default, authentication
is turned off in the packaging - so its possible to access the db and
setup authentication - seehttp://docs.mongodb.org/manual/tutorial/enable-authentication/. That
said the default bind ip is 127.0.0.1 so only users with access to the
system running mongod have unauthenticated access to the database -
allowing a configuration to be bootstrapped securely.

Hopefully that clarifies use of v8 sufficiently to support embedded
inclusion in mongodb.

"Re: it must be demonstrated that libv8 does not process untrusted javascript

libv8 is used to provide the scriptable shell in mongodb; access to the
shell is via the mongo client application."

We allowed V8 to be embedded in the Ubuntu SDK because the attack surface was greatly reduced-- it won't process arbitrary QML-- it will process code from the developer. There are some corner cases with string processing where we need to keep an eye on V8 CVEs, but on the whole, V8 in the Ubuntu SDK can largely be ignored.

For mongodb you described a different situation. The mongo client application provides a scriptable shell. We fixed all kinds of vulnerabilities for an authenticated attacker in other software. Even if we said we need to enforce authentication and decided we wouldn't fix V8 bugs for an authenticated attacker, we would still have to fix them for the now non-default configurations that don't use authentication and/or connections through the loopback (loopback isn't strong protection anyway-- if there were a vulnerability in another piece of software on the system, a remote attacker could attack it and then attack mongo via the loopback)
I think this provides an attack surface such that we would have to support V8 with security updates.

I think this provides an attack surface such that we would have to support V8 with security updates. This very likely means full version upgrades for mongodb to support new versions of V8 because V8 may change so much (assuming that upstream mongodb stays on top of V8 security issues in the first place).

Upstream mongodb have definitely backported some fixes to their embedded 10gen version; however I will need to get a more definitive response on how 10gen manage security issues in dependencies such as this.

FWIW I was intending on applying for a MRE for MongoDB assuming successful MIR.