[SERVER-18941] SEVER Segmentation Fault error triggered from MongoShell find query Created: 12/Jun/15  Updated: 15/Jun/15  Resolved: 12/Jun/15

Status: Closed
Project: Core Server
Component/s: Querying, Security
Affects Version/s: 2.6.10
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Chris Assignee: Jonathan Reams
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Selection_003.png    
Issue Links:
Related
related to DOCS-3952 Disable MACs (SELinux, etc) Closed
Operating System: ALL
Steps To Reproduce:

Fedora 21 using Mongo 2.6.10.
Execute find query as such on a valid collection with valid fields i.e db.Users.find("this.name==this.surname")

Participants:

 Description   

It was possible to trigger a Signal 11 Segmentation fault error and completely crash the Mongod service via a trivial find query using the shell.



 Comments   
Comment by Jonathan Reams [ 15/Jun/15 ]

Hi Chris,

There shouldn't be any issue with using 2.6.10 on Fedora 21. I just started a Fedora 21 x86_64 box and ran mongodb just fine on it, and I created a test database with the content you supplied above (the "Users" collection) and did ran the "this.name==this.name" query without issue.

The stack trace you gave us looked like an issue commonly seen when using a kernel with grsec/pax security patches installed. These security patches prevent processes from mapping memory as executable, and since V8 allocates executable memory for running javascript, mongod crashes while trying to initialize V8 to run your query. Your stacktrace shows the SEGFAULT in the V8 javascript engine while trying to create the builtin javascript math functions. (see SERVER-12991 for more details on this).

You can see if you have a patched kernel by installing/running the checksec package and running checksec --kernel. If you don't have your kernel configured then something else could be going on, but I don't think there are any incompatibilities with Fedora 21. Let me know if you have any more questions.

Jonathan

Comment by Chris [ 12/Jun/15 ]

Hi James,

I was able to start the Mongod service without having to implement the additional notes mentioned for SELinux systems in the Red Hat install notes. However I will try the additional configuration in the install notes aswell. Perhaps this is a issue in default installs as I have installed the MongoDB instance on a vanilla Fedora 21 instance using the provided install notes.

Could you please explain the difference between the two statuses mentioned, "Work" and "Designed".

In terms of the bug, is it therefore not recommended to use 2.6.10 on Fedora 21?

Many thanks,
Chris

Comment by David Storch [ 12/Jun/15 ]

Hi Chris,

It looks like you may have SELinux enabled. Instructions for fixing you configuration can be found at the link below. If this doesn't work, you might be using an unsupported linux kernel.

http://docs.mongodb.org/manual/tutorial/install-mongodb-on-red-hat/#run-mongodb

I'm going to close this ticket as Works as Designed.

Best,
Dave

Comment by Chris [ 12/Jun/15 ]

Hi Dave,

To answer your questions:
-There is only the default index on the ObjectId field
-The shell version is MongoDB shell version: 2.6.10
-> db.runCommand(

{buildinfo:1}

) output:

{ "version" : "2.6.10", "gitVersion" : "5901dbfb49d16eaef6f2c2c50fba534d23ac7f6c", "OpenSSLVersion" : "", "sysInfo" : "Linux build18.nj1.10gen.cc 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3 21:39:27 UTC 2014 x86_64 BOOST_LIB_VERSION=1_49", "loaderFlags" : "-fPIC -pthread -Wl,-z,now -rdynamic", "compilerFlags" : "-Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -pipe -Werror -O3 -Wno-unused-function -Wno-deprecated-declarations -fno-builtin-memcmp", "allocator" : "tcmalloc", "versionArray" : [ 2, 6, 10, 0 ], "javascriptEngine" : "V8", "bits" : 64, "debug" : false, "maxBsonObjectSize" : 16777216, "ok" : 1 }
Comment by David Storch [ 12/Jun/15 ]

Hi Chris,

Thanks for filing this report! I tried to reproduce following your steps, but was unable:

