Bug 892912 (CVE-2013-0165) - CVE-2013-0165 OpenShift mongodb cartridge: info/bin/dump.sh /tmp file creation
Summary: CVE-2013-0165 OpenShift mongodb cartridge: info/bin/dump.sh /tmp file creation
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2013-0165
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 767033 893313
TreeView+ depends on / blocked
 
Reported: 2013-01-08 08:45 UTC by Kurt Seifried
Modified: 2019-09-29 12:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-24 07:43:57 UTC


Attachments (Terms of Use)

Description Kurt Seifried 2013-01-08 08:45:02 UTC
Michael Scherer (misc@zarb.org) of Red Hat reports:

Description of problem:

in the ./cartridges/openshift-origin-cartridge-mongodb-2.2/info/bin/dump.sh file, the script create a directory in /tmp/ for dumping the content of the db, and then cd to it. Since it use $$, the name could be predicted or a for loop could be used to bruteforce it ( by creating several file with potential filename, as there is just  )

There is several issue with this approach :

- the mkdir -p use a predictable filename. Someone could create several link with a loop, and then the script would jump in, since the return code of mkdir is not checked. So if I create a link /tmp/mondogodbdump.$$ to a directory I control ( so with 777 permission ), I could trick someone into running a dump and potentially steal the information. As this would be dumped in a directory I control and I can read, depending on the umask used, it may end readable by the attacker.

- pushd do not check at all if the file is a directory. So if there is a file /tmp/mongodump.1234 , then pushd would silently fail, and then create the dump ( and run the tar.gz creation command from current directory, or worst, from a directory decided by the attacker. There, a attacker could inject some fake table in bson format to the archive. Depending on the application, this could be a building block for a more specialized attack. 

While it would surely do no harm on openshift online ( due to polyinstanciation and selinux , I think this could cause potential issues if someone didn't use selinux to properly separate the users ( ie, someone using openshift without following all the recommendation for deployment ).

- rm -Rf /tmp/mongodbdump.$$ doesn't sound great either, depending on the uid of the user running the script, and depending on where a potential link would be point too. Again, openshift online should not suffer from the problem, based on what I know of the architecture. But someone could be tricked into erasing the project directory, or worst.

- if mongodb try to dump and cannot write a file, it crash ( segfault, reported as 892035 ). While this is not related to that, it could be used for some dos attack by filling the harddrive

Comment 1 Kurt Seifried 2014-06-24 07:42:10 UTC
This code was removed when all v1 cartridges were purged:

commit 3b74dd3d162a9a3b63a7ac4e1eaccea6b889e186
Author: Dan McPherson <dmcphers@redhat.com>
Date:   Fri Jun 14 16:20:12 2013 -0400

    First pass at removing v1 cartridges

Comment 2 Kurt Seifried 2014-06-24 07:43:57 UTC
Statement:

Red Hat Product Security has rated this issue as having Low security impact. Additionally this issue has been addressed through the removal of all v1 cartridges. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.


Note You need to log in before you can comment on or make changes to this bug.