Exploit published that allows remote execution

[Santiago Ezcurra]

Hi there:

 

what can you tell about this exploit recently published:

 

http://blog.scrt.ch/2013/03/24/mongodb-0-day-ssji-to-rce/

 

Is this resolved in latest version ?

 

Regards,

 

Santiago

[Mark Hillick]

Hi Santiago,

The blog post by the security researcher suggests remote code execution, however, it's not a remote code execution exploit since you can't execute arbitrary JS remotely. 

As you will see from SERVER-9124, a fix has been committed to the 2.0, 2.2 and 2.4 code (2.0.9, 2.2.4 and 2.4.2).

2.4.0/2.4.1 is not susceptible to the POC code published by the researcher as his code is specific to the SpiderMonkey JS engine.

As a FYI, this vulnerability has been given a public CVE number - CVE-2013-1892. Our alerts page has been updated with a some information on this issue - http://www.mongodb.org/about/alerts/.

Any further questions, please let me know.

Thanks 

Mark

[Christian Csar]

I may just be reading that blog post incorrectly, but are you sure that isn't RCE? If Eve has access to a MongoDB database on a different server, ie she is using a shared mongodb hosting service, then she can legitimately submit queries to the server. The example exploit uses "db.my_collection.find(" to submit the exploit code. Is there a reason Eve can't make use of this remotely to execute code in the Mongo process she wouldn't otherwise have privileges to execute? CVE-2013-1892 is new enough that it doesn't seem to be on the NIST tracker.

Christian

[Mark Hillick]

Hi Christian,

At present, I do not believe that the example exploit code performs true arbitrary code execution. In my testing so far, when I send the query (to a MongoDB instance) I've been unable to execute subsequent commands as the POC code always causes the mongod instance to die, i.e. a DOS effectively. Please note that this is clearly not good either and I am not downplaying it but I have been unable to achieve code execution with it. From looking at the blog post and (other links pointing to) the work of the security researcher, I do not see that he has been able to "pop" a shell. Please correct me if I'm wrong.

Have you been able to do execute code after sending the query to a MongoDB instance? If so, please let me know.

>> If Eve has access to a MongoDB database on a different server, ie she is using a shared mongodb hosting service, then she can legitimately submit queries to the server. The example exploit uses "db.my_collection.find(" to submit the exploit code.

I don't quite follow what you are suggesting here. Are you asking if Eve can exploit legitimate connectivity to one mongod instance with the exploit such that Eve can then execute code through another mongod process running on the same physical server? Again, in my testing, I have not been able to do this.

I'd like to reassure you that we take issues like this very seriously and we have a vulnerability notification process as outlined at http://docs.mongodb.org/manual/administration/security/#vulnerability-notification. The good news is the fix has been committed (to 2.0, 2.2 and 2.4) as per my previous update.

If anything is unclear or you feel I'm mistaken, please let me know.

Thanks

Mark

[Bryan Helmkamp]

Hello,

Just wanted to chime in on this... at present, it's very unclear what a MongoDB 2.2 user should do. There are reports in the wild of RCE, and as far as I can tell no fixed release.

The fact that that individuals at 10gen have not been able to perform the RCE does not inspire enough confidence. There's "blood in the water", and so I think we have to assume it's vulnerable until the root cause is patched.

We are trying to evaluate whether we need to shutdown our MongoDB (and therefore whole system).

Can someone from 10gen please advise?

-Bryan

[Mark Hillick]

Hi Bryan,

Thanks for your question and I truly appreciate your concern on this issue. We take security issues like this very seriously and apologies if you feel our advice was inadequate.

>> There are reports in the wild of RCE, and as far as I can tell no fixed release.

I have previously communicated on this CVE a few times on this thread, have my answers been unclear? Here is another thread on the same topic - https://groups.google.com/forum/?fromgroups=#!searchin/mongodb-user/cve/mongodb-user/Rz938xpiAyg/7E4BDAdNUCoJ.

Our alerts page has been updated with  information on this issue - http://www.mongodb.org/about/alerts/.

Additionally, as you will see from SERVER-9124, a fix has been committed to the 2.0, 2.2 and 2.4 code (2.0.9, 2.2.4 and 2.4.2). 

2.2.4rc0 and 2.0.9rc0 have been released and this communication has bene published on this Google Group. Again please let me know if this is unclear.

At present, I do not believe this is RCE - as I previously said I have seen no evidence of successful code execution. The `mongod` service dies when the query is executed and yes, this is most definitely not good either. 

