A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2014-September/136474.html below:

[Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

[Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSXSteven D'Aprano steve at pearwood.info
Fri Sep 26 01:40:17 CEST 2014
On Fri, Sep 26, 2014 at 12:17:46AM +0200, Antoine Pitrou wrote:
> On Thu, 25 Sep 2014 13:00:16 -0700
> Bob Hanson <d2mp1a9 at newsguy.com> wrote:
> > Critical bash vulnerability CVE-2014-6271 may affect Python on
> > *n*x and OSX:
[...]

See also:

http://adminlogs.info/2014/09/25/again-bash-cve-2014-7169/


> Fortunately, Python's subprocess has its `shell` argument default to
> False. However, `os.system` invokes the shell implicitly and is
> therefore a possible attack vector.

Perhaps I'm missing something, but aren't there easier ways to attack 
os.system than the bash env vulnerability? If I'm accepting and running 
arbitrary strings from an untrusted user, there's no need for them to go 
to the trouble of feeding me:

"env x='() { :;}; echo gotcha'  bash -c 'echo do something useful'"

when they can just feed me:

"echo gotcha"

In other words, os.system is *already* an attack vector, unless you only 
use it with trusted strings. I don't think the bash env vulnerability 
adds to the attack surface.

Have I missed something?



-- 
Steven
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4