Date: Mon, 8 Sep 2014 18:45:05 -0400 (EDT) From: cve-assign@...re.org To: kseifried@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Python robotframework - tmp vuln -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> 1, Is the "merge('../tmp/passing.xml', '../tmp/failing.xml')" >> debugging code, or is this code realistically used because a >> different piece of software has created passing.xml and failing.xml >> files? > It's part of __main__ so it gets executed. This doesn't really answer the question. In e8e423dc99094d761ea6944e71bb75eb5c418c8c, the upstream vendor says it's debug code. Also, note that result_merger.py is distributed with 0644 permissions. As far as we can tell, the "merge('../tmp/passing.xml', '../tmp/failing.xml')" is executed (in the potentially unsafe way) only if a user explicitly runs a command such as: python full_pathname/result_merger.py Otherwise, "__name__ == '__main__'" would be false. There's apparently no motivation for an end user to enter this python command in order to execute debug code that was meaningful only to the developer. To have a CVE for an issue involving a symlink attack, what we typically look for is a case in which code is executed during normal use of a product. In interpreting "normal use" situations, we think it's reasonable to exclude a user's decision to locate random 0644 files and launch them in isolation with a script interpreter. The 0644 permissions are, at least in some cases, a signal that the file was not intended to be executed in isolation. Products do not, in general, come with security expectations that running a 0644 file directly is safe (unless running the 0644 file is encouraged by the documentation). There doesn't seem to be a good argument for a CVE assignment regardless of the vendor's decision to delete the debug code. Possibly an example with sh would be simpler: % ls -ld /var/productdir/tmp drwxr-xr-x ... % cat /usr/bin/script1.sh #!/bin/sh export MYDIR=/var/productdir /bin/sh /usr/lib/product-1.0/files/script2.sh % cat /usr/lib/product-1.0/files/script2.sh echo test > $MYDIR/tmp/file.txt % ls -l /usr/bin/script1.sh -rwxr-xr-x ... % ls -l /usr/lib/product-1.0/files/script2.sh -rw-r--r-- ... Here, there could be a symlink attack if script2.sh is used in isolation. However, it seems best not to categorize script2.sh as having an "unsafe use of /tmp" or "symlink attack" vulnerability. For an arbitrary script2.sh file in an analogous situation, we'd typically want to see the following before assigning a CVE ID: - documentation telling a user to run "sh /usr/lib/product-1.0/files/script2.sh" or - executable permissions (such as 0755) for script2.sh along with (probably) a reason to expect that it would actually be run, such as any of these: - the location of script2.sh would realistically be added to a user's path - documentation of the purpose of script2.sh, when run in isolation, exists - by reading the script2.sh code, a user could notice that it accomplishes something useful in isolation - the actual filename suggests that the code accomplishes something useful in isolation - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJUDjDEAAoJEKllVAevmvmsGagIALXkDmmPDZyaOpi4TUjKmyfI oqaRfHRdp1UIsCKIscA3G2fSOs4IoulCn8XL03Gq3/mF4WstKCBbpTfRV+Tj0Wxj TlT5tG4pdYnqCTwIhDOElHme4HqvOnR8ID2wZg4gIDNdS6RMNcVBjEgVjGdyOcP8 19GIT/e4avvN5NaugyJWi4paKkjfDDvsoXiHFQvYSR11/lBO6mYJKS+r13x55b2l aM/53LIi7vGwI3Y/UgX5KClPRkAxnjBvkkzUJ8SJRM30tlUy6DoxlXyCX7hvz3Oj vO94HlWdS/2cJeLeyTxZeT4fG92pscFcCTIXZsqTAagWNe8FC0JUzvNfpYsP20A= =Rcqe -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