[SERVER-25335] 0002 umask yields world-readable .dbshell history file Created: 29/Jul/16  Updated: 08/Jan/24  Resolved: 06/Sep/16

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 2.4.10
Fix Version/s: 3.0.15, 3.2.14, 3.3.14

Type: Bug Priority: Major - P3
Reporter: kpcyrd Assignee: Kevin Pulo
Resolution: Done Votes: 2
Labels: asp, asp-cve, asp-sdl-reported, asp-vuln-defaults, bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-22992 wait_for_pid() function in shell_util... Closed
is related to SERVER-26489 mongo shell no longer records history... Closed
is related to SERVER-25963 shell should warn user if .dbshell hi... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Backport Requested:
v3.2, v3.0
Steps To Reproduce:

rm ~/.dbshell
echo test | mongo
ls -la ~/.dbshell

Participants:
Linked BF Score: 27

 Description   

During a very similar bug report on redis (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832460), lamby@ linked to a code search which hinted a similar bug in mongodb.

I've verified this bug exists in 2.4.10 (current mongodb in debian stable), but I'm not sure about the latest version.

I think the severity for this bug is lower, given that db.auth isn't written to ~/.dbshell, but it might leak sensitive application specific information that might be useful for a local attacker.

I suggest the permissions should be set to the user only (0600) instead of world readable (0644, current permissions).



 Comments   
Comment by Githook User [ 03/May/17 ]

Author:

{u'username': u'devkev', u'name': u'Kevin Pulo', u'email': u'kevin.pulo@mongodb.com'}

Message: SERVER-25335 SERVER-26489 avoid group and other permissions when creating .dbshell history file

Cherry-picked from:

  • 035cf2afc04988b22cb67f4ebfd77e9b344cb6e0
  • f2c3376d70a3540d3bee5e32abe9d5517f571369
  • 4a431ceb4cb1d986ceb54ee26ca86915ef9ffd42

With additional adjustments to handle the inability to pass environment
variables to runProgram().
Branch: v3.2
https://github.com/mongodb/mongo/commit/e6b5935caccd012bccef945b4df82149a5a9957c

Comment by Githook User [ 01/May/17 ]

Author:

{u'username': u'devkev', u'name': u'Kevin Pulo', u'email': u'kevin.pulo@mongodb.com'}

Message: SERVER-25335 SERVER-26489 avoid group and other permissions when creating .dbshell history file

Cherry-picked from:

  • 035cf2afc04988b22cb67f4ebfd77e9b344cb6e0
  • f2c3376d70a3540d3bee5e32abe9d5517f571369
  • 4a431ceb4cb1d986ceb54ee26ca86915ef9ffd42

With additional adjustments to handle the inability to pass environment
variables to runProgram().
Branch: v3.0
https://github.com/mongodb/mongo/commit/0ee59992ef9627809e2ff13c608a023fc6b8c909

Comment by Grant Ridder [ 06/Sep/16 ]

Sounds great, thanks!!!

Comment by Githook User [ 06/Sep/16 ]

Author:

{u'username': u'devkev', u'name': u'Kevin Pulo', u'email': u'kevin.pulo@mongodb.com'}

Message: SERVER-25335 use open + fdopen on OSX, and cope with slow program output
Branch: master
https://github.com/mongodb/mongo/commit/f2c3376d70a3540d3bee5e32abe9d5517f571369

Comment by Kevin Pulo [ 06/Sep/16 ]

Hi Grant,

Thanks for your patience with this issue. As you can see, we have now pushed a fix for this issue to the master branch. It takes a different approach to the code in the Pull Request, and it is both more idiomatically POSIX (passing a mask to open(2)), and avoids explicitly changing permissions of the history file (which might override what the user wants). As such, I have closed out the Pull Request. I will now look into backporting this change, which I expect to be reasonably straightforward. As always, I will keep the ticket updated accordingly.

Best regards,
Kev

Comment by Githook User [ 06/Sep/16 ]

Author:

{u'username': u'devkev', u'name': u'Kevin Pulo', u'email': u'kevin.pulo@mongodb.com'}

Message: SERVER-25335 avoid group and other permissions when creating .dbshell history file
Branch: master
https://github.com/mongodb/mongo/commit/035cf2afc04988b22cb67f4ebfd77e9b344cb6e0

Comment by Grant Ridder [ 29/Aug/16 ]

Sounds good, thanks for the update!

Comment by Kevin Pulo [ 29/Aug/16 ]

Hi Grant,

For issues that affect code in the master branch (currently the 3.3 development series), our development workflow is to first address the issue in master. Once this has been done we can consider backporting the change to earlier stable branches. We will update the ticket as it progresses through these stages.

Best regards,
Kev

Comment by Grant Ridder [ 25/Aug/16 ]

Any reason its not being included in 3.2 and backporting to 3.0?

Comment by Ramon Fernandez Marina [ 24/Aug/16 ]

We expect to address this ticket in this development cycle, as indicated by the "3.3 Desired" Fix Version. We're evaluating different approaches to address the issue, please continue to watch the ticket for updates.

