New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
collections.namedtuple does questionable things when passed questionable arguments #66031
Comments
Code such as this: class Foo:
def __str__(self):
# Perhaps this value comes from user input, or
# some other unsafe source
return something_untrusted
def isidentifier(self):
# Perhaps it returns false in some esoteric case
# which we don't care about. Assume developer
# did not know about str.isidentifier() and
# the name clash is accidental.
return True
...may result in arbitrary code execution. Since the collections documentation does not say that such things can happen, this could result in highly obscure security vulnerabilities. The easiest fix is to simply call str() on the typename argument to namedtuple(), as is currently done with the field_names argument. But IMHO this is like cleaning up an SQL injection with string sanitizing, instead of just switching to prepared statements. The "switch to prepared statements" route is conveniently available as a rejected patch for bpo-3974. The above code will not work as such in Python 2.7, but more elaborate shenanigans can fool the sanitizing in that version as well. This issue was originally reported on security@python.org, where I was advised to file a bug report normally. |
IMO we should rewrite the implementation of namedtuple to avoid completly eval(). But there is the problem of the _source attribute: bpo-19640. |
ISTM that in order to run you code, a person already has to have the ability to run arbitrary code. The purpose of the existing checks was to support the use-case where the field names are taken from the header line of CSV files. I would be happy to add a test for exact string inputs but will not throw-out the current design which has a number of advantages including the ability to keep just the generated code and throw-away the factory function itself. |
New changeset 30063f97a44d by Raymond Hettinger in branch '2.7': |
I'll add the 3.4 and 3.5 as well plus a Misc/NEWS item shortly. |
New changeset c238d2899d47 by Raymond Hettinger in branch '3.4': New changeset 5c60dd518182 by Raymond Hettinger in branch '3.4': |
New changeset 958e8bebda6d by Raymond Hettinger in branch '3.4': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: