New submission from Kevin Norris:
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
collections.namedtuple(Foo(), ())
...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
issue 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 secur...@python.org, where I was advised
to file a bug report normally.
----------
components: Library (Lib)
messages: 221394
nosy: Kevin.Norris
priority: normal
severity: normal
status: open
title: collections.namedtuple does questionable things when passed questionable
arguments
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21832>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
