Bug 892912 (CVE-2013-0165)

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