This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author josh.r
Recipients 18z, bigbigliang, christian.heimes, josh.r, krnick, serhiy.storchaka, vstinner, xtreak
Date 2019-04-02.16:52:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1554223936.06.0.754158021206.issue36506@roundup.psfhosted.org>
In-reply-to
Content
I'll note that, based on the title, I'm skeptical of the claim of a vulnerability. getattr is effectively *designed* to execute arbitrary code if called on an appropriate object (one where the class defines __getattribute__; defines __getattr__ without defining the name in question; defines the name in question as a property, not an instance attribute; or does something complicated with metaclasses that achieves a similar result looking up the attribute on the class).

In all of those cases, the "vulnerability" only exists if:

1. The object in question defines a vulnerable handler for the attribute (that is, provides a code path for arbitrary execution that Python's attribute lookup machinery wasn't responsible for except insofar as it passed control to the unsafe handler in question)
2. Untrusted user input is passed as the name to look up on the vulnerable object

If it's something more subtle than that (e.g. something where a "plain" instance with no special execution path supports arbitrary execution), that's an issue, but if it requires a Python developer to both create the vulnerability and open a path to trigger it explicitly, that doesn't really count.
History
Date User Action Args
2019-04-02 16:52:16josh.rsetrecipients: + josh.r, vstinner, christian.heimes, serhiy.storchaka, 18z, xtreak, krnick, bigbigliang
2019-04-02 16:52:16josh.rsetmessageid: <1554223936.06.0.754158021206.issue36506@roundup.psfhosted.org>
2019-04-02 16:52:16josh.rlinkissue36506 messages
2019-04-02 16:52:15josh.rcreate