From current analysis, the query can only be delivered through direct connection to the mongod process, the POC is through a connection with the `mongo` shell. Therefore, if you run with authentication, only an authenticated user could run this query. If you have you `mongod` server segregated off through firewall rules or other network acls then the query can only be delivered from allowed devices.

>> There are reports in the wild of RCE

Can you provide evidence of this to secu...@10gen.com please? I have not seen a true RCE, the `mongod` process always dies - no further code is executable.

Can you please let me know if there are still concerns or if you require further information?

Thanks

Mark

[Christian Csar]

Mark,
    I may be missing something, but is there a security bulletin of some kind? My main complaint is mostly that outside of these posts the sum total of information available from 10gen appears to be

• "Unchecked access to SpiderMonkey’s JavaScript nativeHelper function. See SERVER-9124: fix available in 2.2.4, 2.4.2, and 2.0.9."
• and in that bug "Add a level of indirection to nativeHelper's function and argument pointers."

Now I've read the blog post detailing the vulnerability and can draw my own conclusions about the vulnerability, but the maintainers of MongoDB, ie 10gen, are in theory in the best position to analyze the vulnerability and tell us who it affects, who needs to care, and what if anything users should do. For example Debian's security bulletins typically end with the line "We recommend that you upgrade your [software name] packages." They include details on the type of vulnerability or problem being addressed. They also include the CVE number.

From the discussion in this thread I don't think my company needs to worry too much because the vulnerability appears to be an issue for connections authenticated to the database. This means we would be affected if there's an injection vulnerability in our application (which is of course perfect in every way imaginable). If we ran on shared mongodb hosting (which looks to be a relatively rare situation) I would be concerned about injection vulnerabilities in other applications and other users having access to our DB or being able to compromise the server that was hosting it.
You've said that the vulnerability definitely provides the ability for authenticated denial of service and have not seen evidence of authenticated remote code execution (ie privilege escalation). The blog post claims they have achieved full control of the stack and would be able to call mmap. Unless I'm much mistaken this means they claim to have achieved the steps necessary in order to execute code present on the system even if they did not provide sample code that does anything beyond crash mongod. Needless to say it's much easier to write code that crashes than code that does something useful, but the exploit not writing "hello world" to a file does not meant that it couldn't be exploited to do so. If there is a reason why this is authenticated DOS and not authenticated privilege escalation/remote RCE I would appreciate hearing it, so far the suggestions have not been confidence inspiring. Why does mongod die?

It's great that 2.2.4rc0 and 2.0.9rc0 have been released, should people be upgrading to them? "is out and ready for testing" suggests not. Again an 'actionable step' would have been nice. It might be 'upgrade to 2.2.4 and 2.0.9 when they are released.' On a related note, should we expect notices on the alerts page to get posted to the announce list this message has useful information in it about that nonsecurity issue.

Finally there's "This feature/vulnerability was reported 3 weeks ago to 10gen developers, no patch was commit but the default javascript engine was changed in last version so there is no more nativeHelper.apply function."  I don't know anything about the communication that happened or agixid's track record, and I understand that communicating with security researchers can be difficult especially when they have different expectations. But if 2.4 came out apparently containing a fix for the issue reported and he'd already held off three weeks, a message asking him to hold off for a few more weeks until you had fixes for all supported versions ready might have worked and let this process be smoother.

In short, I'm disappointed, but my own basic analysis is that this vulnerability is likely RCE but matters to one's application only if it either 1. uses a shared MongoDB instance or 2. has preexisting injection vulnerabilities (which now could potentially hurt the whole server vs just your data).

Christian

[tetlika]

Is that exploit applicable to a sharded cluster?

On 31 Бер, 06:04, Christian Csar <cac...@gmail.com> wrote:
> Mark,
>     I may be missing something, but is there a security bulletin of some
> kind? My main complaint is mostly that outside of these posts the sum total
> of information available from 10gen appears to be
>

>    - "Unchecked access to SpiderMonkey’s JavaScript nativeHelper function.
>    See SERVER-9124 <https://jira.mongodb.org/browse/SERVER-9124>: fix

>    available in 2.2.4, 2.4.2, and 2.0.9."

>    - and in that bug "Add a level of indirection to nativeHelper's function

> upgrading to them? "is out and ready for testing"<https://groups.google.com/forum/?fromgroups=#!topic/mongodb-announce/...>suggests not. Again an 'actionable step' would have been nice. It might be

