Title: File "" is opened and read unconditionally
Type: security Stage: resolved
Components: Interpreter Core Versions:
Status: closed Resolution: duplicate
Dependencies: Superseder: when "python -c command" does a traceback, it open the file "<string>"
View: 16974
Assigned To: Nosy List: serhiy.storchaka, snizio
Priority: normal Keywords:

Created on 2018-04-09 07:48 by snizio, last changed 2018-04-09 08:10 by serhiy.storchaka. This issue is now closed.

Messages (2)
msg315113 - (view) Author: SÅ‚awomir Nizio (snizio) Date: 2018-04-09 07:48
This may lead to e.g. DoS or data leak.

When an exception occurs, the Python interpreter displays the stack trace:

$ python3
Traceback (most recent call last):
  File "", line 2, in <module>
ZeroDivisionError: division by zero

and does so also when there is no source file:

$ python3 -c 'print(1/0)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ZeroDivisionError: division by zero

It opens the file in question to read the needed bits, and an the latter
case it tries to open file named literally <string>.

There is a possibility of a denial of service (a), data leak (b) and
other types of problems (c).

a) If "<string>" is a symbolic link for example to /dev/stdin or an
"empty" fifo, the script hangs.

$ ln -s /dev/stdin '<string>'
$ python3 -c 'print(1/0)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>

# hangs here

b) If <string> is a symbolic link, its content will be read as well.
This can be a file with some kind of secret data, readable by the user
executing the script, but which should not be normally displayed to
screen (or for example sent back with HTTP to display the error message).

User who can run a certain script (for example using sudo) that calls
python -c as root or other user may be able to see parts of otherwise
inaccessible files.

c) Other attacks (or misbehaviour) is possible, for example file
<string> could be a symbolic link to a device file which upon reading
triggers some system wide action.

An interesting possiblity (if not necessarity a security issue by
itself) is a way to trick a user about the cause of the exception, like
in the example.

$ echo 'print(0/1)' > '<string>'
$ python3 -c 'print(1/0)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ZeroDivisionError: division by zero

As it turns out, the file doesn't need to be in the current directory
but anywhere in sys.path.

I was able to confirm the behaviour on all versions I tried: 2.7.14,
3.5.4 and 3.6.5.

This is in a way similar to the problem with Python modules loaded from
current working directory: (sys.path[0] security issues)
but the essential differences are that:
- upon validation system (e.g. a server) may reject Python files but
leave out "<string>,"
- system can sanitize sys.path which helps with the sys.path[0] bug but
not the one being described.
msg315114 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-04-09 08:10
This is a duplicate of issue16974.
Date User Action Args
2018-04-09 08:10:25serhiy.storchakasetstatus: open -> closed

superseder: when "python -c command" does a traceback, it open the file "<string>"

nosy: + serhiy.storchaka
messages: + msg315114
resolution: duplicate
stage: resolved
2018-04-09 07:48:51sniziocreate