oss-sec mailing list archives
Re: Python robotframework - tmp vuln
From: cve-assign () mitre org
Date: Mon, 8 Sep 2014 18:45:05 -0400 (EDT)
-----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-----
Current thread:
- Python robotframework - tmp vuln Kurt Seifried (Sep 07)
- Re: Python robotframework - tmp vuln Kurt Seifried (Sep 07)
- Re: Python robotframework - tmp vuln coderman (Sep 07)
- Re: Python robotframework - tmp vuln cve-assign (Sep 08)
- Re: Python robotframework - tmp vuln Kurt Seifried (Sep 08)
- Re: Re: Python robotframework - tmp vuln Mikko Korpela (Sep 08)
- Re: Python robotframework - tmp vuln cve-assign (Sep 08)
- Re: Python robotframework - tmp vuln Kurt Seifried (Sep 08)
- <Possible follow-ups>
- RE: Python robotframework - tmp vuln Mikko Korpela (Sep 08)
- Re: Python robotframework - tmp vuln Kurt Seifried (Sep 07)