Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon,  8 Sep 2014 18:45:05 -0400 (EDT)
Subject: Re: Python robotframework - tmp vuln

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 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/

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

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

Possibly an example with sh would be simpler:

  % ls -ld /var/productdir/tmp
  drwxr-xr-x ...
  % cat /usr/bin/
  export MYDIR=/var/productdir
  /bin/sh /usr/lib/product-1.0/files/
  % cat /usr/lib/product-1.0/files/
  echo test > $MYDIR/tmp/file.txt
  % ls -l /usr/bin/
  -rwxr-xr-x ...
  % ls -l /usr/lib/product-1.0/files/
  -rw-r--r-- ...

Here, there could be a symlink attack if is used in
isolation. However, it seems best not to categorize as
having an "unsafe use of /tmp" or "symlink attack" vulnerability. For
an arbitrary 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/"


  - executable permissions (such as 0755) for along with
    (probably) a reason to expect that it would actually be run,
    such as any of these:

       - the location of would realistically be added
         to a user's path

       - documentation of the purpose of, when run in
         isolation, exists

       - by reading the 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 ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.