26

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?

Community
  • 1
  • 1
rook
  • 66,304
  • 38
  • 162
  • 239
  • 6
    How about making this a community wiki? – Sven Marnach Nov 17 '10 at 17:56
  • @Sven Marnach how would that make this better? I haven't done that before. – rook Nov 17 '10 at 18:03
  • 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. – Katriel Nov 17 '10 at 18:20
  • @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. – rook Nov 17 '10 at 18:23
  • 2
    @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. – Sven Marnach Nov 17 '10 at 20:25
  • 1
    @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. – rook Nov 17 '10 at 21:11

5 Answers5

14

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.

nmichaels
  • 49,466
  • 12
  • 107
  • 135
  • 2
    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. – S.Lott Nov 17 '10 at 18:21
  • 2
    @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. – nmichaels Nov 17 '10 at 18:43
  • "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. – S.Lott Nov 17 '10 at 19:46
  • @S.Lott: Fair enough. Better? – nmichaels Nov 17 '10 at 20:30
14

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.
admalledd
  • 428
  • 3
  • 11
  • 1
    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. – detly Nov 27 '10 at 07:04
10

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.

dietbuddha
  • 8,556
  • 1
  • 30
  • 34
6

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.

rook
  • 66,304
  • 38
  • 162
  • 239
3

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

khachik
  • 28,112
  • 9
  • 59
  • 94
  • 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. – gtux Sep 04 '17 at 13:07
  • How exacly input function evaluates the given string? – Ekrem Dinçel Dec 13 '20 at 17:23