Michael Scherer (misc) 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
This code was removed when all v1 cartridges were purged: commit 3b74dd3d162a9a3b63a7ac4e1eaccea6b889e186 Author: Dan McPherson <dmcphers> Date: Fri Jun 14 16:20:12 2013 -0400 First pass at removing v1 cartridges
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/.