Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB remote command execution vulnerability: nightmare or eye opener?

blog.sdelements.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: MongoDB remote command execution vulnerability: nightmare or eye opener?

#21

Post by mrkurt »

cheald wrote: post #18

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

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.

Re: MongoDB remote command execution vulnerability: nightmare or eye opener?

#22

Post by cheald »

mrkurt wrote: post #21
cheald wrote: post #18

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

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…

That's great to hear. Big respect to you guys for solving that problem before it was a problem!

Re: MongoDB remote command execution vulnerability: nightmare or eye opener?

#23

Post by abentspoon »

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

Re: MongoDB remote command execution vulnerability: nightmare or eye opener?

#24

Post by cheald »

abentspoon wrote: post #23

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

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

Re: MongoDB remote command execution vulnerability: nightmare or eye opener?

#25

Post by sandstrom »

achillean wrote: post #13
nickporter wrote: post #6

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

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

I remember highlighting this problem >3 years ago

https://jira.mongodb.org/browse/SERVER-207

(though it seems that it wasn't fixed when this issue was closed, so probably later https://jira.mongodb.org/browse/SERVER-697)

Re: MongoDB remote command execution vulnerability: nightmare or eye opener?

#27

Post by optymizer »

ajross wrote: post #26
optymizer wrote: post #7

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

The same thing could be said of SQL injection attacks, yet...

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

Re: MongoDB remote command execution vulnerability: nightmare or eye opener?

#28

Post by tedchs »

nickporter wrote: post #6

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

IMHO, Mongo listening on 0.0.0.0 (i.e. all interfaces) is a reasonable default. Most production deployments are going to run Mongo on a separate box from the app server, particularly if a replica set is used. This normally does not lead to Internet exposure because folks have IPTables, EC2 Security Group rules, or other firewall filtering that only allows desired traffic.
Post reply on HN