> db.version()
2.6.10
> db.Users.drop()
true
> db.Users.insert({ "_id" : ObjectId("5579b68e7f33ba3b3317e7c2"), "name" : "chris", "sensitiveData" : "thisIsSensitive", "gender" : "male" })
WriteResult({ "nInserted" : 1 })
> db.Users.insert({ "_id" : ObjectId("5579b6997f33ba3b3317e7c3"), "name" : "christy", "sensitiveData" : "thisIsSensitiveToo", "gender" : "female" })
WriteResult({ "nInserted" : 1 })
> db.Users.insert({ "_id" : ObjectId("5579b6ab7f33ba3b3317e7c4"), "name" : "john", "sensitiveData" : "thisIsNotSensitiveButYolo", "gender" : "male" })
WriteResult({ "nInserted" : 1 })
> db.Users.insert({ "_id" : ObjectId("5579bb26888f71faabbac131"), "name" : "chris", "gender" : "dontKnow" })
WriteResult({ "nInserted" : 1 })
> db.Users.find("this.name==this.name")
{ "_id" : ObjectId("5579b68e7f33ba3b3317e7c2"), "name" : "chris", "sensitiveData" : "thisIsSensitive", "gender" : "male" }
{ "_id" : ObjectId("5579b6997f33ba3b3317e7c3"), "name" : "christy", "sensitiveData" : "thisIsSensitiveToo", "gender" : "female" }
{ "_id" : ObjectId("5579b6ab7f33ba3b3317e7c4"), "name" : "john", "sensitiveData" : "thisIsNotSensitiveButYolo", "gender" : "male" }
{ "_id" : ObjectId("5579bb26888f71faabbac131"), "name" : "chris", "gender" : "dontKnow" }

Can you provide any follow-up information about how to reproduce? The following might help:

  • The list of indexes on the Users collection.
  • The version of the shell you are using.
  • The output of the db.runCommand({buildinfo: 1}) command.

Thanks,
Dave

Comment by Chris [ 12/Jun/15 ]

Hi Andreas,

I have a single collection in database. The collection has three fields and is named "Users". The error occurs when I execute the following query from the Mongo Shell: ->db.Users.find("this.name==this.name").

Here is my shell output:

show dbs
admin (empty)
local 0.078GB
sensesploit 0.078GB
test (empty)
> use sensesploit
switched to db sensesploit
> show collections
Users
system.indexes
> db.Users.find()

{ "_id" : ObjectId("5579b68e7f33ba3b3317e7c2"), "name" : "chris", "sensitiveData" : "thisIsSensitive", "gender" : "male" } { "_id" : ObjectId("5579b6997f33ba3b3317e7c3"), "name" : "christy", "sensitiveData" : "thisIsSensitiveToo", "gender" : "female" } { "_id" : ObjectId("5579b6ab7f33ba3b3317e7c4"), "name" : "john", "sensitiveData" : "thisIsNotSensitiveButYolo", "gender" : "male" } { "_id" : ObjectId("5579bb26888f71faabbac131"), "name" : "chris", "gender" : "dontKnow" }

> db.Users.find("this.name==this.name")
2015-06-12T15:40:06.560+0200 DBClientCursor::init call() failed
Error: error doing query: failed
2015-06-12T15:40:06.562+0200 trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2015-06-12T15:40:06.563+0200 warning: Failed to connect to 127.0.0.1:27017, reason: errno:111 Connection refused
2015-06-12T15:40:06.563+0200 reconnect 127.0.0.1:27017 (127.0.0.1) failed failed couldn't connect to server 127.0.0.1:27017 (127.0.0.1), connection attempt failed

Is this report being considered as a security vulnerability?

Please let me know if you have any further questions.

Comment by Andreas Nilsson [ 12/Jun/15 ]

Thanks for your report Chris!

Would you mind providing the exact query and the layout of your collection so we can try to reproduce the problem.

Regards,
Andreas

Generated at Thu Feb 08 03:49:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.