Python has become one of the most popular programming languages ​​in the world. The reason is, of course, Python's concise and easy-to-use script syntax, which can run quickly by simply putting a program into a .py file.

And the Python language is easy to get started with modules. For example, if you have written a module my_lib.py, you only need to add a line of import my_lib to the program that calls this module.

The advantage of this design is that beginners can execute commands very easily. But for attackers, this is tantamount to opening a backdoor for malicious programs.

Especially for some beginners, after downloading the online Python software package and code to the local ~/Downloads folder, they will directly run the python command in this path, which will bring great hidden dangers to the computer.

Don't make it easy

Why is it dangerous to do so? First, we need to understand the three conditions that Python programs need to meet to run safely:

Every entry on the system path is in a safe place;

The directory where the "main script" is located is always in the system path;

If the python command uses the -c and -m options, the calling program's directory must also be safe.

If you are running a properly installed Python, the only location outside the Python installation directory and virtualenv that is automatically added to the system path is the current main program installation directory.

This is where the security risks come from, and here's an example to tell you why.

If you installed pip in the /usr/bin folder and run the pip command. Since /usr/bin is the system path, this is a pretty safe place.

However, some people don't like to use pip directly, preferring to call /path/to/python -m pip instead.

This has the advantage of avoiding the complexity of setting the environment variable $PATH and, for Windows users, having to deal with installing various exe scripts and documentation.

So here comes the problem, if there is a file called pip.py in your download file, then you will replace the pip that comes with the system and take over your program.

Downloads folder is not safe

For example, you downloaded a Python wheel file directly from the Internet instead of PyPI. You naturally install it by typing:

~$ cd Downloads

~/Downloads$ python -m pip install ./totally-legit-package.whl

This seems like a very reasonable thing to do. But what you don't know is that doing this is very likely to visit a site with XSS JavaScript and drop a malware-laden pip.py into the download folder.

The following is a demo example of malicious attack software:

~$ mkdir attacker_dir

~$ cd attacker_dir

~/attacker_dir$ echo 'print("lol ur pwnt")' > pip.py

~/attacker_dir$ python -m pip install requests

lol ur pwnt

see it? This code generates a pip.py and takes over the program in place of the system's pip.

Setting $PYTHONPATH is also not safe

As mentioned earlier, Python will only call the system path, virtualenv virtual environment path and the current main program path. You may say, then I will manually set the $PYTHONPATH environment variable, and do not put the current directory in the environment variable, so it is not safe. Yet?

Not too! Unfortunately, you may encounter another attack. Let's simulate a "fragile" Python program:

tool.py

try:

import optional_extra

except ImportError:

print("extra not found, that's fine")

Then create 2 directories: install_dir and attacker_dir. Put the above program in install_dir. Then cd attacker_dir to put the complex malware there and change its name to the optional_extra module called by tool.py:

optional_extra.py

print("lol ur pwnt")

Let's run it:

~/attacker_dir$ python ../install_dir/tool.py

extra not found, that's fine

So far so good, no issues.

But this idiom has a serious flaw: the first time it is called, if $PYTHONPATH was previously empty or not set, it contains an empty string, which is resolved to the current directory.

Let's try it again:

~/attacker_dir$ export PYTHONPATH="/a/perfectly/safe/place:$PYTHONPATH";

~/attacker_dir$ python ../install_dir/tool.py

lol ur pwnt

see it? A malicious script took over the program.

To be on the safe side, you might be thinking that emptying your $PYTHONPATH should be fine, right? Naive! Still not safe!

~/attacker_dir$ export PYTHONPATH="";

~/attacker_dir$ python ../install_dir/tool.py

lol ur pwnt

What's happening here is that $PYTHONPATH becomes empty, which is not the same as unset.

Because in Python, os.environ.get("PYTHONPATH") == "" and os.environ.get("PYTHONPATH") == None are not the same.

If you want to make sure $PYTHONPATH is cleared from the shell, you need to process it with the unset command, and you're good to go.

Setting PYTHONPATH used to be the most common way to set up a Python development environment. But you'd better not use it in the future, virtualenv can better meet the needs of developers. If you have set a PYTHONPATH in the past, now is a good chance to delete it.

If you really need to use PYTHONPATH in the shell, use the following:

export PYTHONPATH="${PYTHONPATH:+${PYTHONPATH}:}new_entry_1"

export PYTHONPATH="${PYTHONPATH:+${PYTHONPATH}:}new_entry_2"

In bash and zsh, the value of the $PYTHONPATH variable becomes:

$ echo "${PYTHONPATH}"

new_entry_1:new_entry_2

This ensures that there are no spaces and extra colons in the environment variable $PYTHONPATH.

If you're still using $PYTHONPATH, make sure to always use absolute paths!

In addition, running Jupyter Notebook directly in the download folder is also dangerous, such as jupyter notebook ~/Downloads/anything.ipynb may also introduce malicious programs into the code.

Precaution

Finally, summarize the main points.

If you want to use tools written in Python in the Downloads folder ~/Downloads, make a good habit of using the path /path/to/venv/bin/pip where pip is located, instead of typing /path/to/venv/bin/python -m pip. Avoid ~/Downloads as the current working directory, and move any software you want to use to a more appropriate location before launching.

It's important to understand where Python gets its execution code from. Giving someone else the ability to execute arbitrary Python commands is equivalent to giving him full control over your computer!