Exploitable Python Functions [closed]

Question

This question is similar to Exploitable PHP Functions.

Tainted data comes from the user, or more specifically an attacker. When a tainted variable reaches a sink function, then you have a vulnerability. For instance a function that executes a sql query is a sink, and GET/POST variables are sources of taint.

What are all of the sink functions in Python? I am looking for functions that introduce a vulnerability or software weakness. I am particularly interested in Remote Code Execution vulnerabilities. Are there whole classes/modules that contain dangerous functionally? Do you have any examples of interesting Python vulnerabilities?

Caboodle

How about making this a community wiki? – Paoting

@Sven Marnach how would that make this better? I haven't done that before. – Caboodle

It is (would be?) very difficult to secure Python to any great degree; the language is simply too flexible for that. If you're trying to create a secure Python environment, you have a very large task ahead of you. – Ortrude

@katrielalex actually my motivations are quite the opposite, I am auditing python applications looking for vulnerabilities. I will be reporting the issues to the vendor, of course. – Caboodle

@Rook: It would enable people to collaboratively compile the list. The accepted answer of the PHP post you linked is also a community wiki post. – Paoting

@Sven Marnach your more than welcome to edit my post for this thread. I had some help with the PHP list and that worked out. – Caboodle

Answer 1

eval and exec are the classics. However, open and file can be abused too:

open('/proc/kcore', 'w').write('0' * 1000 * 1000 * 1000)

Then there are the os, sys, subprocess, and dircache modules. Pretty much anything that touches the filesystem or can be used to turn data into executable code (like os.system) is going to be on the list.

As S. Lott pointed out in the comments, writing to the filesystem and executing arbitrary external programs aren't Python-specific. However, they are worth security auditors' consideration. Most of these functions can be safely used without too much concern for security. eval and exec, on the other hand, are great big red flags. Using them safely requires meticulous care.

Sudarium

Opening '/proc/kcore' requires privileges that most processes don't have. This is a different kind of exploit because it requires privileges and isn't just shabby coding. – Frangipane

@S.Lott: Sure, but that was just a (dramatic) example. Maybe an attacker expects to be running as the web server user and opens /var/www/index.html instead. Good security is layered. We can't expect all our users' administrators to ensure that everything runs with optimal permissions all the time, so it's worth paying a little extra attention and looking for this sort of thing. – Sudarium

"Good security is layered". That's not entirely the point. The eval and exec are Python exploits that don't rely on security. The other exploit is different in kind -- it's irrelevant to Python, since all languages have it. It's part of OS privilege management. If you're going to list that, then you have to start listing all OS exploits that have nothing to do with Python. I think you should segregate this more clearly in your answer as a different kind of exploit that only happens to use Python. – Frangipane

@S.Lott: Fair enough. Better? – Sudarium

Answer 2

right from the pickle documentation:

Warning

The pickle module is not intended to be secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.

Pearl

Pickled data is on of the worst, since it's not structured or readable enough to sanitise, and arbitrary code can be executed while unpickling. For example, sending pickled data structures over DBUS (or some other open-ish IPC mechanism) can be a massive security hole, but this is not necessarily obvious to someone new to Python or DBUS. A better approach is to write an explicit serialisation method, using JSON or XML, and send THAT over whatever protocol you're using. – Victorvictoria

Answer 3

I tend toward the paranoid when looking for this kind of thing. More so because I tend to do alot of metaprogramming.

• most side effect commands (which other posts cover)
  • file manipulation (open, tarfile, zipfile, ...)
  • network calls (urllib2, socket, ...)
  • data serialization/persistence (pickle, shelve, ...)
  • process/thread management (subprocess, os.fork, os.kill, ...)
• builtins
  • getattr
  • setattr
  • delattr
  • eval
  • exec
  • execfile
  • __import__

And probably others I'm forgetting. I'm also wary of user input going through functions where I'm modifying sys.path, sys.modules, etc.

Degradation

Answer 4

The subprocess module contains nasty functionally which deprecated these ways of executing commands/processes:

os.system
os.spawn*
os.popen*
popen2.*
commands.*

There is also exec which will execute python code and eval which will "evaluate" an expression and can be used to manipulate variables.

Caboodle

Answer 5

The input function, which evaluates the given string and returns the result, has some restrictions, but still may be exploitable.

Chivers

Can confirm that it is exploitable. __import__('os').system('ls') Feeding in the above string in stdin, results in execution of ls command in shell. – Dysplasia

How exacly input function evaluates the given string? – Daft