6 ms·

MongoDB remote command execution vulnerability: nightmare or eye opener?

70 points by ehsanf 14y ago

shin_lao 14y ago
Doesn't the MongoDB daemon run in a privilege-free sandboxed environment?
- mrkurt 14y ago
  Depends who's running it. :)
  - yet 14y ago
    Exactly - and in 90% of the cases MongoDB is run by the company idiot
- ehsanf 14y ago
  MongoDB manual has some good recommendations on operations here: http://docs.mongodb.org/manual/administration/security/#operations http://docs.mongodb.org/manual/administration/security/#oper... It certainly helps limit the damage. However, unless it is chroot-ed, it will still pose a very serious risk. And even with chroot, the damage is not totally eliminated. The attacker can start leveraging local vulnerabilities.
wheaties 14y ago
As a developer that uses MongoDB in production I am shocked! Shocked, I tell you.
- yet 14y ago
  And why are you shocked? Because you don't know what you are doing?
  - tjtrapp 14y ago
    Totally unnecessary comment. I would down vote you if I could.
nickporter 14y ago
I guess this is only a real problem if you're exposing your MongoDB instance to the internet.
- rambot 14y ago
  I suspect a lot of people are using MongoDB as the database backend to their web applications or services, so they are probably being indirectly exposed to the Internet. (Just like your Postgres or MySQL database.)
  - just2n 14y ago
    I've never exposed a Postgres or MySQL database directly to the internet, either. They're always listening to localhost connections only, and the only code that gets to make direct calls into them is my code, which means input sanitization prevents attacks like this. The same goes for my use of MongoDB. Though I am curious if anything similar exists for CouchDB, as they seem to be encouraging dangerous configurations like that.
    - rambot 14y ago
      Same. I was trying to suggest the attack vector most people would encounter is the web application MongoDB is servicing.
  - deleted 14y ago
    [deleted]
