Re: Re: CVE request: python-gnupg before 0.3.5 shell injection

[Simon McVittie <smcv () debian org>]

On 09/02/14 21:40, cve-assign () mitre org wrote:
> First, it seems that the shell_quote function in version 0.3.5 has
> two fundamentally different problems with different flaw types and 
> different discoverers.

I think the underlying problem here is that a library for interacting
with GNUPG from Python is trying to implement Unix shell escaping.
Unix shell escaping is subtle and easy to get wrong, so libraries
whose intended scope does not include "miscellaneous OS/runtime
utilities" should be delegating this to a better-tested and
better-audited implementation.

If possible, the preferred way to start a subprocess should be without
going via /bin/sh: in Python, using functions from the subprocess
module, without using the argument shell=True, achieves this. This is
analogous to posix_spawn() (or fork()/exec()) in plain C,
g_spawn_[a]sync() in GLib and so on.

If python-gnupg really does need to go via a shell, analogous to
system() in plain C or g_spawn_command_line_[a]sync() in GLib, then it
should use a library function analogous to GLib's g_shell_quote().

Python's shlex.quote() seems ideal for this, but unfortunately it's
new in version 3.3. Python 2.7 does document pipes.quote(), and the
documentation indicates that pipes.quote() may have been
present-but-undocumented in previous versions.

As a worst case, as much as I hate to encourage embedded code copies,
copying the implementation of shlex.quote() or pipes.quote() seems
likely to yield better results than reimplementing it.

    S