configparser v/s file variables
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Thu Jun 28 03:46:24 EDT 2018
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
More information about the Python-list
mailing list