MongoDB remote command execution vulnerability: nightmare or eye opener?

Having your DB server (regardless of type) exposed to the entire internet is a bad idea but that's not the real problem here (it just makes this <i>really</i> scary for people running wide open MongoDB instances). This is a lack of validation of client inputs by the server itself and (in my opinion) a dangerous default choice of trusting your client.<p>Most DBs allow something similar to this though it's generally locked down by default.<p>For PostgreSQL you can do it via untrusted languages though by default only super users can use those: <a href="http://www.postgresql.org/docs/9.1/static/plperl-trusted.html" rel="nofollow">http://www.postgresql.org/docs/9.1/static/plperl-trusted.htm...</a><p>For Oracle here's a bunch of ways to accomplish the same thing though again, by default, all are blocked for non-DBA users: <a href="http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:16212348050" rel="nofollow">http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTI...</a><p>Note that there are some times when it's useful to be able to execute misc things like this. About 6 or 7 years back I wrote something on Oracle that would execute shell commands to get iostat/vmstat output and save it on regular intervals. Could have been done from outside in (data gets pushed from unix =&#62; DB) but having it initiated by the DB itself let us control when it runs based on DB actions (triggers, DBMS_JOBs, etc). To get that setup though we had to whitelist the executables we were calling as by default on Oracle everything is blocked. It's not a common thing to do and I think it's sensible that things like that should be locked down by default.

This relies on javascript to be passed to $where. There is no excuse for not sanitizing your inputs.

Thanks to $elemMatch and automatic parameter parsing, this vulnerability is easier to exploit than it would seem.<p>In rails, both of these are usually considered safe:<p><pre><code> MysqlCollection.create(:name =&#62; params[:name]) MysqlCollection.where(:name =&#62; params[:name]).all MongoCollection.create(:name =&#62; params[:name]) MongoCollection.where(:name =&#62; params[:name]).all </code></pre> However, the mongo version is vulnerable to this exploit.<p><pre><code> /create?name[0][whatever]=anything /get?name[$elemMatch][$where]=exploitcode</code></pre>

As a developer that uses MongoDB in production I am shocked! Shocked, I tell you.

I guess this is only a real problem if you're exposing your MongoDB instance to the internet.

This seems like Seriously Bad News for folks like MongoHQ. I'm hoping they're running 2.4.1, though?

Doesn't the MongoDB daemon run in a privilege-free sandboxed environment?