[SERVER-24117] Mongo binaries ELF stack has become executable Created: 10/May/16  Updated: 20/Nov/16  Resolved: 14/May/16

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: 3.2.5, 3.2.6
Fix Version/s: 3.2.7, 3.3.6

Type: Bug Priority: Critical - P2
Reporter: Marek Skalický Assignee: Andrew Morrow (Inactive)
Resolution: Done Votes: 1
Labels: code-only
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-23863 MongoDB v3.2.5 crash due to permissio... Closed
Duplicate
is duplicated by SERVER-23863 MongoDB v3.2.5 crash due to permissio... Closed
is duplicated by SERVER-24101 MongoDB needs excecution permission o... Closed
Related
related to WT-2629 Introduction of ppc64le crc32c assemb... Closed
is related to SERVER-24120 Make link warnings fatal Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Steps To Reproduce:

Always since 3.2.5

This affect also builds from https://www.mongodb.com/download-center#community

Tested for RHEL 7 64-bit and Amazon 64-bit.

Sprint: Platforms 14 (05/13/16)
Participants:

 Description   

mongod, mongoperf and mongosniff has executable GNU_STACK. This is a real error. It means the program has an executable stack. This leaves the program vulnerable to buffer overflows.

$ execstack path/to/binary

  • path/to/binary

A - indicates the secure non-executability.

If that shows an X or ? next to a file name, then the stack will be executable, i.e. insecure, i.e. bad. Furthermore, ? indicates a binary built with no marking at all, which is almost certainly a build error of some kind.

You can check it by execstack program.

[mskalick@unused-4-188 tmp]$ execstack bin/*
- bin/bsondump
- bin/mongo
X bin/mongod
- bin/mongodump
- bin/mongoexport
- bin/mongofiles
- bin/mongoimport
- bin/mongooplog
X bin/mongoperf
- bin/mongorestore
- bin/mongos
- bin/mongostat
- bin/mongotop

(I was trying to build MongoDB myself and mongosniff is also affected)

Binaries from 3.2.4 are not affected. So this was introduced in 3.2.5.

More info https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart



 Comments   
Comment by Githook User [ 16/May/16 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@mongodb.com'}

Message: SERVER-24117 Force the stack to always be non-executable

Also, warn if the stack would have been executable if we hadn't forced
it not to be, so we can find and correct broken assmbley source files.

(cherry picked from commit 23c5d7e44c5447769a46e6d4e10ae6237e8de5fd)
Branch: v3.2
https://github.com/mongodb/mongo/commit/61965e5792b29e3aaa04421e848731f1f2457766

Comment by Andrew Morrow (Inactive) [ 10/May/16 ]

mskalick - I've just pushed a commit to master to address this. Assuming it works as expected we will backport it to 3.2. If you have an opportunity to test it in your environment by building the master branch, that would be valuable information.

Comment by Githook User [ 10/May/16 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@mongodb.com'}

Message: SERVER-24117 Force the stack to always be non-executable

Also, warn if the stack would have been executable if we hadn't forced
it not to be, so we can find and correct broken assmbley source files.
Branch: master
https://github.com/mongodb/mongo/commit/23c5d7e44c5447769a46e6d4e10ae6237e8de5fd

Comment by Marek Skalický [ 10/May/16 ]

I am building MongoDB 3.2.6 for RHEL7 x86_64 and unittests and core jstests are working. I will inform you if other JS testsuites don't pass.

Comment by Andrew Morrow (Inactive) [ 10/May/16 ]

Yes, building with -Wl,-z,noexecstack added into LINKFLAGS should work fine:

scons LINKFLAGS="-Wl,-z,noexecstack" ...

If you could confirm that in your environment that would be helpful, as the fix we are introducing is similar.

Comment by Marek Skalický [ 10/May/16 ]

Will mongod work correctly with gcc --noexecstack compile flag?

Comment by Andrew Morrow (Inactive) [ 10/May/16 ]

Hi mskalick - Thanks for reporting this. We are already aware of the issue, which we agree is serious, and we are working on a fix.

Generated at Thu Feb 08 04:05:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.