Python Security — Python Security 0.0 documentation (original) (raw)

Python Security model

Python doesn’t implement privilege separation (not “inside” Python) to reduce the attack surface of Python. Once an attacker is able the execute arbitrary Python code, the attacker basically gets a full access to the system. Privilege separation can be implemented “outside” Python by putting Python inside a sandbox.

Example with bpo-36506 (closed as not a bug): getattr() executes arbitrary code by design, it’s not a vulnerability.

Bytecode

CPython doesn’t verify that bytecode is safe. If an attacker is able to execute arbitrary bytecode, we consider that the security of the bytecode is the least important issue: using bytecode, sensitive code can be imported and executed.

For example, the marshal doesn’t validate inputs.

Sandbox

Don’t try to build a sandbox inside CPython. The attack surface is too large. Python has many introspection features, see for example the inspect module. Python also many convenient features which executes code on demand. Examples:

The good design is to put CPython into a sandbox, not the opposite.

Ok, understood, but I want a sandbox in Python. Well…

Dangerous functions and modules

Archives and absolute paths

RNG

The random module must not be used in security sensitive code, except of the random.SystemRandom class.

CPython Security Experts

Windows

ASLR and DEP

ASLR and DEP protections enabled since Python 3.4 (and Python 2.7.11 if built using PCbuild/ directory).

Unsafe Python 2.7 default installation directory

Python 2.7 installer uses C:\Python27\ directory by default. The created directory has the “Modify” access rights given to the “Authenticated Users” group. An attacker can modify the standard library or even modify python.exe. Python 3 installer now installs Python in C:\Program Files by default to fix this issue. Override the default installation directory, or fix the directory permissions.

DLL injection

On Windows 8.1 and older, the installer is vulnerable to DLL injection: evil DLL written in the same download directory that the downloaded Python installer. See DLL Hijacking Just Won’t Die.

DLL injection using PATH

Inject a malicious DLL in a writable directory included in PATH. The “pip” step of the Python installer will run this DLL.

We consider that it is not an issue of Python (Python installer) itself.

Once you have write access to a directory on the system PATH (not the current user PATH) and the ability to write binaries that are not validated by the operating system before loading, there are many more interesting things you can do rather than wait for the Python installer to be run.

Module Search Path (sys.path)

Static analysers of CPython code base

Misc

Links