On Wed, 27 Jun 2018 16:09:09 -0700, Jim Lee wrote: > On 06/27/18 15:19, Steven D'Aprano wrote: >> On Wed, 27 Jun 2018 12:15:23 -0700, Jim Lee wrote: >> >>> It seems a bit silly to me to worry about arbitrary code >>> execution in >>> an interpreted language like Python whose default runtime execution >>> method is to parse the source code directly. An attacker would be far >>> more likely to simply modify the source to achieve his ends rather >>> than try to inject a payload externally. >> Spoken like a single user on a single-user machine who has >> administrator privileges and can write to anything anywhere. >> >> >> > ...which is exactly the case I was trying to illustrate. Another is the > elevation of privileges (in a multi-user environment) due to any of a > number of methods. The point is that the source code exists in the > execution environment, and once one gains access to that code, one > doesn't *need* anything else.
o_O Yes, attacks by trusted insiders are the hardest to defend against. Betrayal of trust sucks. Trusted users with sufficient privileges could just modify the source code of your application or of Python itself. They could also attack your system in a thousand different ways. But what about untrusted users with fewer privileges? They *can't* modify the source code of your application, or change the password on other accounts, or read arbitrary files, or masquerade as other users. Because they have unprivileged accounts. So why give them the ability to escalate their privilege to that of your application (which probably can do lots of things they can't do) by directly executing Python code they supply? Your argument is akin to: "I gave my partner a key to my house, and they could rob me blind if they want. Since I trust them not to, there's no point in locking the door to the house when I go out, since they have a key." -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
