[SERVER-7691] Java driver is capable of crashing mongod with a simple insert Created: 16/Nov/12  Updated: 15/Feb/13  Resolved: 06/Dec/12

Status: Closed
Project: Core Server
Component/s: Stability
Affects Version/s: 2.0.0, 2.2.1
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: Joel Westberg Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: Crash, Driver
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2008 r2 & OSX
Java Driver 2.9.*


Issue Links:
Duplicate
duplicates SERVER-7769 use --objcheck by default, Server arb... Closed
Related
Operating System: ALL
Steps To Reproduce:

Run the following in Java:

new Mongo().getDB("test").getCollection("test").insert(new BasicDBObject("\u0000Žö", ""));

Participants:

 Description   

MongoDB will crash if the Java driver can crash any MongoDB by writing a document containing a special string as the field name - \u0000Žö

new Mongo().getDB("test").getCollection("test").insert(new BasicDBObject("\u0000Žö", ""));

This actually came up in during real world usage when Apache Tika managed to produce the magical string as part of a field name. I have no idea what makes this string special, but removing any character will cause no issues.

Anyway, the result is the following output from mongod on OSX (output is similar on Windows):

Fri Nov 16 18:53:18 Invalid access at address: 0xbac3c5fe from thread: conn5
 
Fri Nov 16 18:53:18 Got signal: 11 (Segmentation fault: 11).
 
Fri Nov 16 18:53:18 Backtrace:
0x10004241b 0x10005628b 0x100056941 0x7fff828afcfa 0x1 0x100281611 0x100288c91 0x10006c501 0x10058e50c 0x1005e31d3 0x7fff8285b8bf 0x7fff8285eb75 
 0   mongod                              0x000000010004241b _ZN5mongo15printStackTraceERSo + 43
 1   mongod                              0x000000010005628b _ZN5mongo10abruptQuitEi + 987
 2   mongod                              0x0000000100056941 _ZN5mongo24abruptQuitWithAddrSignalEiP9__siginfoPv + 673
 3   libsystem_c.dylib                   0x00007fff828afcfa _sigtramp + 26
 4   ???                                 0x0000000000000001 0x0 + 1
 5   mongod                              0x0000000100281611 _ZN5mongo14receivedInsertERNS_7MessageERNS_5CurOpE + 1841
 6   mongod                              0x0000000100288c91 _ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE + 4705
 7   mongod                              0x000000010006c501 _ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE + 257
 8   mongod                              0x000000010058e50c _ZN5mongo3pms9threadRunEPNS_13MessagingPortE + 1084
 9   mongod                              0x00000001005e31d3 thread_proxy + 163
 10  libsystem_c.dylib                   0x00007fff8285b8bf _pthread_start + 335
 11  libsystem_c.dylib                   0x00007fff8285eb75 thread_start + 13

Attempting to insert a document containing a field name such as the one described using the mongo JavaScript shell does not work, unless it's part of a sub-document. Doing so, however, will cause an assertion error when trying to list the document.

> db.test.save({"\u0000Žö" : ""})
BSONElement: bad type -59
> db.test.save({"x" : {"\u0000Žö" : ""}})
> db.test.find()
Fri Nov 16 19:41:52 Assertion: 10320:BSONElement: bad type -59
0x10001ccdb 0x10001608c 0x100002312 0x10012c845 0x100211a0e 0x1002139a8 0x1001fa1c4 0x1002092df 0x1001c0ce8 0x1001c0deb 0x100139b3a 0x100027555 0x100028c0a 0x1000208d8 
 0   mongo                               0x000000010001ccdb _ZN5mongo15printStackTraceERSo + 43
 1   mongo                               0x000000010001608c _ZN5mongo11msgassertedEiPKc + 204
 2   mongo                               0x0000000100002312 _ZNK5mongo11BSONElement4sizeEv + 418
 3   mongo                               0x000000010012c845 _ZN5mongo16resolveBSONFieldEP9JSContextP8JSObjectljPS3_ + 389
 4   mongo                               0x0000000100211a0e js_LookupPropertyWithFlags + 734
 5   mongo                               0x00000001002139a8 js_GetProperty + 136
 6   mongo                               0x00000001001fa1c4 js_Interpret + 3396
 7   mongo                               0x00000001002092df js_Execute + 1103
 8   mongo                               0x00000001001c0ce8 JS_EvaluateUCScriptForPrincipals + 168
 9   mongo                               0x00000001001c0deb JS_EvaluateScript + 107
 10  mongo                               0x0000000100139b3a _ZN5mongo7SMScope4execERKNS_10StringDataERKSsbbbi + 330
 11  mongo                               0x0000000100027555 _Z5_mainiPPc + 14757
 12  mongo                               0x0000000100028c0a main + 42
 13  mongo                               0x00000001000208d8 start + 52
Error: BSONElement: bad type -59
> 

I have not tested this with any other driver.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 10/Dec/12 ]

Sorry, correct case is SERVER-7769, which is more exactly the same issue and severity.

Comment by Joel Westberg [ 09/Dec/12 ]

I urge you to reconsider, as this is capable of bringing down a mongod in production. In my case our application was generating the NUL, but I can easily see a malevolent user passing nul to a webservice backed by MongoDB, potentially bringing down the entire production service if the app happens to have been developed in a few unlucky languages (such as Java).

The severity of this issue in comparison to SERVER-7014 can't really be compared. That issue talks only about how the shell is able to insert strings with NUL. That issue, is if anything, a subset of this issue.

Comment by Ian Whalen (Inactive) [ 06/Dec/12 ]

although it's a slightly different symptom, this problem will be worked on as a part of SERVER-7014 - closing this as a dupe.

Comment by Joel Westberg [ 16/Nov/12 ]

It's rather intriguing though, that removing any of the 'Ž' or 'ö' characters, or replacing them, does not affect the server as harshly. I think the crash will only happen if Null character is followed by at least 2 multi-byte UTF-8 characters, but I might be mistaken.

Comment by Tad Marshall [ 16/Nov/12 ]

Hi Joel,

Thanks a lot for posting what you've found.

The BSON storage format and wire protocol store field names as NUL-terminated strings, and so it is not possible for a field name to contain an embedded NUL. The upshot is that we need to parse these more thoroughly at the driver (or shell) and perhaps be more defensive at the server.

If the server is run with --objcheck, it will perform validation on data presented by clients, but this is not on by default because the expectation is that the server is running in a secured environment with qualified clients.

This issue is related to SERVER-7014; this ticket also involves NUL bytes embedded in a field name, with related problems. I'll link that ticket to this one.

Tad

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