Regards,
Ramón.

Comment by Grant Ridder [ 24/Aug/16 ]

@ramon.fernandez any update on this ticket? closing in on a month of it being open

Comment by Grant Ridder [ 15/Aug/16 ]

Created https://github.com/mongodb/mongo/pull/1106 to pull in the upstream change from the linenoise repo

Comment by Grant Ridder [ 15/Aug/16 ]

I would suggest pulling in a further upstream change instead. Also i am not sure that a check and chmod should be required in linenoiseHistoryLoad since the save function, linenoiseHistorySave, takes care of the chmod

int linenoiseHistorySave(const char *filename) {
    mode_t old_umask = umask(S_IXUSR|S_IRWXG|S_IRWXO);
    FILE *fp;
    int j;
 
    fp = fopen(filename,"w");
    umask(old_umask);
    if (fp == NULL) return -1;
    chmod(filename,S_IRUSR|S_IWUSR);
    for (j = 0; j < history_len; j++)
        fprintf(fp,"%s\n",history[j]);
    fclose(fp);
    return 0;
}

Comment by Marek Skalický [ 08/Aug/16 ]

Thanks for reopening this bug and effort to create upstream "fix".

Is it acceptable for MongoDB to have different behavior for linux and windows users? (for example see Debian fix https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=832908;filename=CVE-2016-6494.patch;msg=56 ; of course there have to be #ifndef _WIN32)
Or is it somehow possible to get same behavior for windows which use ACLs?)

Comment by Ramon Fernandez Marina [ 04/Aug/16 ]

Reopening this ticket to host further discussion.

Comment by Grant Ridder [ 01/Aug/16 ]

MongoDB doesn't take any action on the permissions of .dbshell

That might be the case, but IMO that should probably change.

Comment by Ramon Fernandez Marina [ 30/Jul/16 ]

grant@teambanjo.com, given your settings for umask the permissions of the .dbshell file are expected. MongoDB doesn't take any action on the permissions of .dbshell; when that file is created its permissions are determined by the value of umask.

Since this is not a but in MongoDB I'm going to close this ticket. kpcyrd, if you can please post the value of umask that will help us confirm this resolution. On the other hand, if you find evidence of a bug in MongoDB please let us know and we'll reopen this ticket.

In the future, I'd like to suggest postings similar questions in the mongodb-user group or Stack Overflow with the mongodb tag, where they will reach a larger audience. A question like this involving more discussion would be best posted on the mongodb-user group. Only if a bug is found a ticket in the SERVER project is warranted.

Thanks,
Ramón.

Comment by Grant Ridder [ 29/Jul/16 ]

$ umask
0002
$ 

$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID:	CentOS
Description:	CentOS Linux release 7.2.1511 (Core) 
Release:	7.2.1511
Codename:	Core
$ 

Comment by Ramon Fernandez Marina [ 29/Jul/16 ]

My first read of this report made me think whether there's a umask-related bug, so I tried the following:

$ rm ~/.dbshell 
$ umask 077
$ mongo
MongoDB shell version: 3.2.8
connecting to: test
replset:PRIMARY> db.foo.findOne()
{ "_id" : ObjectId("5791464be7f8cb5f04581a19"), "a" : 2907, "b" : 881 }
replset:PRIMARY> 
bye
$ ls -la ~/.dbshell 
-rw------- 1 me me 17 Jul 29 17:09 /home/me/.dbshell

So it looks to me that the reason for the 664 permission could be the umask setting. What's the output of the umask command? Or am I missing something?

Thanks,
Ramón.

Comment by kpcyrd [ 29/Jul/16 ]

Link to the debian bug: https://bugs.debian.org/832908
This got assigned CVE-2016-6494 (you might want to add this to the title, it looks like I don't have permissions to do that)

I think a bisectable way to figure out if a version is affected looks like this (insert compile command as necessary):

rm -f ~/.dbshell; echo "db.help()" | mongo > /dev/null; stat -c "%A" ~/.dbshell | grep -q -- -rw-------

edit: sorry, didn't reload the page before commenting

Comment by Grant Ridder [ 29/Jul/16 ]

as a side note, CVE-2016-6494 was assigned to this

Comment by Grant Ridder [ 29/Jul/16 ]

Looks like this still affects the newest version of 3.2 as well (although home directories on CentOS, which i am running, are not world readable)

$ mongo --version
MongoDB shell version: 3.2.8
$ mongod --version
db version v3.2.8
git version: ed70e33130c977bda0024c125b56d159573dbaf0
OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
allocator: tcmalloc
modules: none
build environment:
    distmod: rhel70
    distarch: x86_64
    target_arch: x86_64
$ ls -la ~/.dbshell 
-rw-rw-r--. 1 user user 647 Jul 28 23:02 /home/user/.dbshell
$ 

$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID:	CentOS
Description:	CentOS Linux release 7.2.1511 (Core) 
Release:	7.2.1511
Codename:	Core
$ 

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