This issue was raised first on security@python.org. Guido responded that not sensitive enough to be kept to the list and that okay to log a bug report.

This issue may not warrant any action except perhaps an update to
documentation for the logging module to warn about it, but thought
that should raise it just in case someone felt it needed actual code
changes to be made to avoid the issue if possible.

The problem arises in the Python logging modules ability to create a
listener socket which can accept new configuration in the ini file
format.

http://docs.python.org/library/logging.config.html#logging.config.listen

"""To send a configuration to the socket, read in the configuration
file and send it to the socket as a string of bytes preceded by a
four-byte length string packed in binary using struct.pack('>L',
n)."""

This sounds innocuous and the documentation at that point doesn't warn
that you are opening yourself up to security problems in using it.

You get a hint of potential issues later if one reads later
documentation about the file format:

"""The class entry indicates the handler’s class (as determined by
eval() in the logging package’s namespace). The level is interpreted
as for loggers, and NOTSET is taken to mean ‘log everything’."""

There are other mentions about eval() in context of log level and args
for the handler class as well, but not sure that is used for log level
as it says.

The combination of the open listener port for configuration and that
processing of the configuration file uses eval(), means that one could
send a configuration file to the process containing:

[handler_consoleHandler]
class=os.system('echo security issue') or StreamHandler
level=DEBUG
formatter=simpleFormatter
args=(sys.stdout,)

and one could execute an arbitrary command as the user the process runs as.

The problem is tempered by the fact that someone has to enable the
feature, which is likely rare, but also because socket connections to
send new configuration will only be accepted from the same host
('localhost') and the host can not be overridden. So can only be taken
advantage of by someone (potentially a different user) on the same
host and not remotely at least.

The specific code in Python 3.2 is:

        section = cp["handler_%s" % hand]
        klass = section["class"]
        fmt = section.get("formatter", "")
        try:
            klass = eval(klass, vars(logging))
        except (AttributeError, NameError):
            klass = _resolve(klass)
        args = section["args"]
        args = eval(args, vars(logging))
        h = klass(*args)

and older Python 2.X versions have similar code.

Although you could perhaps avoid need for eval for class lookup, can't
see that you could do that for args unless you restrict it to literal
values and use a more limited eval like parser.

At the minimum there probably should be a warning in the documentation about using the logging module configuration port on untrusted systems with shared users.

ast.literal_eval() is a good choice for limited evaluation of Python string as it only supports data types like numbers, str, dict etc. but no classes or function calls.

I think it is sufficient for 2.7, 3.2 and 3.3 to just update the documentation, as Graham says, using "note" markup so that it stands out.

I can look at ast.literal_eval as an option for 3.4.

New changeset f30b49a5072e by Vinay Sajip in branch '2.7':
Issue #15445: Updated logging configuration documentation to highlight potential security risk posed by listen() in certain scenarios.
http://hg.python.org/cpython/rev/f30b49a5072e

New changeset e5d7d202f2bf by Vinay Sajip in branch '3.2':
Issue #15445: Updated logging configuration documentation to highlight potential security risk posed by listen() in certain scenarios.
http://hg.python.org/cpython/rev/e5d7d202f2bf

New changeset 410be02de1c6 by Vinay Sajip in branch 'default':
Closes #15445: Merged documentation update from 3.2.
http://hg.python.org/cpython/rev/410be02de1c6