- achillean 14y ago
  By default, I believe MongoDB listens on 0.0.0.0 which means that servers unprotected from a firewall will expose their MongoDB database to the Internet. Shodan confirms that there are at least 31,000 public instances of MongoDB on the Internet at the moment (source: http://www.shodanhq.com/search?q=port%3A28017 http://www.shodanhq.com/search?q=port%3A28017).
  - ehsanf 14y ago
optymizer 14y ago
This relies on javascript to be passed to $where. There is no excuse for not sanitizing your inputs.
- ajross 14y ago
  The same thing could be said of SQL injection attacks, yet...
  - optymizer 14y ago
    ... no one is pointing fingers at MySQL, like they are at MongoDB, as if this is some kind of security flaw in MongoDB. It's a feature, not a bug. The docs make it clear that $where can run JavaScript, so if you know what you're doing, you're not going to allow JavaScript to flow through your software as if it's valid input.
sehrope 14y ago
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 really 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. Most DBs allow something similar to this though it's generally locked down by default. For PostgreSQL you can do it via untrusted languages though by default only super users can use those: http://www.postgresql.org/docs/9.1/static/plperl-trusted.html http://www.postgresql.org/docs/9.1/static/plperl-trusted.htm... For Oracle here's a bunch of ways to accomplish the same thing though again, by default, all are blocked for non-DBA users: http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:16212348050 http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTI... 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 => 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.
cheald 14y ago
This seems like Seriously Bad News for folks like MongoHQ. I'm hoping they're running 2.4.1, though?
- mrkurt 14y ago
  It's less of a problem than you'd expect, most of our DBs run in isolated processes and an authenticated user (even with shell) can't really break out and run wild on the environment. We expected that the Mongo javascript engine would have vulnerabilities like this and started trying to get ahead of them about 18 months ago. About 3% of our servers are either legacy, and the isolation hasn't been tested all that well, or sandbox environments where people share a process for tiny/test DBs. We've upgraded all of those to 2.4.1.
  - cheald 14y ago
    That's great to hear. Big respect to you guys for solving that problem before it was a problem!
abentspoon 14y ago
Thanks to $elemMatch and automatic parameter parsing, this vulnerability is easier to exploit than it would seem. In rails, both of these are usually considered safe: MysqlCollection.create(:name => params[:name]) MysqlCollection.where(:name => params[:name]).all MongoCollection.create(:name => params[:name]) MongoCollection.where(:name => params[:name]).all However, the mongo version is vulnerable to this exploit. /create?name[0][whatever]=anything /get?name[$elemMatch][$where]=exploitcode
- cheald 14y ago
  Per usual, even if you're using something that isn't Mongo, it's good practice to explicitly cast your untrusted params before passing them to a query. MongoCollection.where(:name => params[:name].to_s) That'll result in the literal: db.collection.where({name: "{\"$elemMatch\"=>{\"$where\"=>\"exploit\"}}"}) rather than the more exploity: db.collection.where({name: {$elemMatch:{$where: "exploit"}}}) Failing to cast params to strings can result in "injection" attacks in Mongo, even outside of the context of this bug. For example: User.where(:id => params[:id]) You could pass id[$gt]=0, resulting in: User.where(:id => {:$gt => 0}) which would match all records in the database. For completeness' sake, here's a similar exploit vector in ActiveRecord: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/t1WFuuQyavI https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

70 points by ehsanf 14y ago

shin_lao 14y ago

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

mrkurt 14y ago
Depends who's running it. :)
- yet 14y ago
  Exactly - and in 90% of the cases MongoDB is run by the company idiot
ehsanf 14y ago
MongoDB manual has some good recommendations on operations here: http://docs.mongodb.org/manual/administration/security/#operations http://docs.mongodb.org/manual/administration/security/#oper... It certainly helps limit the damage. However, unless it is chroot-ed, it will still pose a very serious risk. And even with chroot, the damage is not totally eliminated. The attacker can start leveraging local vulnerabilities.

wheaties 14y ago

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

yet 14y ago
And why are you shocked? Because you don't know what you are doing?
- tjtrapp 14y ago
  Totally unnecessary comment. I would down vote you if I could.

nickporter 14y ago

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

rambot 14y ago
I suspect a lot of people are using MongoDB as the database backend to their web applications or services, so they are probably being indirectly exposed to the Internet. (Just like your Postgres or MySQL database.)
- just2n 14y ago
  I've never exposed a Postgres or MySQL database directly to the internet, either. They're always listening to localhost connections only, and the only code that gets to make direct calls into them is my code, which means input sanitization prevents attacks like this. The same goes for my use of MongoDB. Though I am curious if anything similar exists for CouchDB, as they seem to be encouraging dangerous configurations like that.
  - rambot 14y ago
    Same. I was trying to suggest the attack vector most people would encounter is the web application MongoDB is servicing.
- deleted 14y ago
  [deleted]
achillean 14y ago
By default, I believe MongoDB listens on 0.0.0.0 which means that servers unprotected from a firewall will expose their MongoDB database to the Internet. Shodan confirms that there are at least 31,000 public instances of MongoDB on the Internet at the moment (source: http://www.shodanhq.com/search?q=port%3A28017 http://www.shodanhq.com/search?q=port%3A28017).
- ehsanf 14y ago

optymizer 14y ago

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

ajross 14y ago
The same thing could be said of SQL injection attacks, yet...
- optymizer 14y ago
  ... no one is pointing fingers at MySQL, like they are at MongoDB, as if this is some kind of security flaw in MongoDB. It's a feature, not a bug. The docs make it clear that $where can run JavaScript, so if you know what you're doing, you're not going to allow JavaScript to flow through your software as if it's valid input.

sehrope 14y ago

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 really 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. Most DBs allow something similar to this though it's generally locked down by default. For PostgreSQL you can do it via untrusted languages though by default only super users can use those: http://www.postgresql.org/docs/9.1/static/plperl-trusted.html http://www.postgresql.org/docs/9.1/static/plperl-trusted.htm... For Oracle here's a bunch of ways to accomplish the same thing though again, by default, all are blocked for non-DBA users: http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:16212348050 http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTI... 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 => 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.

cheald 14y ago

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

mrkurt 14y ago
It's less of a problem than you'd expect, most of our DBs run in isolated processes and an authenticated user (even with shell) can't really break out and run wild on the environment. We expected that the Mongo javascript engine would have vulnerabilities like this and started trying to get ahead of them about 18 months ago. About 3% of our servers are either legacy, and the isolation hasn't been tested all that well, or sandbox environments where people share a process for tiny/test DBs. We've upgraded all of those to 2.4.1.
- cheald 14y ago
  That's great to hear. Big respect to you guys for solving that problem before it was a problem!

abentspoon 14y ago

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

cheald 14y ago
Per usual, even if you're using something that isn't Mongo, it's good practice to explicitly cast your untrusted params before passing them to a query. MongoCollection.where(:name => params[:name].to_s) That'll result in the literal: db.collection.where({name: "{\"$elemMatch\"=>{\"$where\"=>\"exploit\"}}"}) rather than the more exploity: db.collection.where({name: {$elemMatch:{$where: "exploit"}}}) Failing to cast params to strings can result in "injection" attacks in Mongo, even outside of the context of this bug. For example: User.where(:id => params[:id]) You could pass id[$gt]=0, resulting in: User.where(:id => {:$gt => 0}) which would match all records in the database. For completeness' sake, here's a similar exploit vector in ActiveRecord: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/t1WFuuQyavI https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...