The bit about python being somewhat of a security concern because already compromised systems have it preinstalled (and the hacker might use it) is an odd point.
Even if Python isn't there, Perl or PHP, or something else similarly flexible probably is. Or just curl and bash.
Edit: Regarding this: "So, what should be done about this? The Python core development community needs to acknowledge the problem; it is the reason that many corporate networks ban Python, for example"
I've never heard of this...is this actually common? If I've already compromised your system, I can install whatever I want...one way or the other. Even if that's pasting binaries via base64.
In particular, I don't understand why this would be a problem, since the exec would assumedly be run with the privileges and access of the user who ran python.
Some years ago security reviews asked whether you have removed all the C compilers from your production systems for similar reasons.
But now, even bash has an optional TCP socket support, or you might have netcat installed etc, assuming that what you can get executed is minimal in size and you need to fetch something from the Internet.
What's going on here is that Python is a powerful program, called a "deputy" in security parlance, which has some power that it can choose to delegate based on some policy. These sorts of attacks are called "confused deputy" attacks because they rely on tricking the deputy into misbehaving.
Admittedly, in the given examples, the attacks are not especially interesting, but that is because it is totally unsurprising that a Python interpreter might have this kind of power.
There are distros like NixOS where there is not a system Python preinstalled, this is due to NixOS following the Principle of Least Authority (POLA) and not putting powerful tools into standard paths automatically.
I do get the premise, it just seems like it adds little value. Even with POLA, I'm sure I could find some powerful tool on NixOS to use, or a way to bootstrap one.
Python is not (typically) a "powerful" program in the sense of a confused deputy; in runs with exactly the same powers as the user who runs it. If you want security, you need well defined security boundaries, not removing arbitrary programs that "seem" powerful.
Although this obviously isn't what GP meant, I had fun imagining what sort of ridiculous abuses of a system would result in python actually being a confused deputy. Making a python interpreter that is also a setuid binary for example.
Things like Python, bash, etc, when actively used make it harder to tell when unauthorized code is running, either via automated application whitelisting systems or more monitoring/hunting scenarios.
To developers, running arbitrary code is totally normal, but it makes securing developer systems particularly challenging, compared to the rest of a corporate network. I've never really met anyone who has a good answer for how to secure developer machines, the best that people usually manage is trying to make jumping from dev to prod as hard as possible.
Which sort of brings us back to the point: in a prod system, you only want to be running the code that is coming out of your repo & upstream, nothing else, having a python interpreter there makes that harder than a bash shell since bash still largely has to call other binaries to do things, especially after you disable bash sockets.
Just seems pointless to me. The chances that a production machine might have a jvm, Python, Perl, PHP, node.js, curl, wget, or just a database client like pgsql/mysql makes this pretty fruitless.
re: Jython.. it's just missing too much to be useful. Porting code to it is often a non-trivial exercise. multiprocessing is still missing which it turns out a number of libraries actually rely on to various degrees. http://bugs.jython.org/issue2287
I want to like it & use it, after all JRuby is an excellent example of what can be done. It's just every time I've tried, I've just found myself deep in the guts of various libraries trying to make it work.
14 comments
[ 2.9 ms ] story [ 51.0 ms ] threadEven if Python isn't there, Perl or PHP, or something else similarly flexible probably is. Or just curl and bash.
Edit: Regarding this: "So, what should be done about this? The Python core development community needs to acknowledge the problem; it is the reason that many corporate networks ban Python, for example"
I've never heard of this...is this actually common? If I've already compromised your system, I can install whatever I want...one way or the other. Even if that's pasting binaries via base64.
But now, even bash has an optional TCP socket support, or you might have netcat installed etc, assuming that what you can get executed is minimal in size and you need to fetch something from the Internet.
Admittedly, in the given examples, the attacks are not especially interesting, but that is because it is totally unsurprising that a Python interpreter might have this kind of power.
There are distros like NixOS where there is not a system Python preinstalled, this is due to NixOS following the Principle of Least Authority (POLA) and not putting powerful tools into standard paths automatically.
Things like Python, bash, etc, when actively used make it harder to tell when unauthorized code is running, either via automated application whitelisting systems or more monitoring/hunting scenarios.
To developers, running arbitrary code is totally normal, but it makes securing developer systems particularly challenging, compared to the rest of a corporate network. I've never really met anyone who has a good answer for how to secure developer machines, the best that people usually manage is trying to make jumping from dev to prod as hard as possible.
Which sort of brings us back to the point: in a prod system, you only want to be running the code that is coming out of your repo & upstream, nothing else, having a python interpreter there makes that harder than a bash shell since bash still largely has to call other binaries to do things, especially after you disable bash sockets.
And then you learn about bash loadable builtins and have a bad day ;-) (enable -f ...)
Some shops do have a policy to not use any Python software at all (usually excluding a bunch of other stuff as well).
I want to like it & use it, after all JRuby is an excellent example of what can be done. It's just every time I've tried, I've just found myself deep in the guts of various libraries trying to make it work.