> 'upgrade to 2.2.4 and 2.0.9 when they are released.' On a related note,
> should we expect notices on the alerts page to get posted to the announce
> list this message

> <https://groups.google.com/forum/?fromgroups=#!topic/mongodb-announce/...>has

> useful information in it about that nonsecurity issue.
>
> Finally there's "This feature/vulnerability was reported 3 weeks ago to
> 10gen developers, no patch was commit but the default javascript engine was
> changed in last version so there is no more nativeHelper.apply function."

> <http://blog.scrt.ch/2013/03/24/mongodb-0-day-ssji-to-rce/>I don't know

> anything about the communication that happened or agixid's track record,
> and I understand that communicating with security researchers can be
> difficult especially when they have different expectations. But if 2.4 came
> out apparently containing a fix for the issue reported and he'd already
> held off three weeks, a message asking him to hold off for a few more weeks
> until you had fixes for all supported versions ready might have worked and
> let this process be smoother.
>
> In short, I'm disappointed, but my own basic analysis is that this
> vulnerability is likely RCE but matters to one's application only if it
> either 1. uses a shared MongoDB instance or 2. has preexisting injection
> vulnerabilities (which now could potentially hurt the whole server vs just
> your data).
>
> Christian
>
>
>
>
>
>
>
> On Friday, March 29, 2013 10:58:35 AM UTC-7, Mark Hillick wrote:
>
> > Hi Bryan,
>
> > Thanks for your question and I truly appreciate your concern on this
> > issue. We take security issues like this very seriously and apologies if
> > you feel our advice was inadequate.
>
> > >> There are reports in the wild of RCE, and as far as I can tell no
> > fixed release.
>
> > I have previously communicated on this CVE a few times on this thread,
> > have my answers been unclear? Here is another thread on the same topic -

> >https://groups.google.com/forum/?fromgroups=#!searchin/mongodb-user/c...
> > .

>
> > Our alerts page has been updated with  information on this issue -
> >http://www.mongodb.org/about/alerts/.
>

> > Additionally, as you will see from SERVER-9124<https://jira.mongodb.org/browse/SERVER-9124>,

> > a fix has been committed to the 2.0, 2.2 and 2.4 code (2.0.9, 2.2.4 and
> > 2.4.2).
>
> > 2.2.4rc0 and 2.0.9rc0 have been released and this communication has bene
> > published on this Google Group. Again please let me know if this is unclear.
>
> > At present, I do not believe this is RCE - as I previously said I have
> > seen no evidence of successful code execution. The `mongod` service dies
> > when the query is executed and yes, this is most definitely not good
> > either.
>
> > From current analysis, the query can only be delivered through direct
> > connection to the mongod process, the POC is through a connection with the
> > `mongo` shell. Therefore, if you run with authentication, only an
> > authenticated user could run this query. If you have you `mongod` server
> > segregated off through firewall rules or other network acls then the query
> > can only be delivered from allowed devices.
>
> > >> There are reports in the wild of RCE
>

> > Can you provide evidence of this to secu...@10gen.com <javascript:>please? I have not seen a true RCE, the `mongod` process always dies - no

> >>>http://docs.mongodb.org/manual/administration/security/#vulnerability....

> >>> The good news is the fix has been committed (to 2.0, 2.2 and 2.4) as per my
> >>> previous update.
>
> >>> If anything is unclear or you feel I'm mistaken, please let me know.
>
> >>> Thanks
>
> >>> Mark
>
> >>> On Wednesday, March 27, 2013 8:09:06 PM UTC, Christian Csar wrote:
>
> >>>> I may just be reading that blog post incorrectly, but are you sure that
> >>>> isn't RCE? If Eve has access to a MongoDB database on a different server,
> >>>> ie she is using a shared mongodb hosting service, then she can legitimately
> >>>> submit queries to the server. The example exploit uses
> >>>> "db.my_collection.find(" to submit the exploit code. Is there a reason Eve
> >>>> can't make use of this remotely to execute code in the Mongo process she
> >>>> wouldn't otherwise have privileges to execute? CVE-2013-1892 is new enough
> >>>> that it doesn't seem to be on the NIST tracker.
>
> >>>> Christian
>
> >>>> On Wednesday, March 27, 2013 10:27:15 AM UTC-7, Mark Hillick wrote:
>
> >>>>> Hi Santiago,
>
> >>>>> The blog post by the
>

> ...
>
> читати далі »

[Hemant Bist]

Hi,

