[CDRIVER-1691] /dev/shm/mongoc-${PID} is created in an insecure manner Created: 11/Oct/16 Updated: 26/Jun/17 Resolved: 18/Oct/16 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.5.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Balazs Scheidler | Assignee: | Hannes Magnusson |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
We've received a security report report about syslog-ng, that uses mongo-c-driver to send log messages to mongodb. The problem is actually in mongo-c-driver, and could apply to all applications using mongo-c-driver, hence this report. The shared memory block in /dev/shm/mongoc-${PID} is a predictable name, in a world writable directory without O_EXCL and O_NOFOLLOW, thus can be used to craft a symlink attack. We created this workaround that passes --disable-shm-counters to the configure script: https://github.com/balabit/syslog-ng/pull/1219 But that won't fix distributions (once mongo-c-driver is included there) and it would be a lot better to actually fix the problem so that mongoc-stats remains available after the fix. Is this something that you can handle with priority? Because if it is, I'd not commit our workaround, but rather wait for the proper fix. If it is not, we would disable the shm based counters in our builds. |
| Comments |
| Comment by Githook User [ 18/Oct/16 ] |
|
Author: {u'username': u'bjori', u'name': u'Hannes Magnusson', u'email': u'bjori@php.net'}Message: |
| Comment by A. Jesse Jiryu Davis [ 11/Oct/16 ] |
|
"it would be a lot better to actually fix the problem so that mongoc-stats remains available after the fix." |
| Comment by Hannes Magnusson [ 11/Oct/16 ] |
|
| Comment by A. Jesse Jiryu Davis [ 11/Oct/16 ] |
|
What's the planned workaround? |
| Comment by Hannes Magnusson [ 11/Oct/16 ] |
|
We are preparing for 1.5.0 and currently in RC phase. I imagine we can have this fix included in the next RC |