Will 10gen create Ubuntu packages with this fix for 2.2.X and 2.0.X releases? e.g. as far as I can tell, on 2.2.X code 2.2.3 is the latest package which does not have SERVER-9124 fix.

Thanks,

HB

[Mark Hillick]

Hi,

Yes, it is applicable to all `mongod` instances.

Thanks

Mark

[tetlika]

so, the vulnerability exploitation is possible just through direct
connection to mongod?

> ...
>
> читати далі »

[Mark Hillick]

Hi HB,

Yes, 10gen will create Ubuntu packages with the fix.

The current code (2.2.4rc0 and 2.0.9rc0) that contains the fixes is available as a binary download from the downloads page, however, not as .deb or .rpm.

A 2.2.4 and 2.0.9 GA release will be made in the next 24 hours assuming final testing of the rc0 builds pass and there are no show-stoppers from the field. Please see here for the fixes within 2.2.4 - https://jira.mongodb.org/browse/SERVER/fixforversion/12313.

Thanks

Mark

[Mark Hillick]

Hi,

Yes, that is correct. You have to be able to connect to the `mongod` instance and have permissions to run the query.

Thanks

Mark

[Mark Hillick]

Hi Christian,

I am truly sorry to hear that you are disappointed and I greatly appreciate your feedback on where you feel 10gen have been lacking. We will endeavour to learn from this incident and improve.

>>   I may be missing something, but is there a security bulletin of some kind?

All critical alerts and advisories can be found here - http://www.mongodb.org/about/alerts. We are currently working internally on reviewing this page and acknowledge the shortcomings. Thanks for providing the Debian link - I have reviewed other similar solutions and will take this on-board.

As I'm sure you  will understand, I cannot comment on dealings with any security researcher.

>> Why does mongod die?

I am very sorry, but unfortunately I cannot comment on this any further.

>> It's great that 2.2.4rc0 and 2.0.9rc0 have been released

As I mentioned in this thread (earlier this morning), 2.0.9 and 2.2.4 will be released in the next 24 hours assuming there are no show-stoppers in rc0 prior to that point. Communication regarding their release will be made in all the usual places, including this Google Group forum. I will request that the communication is more clear.

>> On a related note, should we expect notices on the alerts page to get posted to the announce list this message has useful information in it about that nonsecurity issue.

I don't quite follow what you're asking here. Are you asking that 10gen post to the Google Group when something gets added to the "alerts" page?

>> but my own basic analysis is that this vulnerability is likely RCE

At this minute in time, I see no evidence of a successful RCE and the security researcher has not presented any as far as I am aware. I personally don't see this as remote as the user has to have an authenticated connection to the database but others will disagree I'm sure. As with many exploits, the POC code is quite often improved very quickly once released to the community, so yes, a working RCE (possibly as a Metasploit module, though getting it into the Metasploit trunk can take some time) is without doubt a clear possibility.

At this stage, this is semantics and the main issue is that there was unfortunately a vulnerability in MongoDB.   At 10gen we take this very seriously: we have investigated the attack vector, tested and committed fixes for affected versions, and GA releases are planned within the next 24 hours.

Thanks

Mark

[Bryan Helmkamp]

Is v2.4.2 (released yesterday) considered by 10gen to be a security release? It's a bit unclear.

The docs page lists affected versions as "2.0.8, 2.2.3, and earlier." but states fixed versions as "2.0.9, 2.2.4, 2.4.2".

If 2.4.1 was not affected, why is 2.4.2 considered fixed?

-Bryan

[Stephen Steneker]

 

Is v2.4.2 (released yesterday) considered by 10gen to be a security release? It's a bit unclear.

The docs page lists affected versions as "2.0.8, 2.2.3, and earlier." but states fixed versions as "2.0.9, 2.2.4, 2.4.2".

If 2.4.1 was not affected, why is 2.4.2 considered fixed?

Hi Bryan,

The SERVER-9124 issue is specific to the SpiderMonkey JavaScript engine, which is no longer the default in MongoDB 2.4.  As of MongoDB 2.4, the default JavaScript engine is v8.

The affected versions listed in the alert page are the binary/default versions distributed by 10gen and available via mongodb.org.

It is still possible to compile a custom build of MongoDB with --usesm to use the SpiderMonkey engine instead of v8, so the fixVersion of 2.4.2 is noting that this change has also landed in the 2.4 branch.

The 2.4.2 release is a normal maintenance release.

Cheers,

Stephen