[issue33515] subprocess.Popen on a Windows batch file always acts as if shell=True

[Eryk Sun]

Change by Eryk Sun :


--
stage: patch review -> 
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33515] subprocess.Popen on a Windows batch file always acts as if shell=True

[Sergey G. Brester]

Change by Sergey G. Brester :


--
keywords: +patch
pull_requests: +8375
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33515] subprocess.Popen on a Windows batch file always acts as if shell=True

[Eryk Sun]

Eryk Sun  added the comment:

There's no simple workaround for this behavior. All we can reasonably do is 
document that running a batch script directly has the same security risks as 
using shell=True. 

CMD doesn't support a file argument. It only supports running a /c or /k 
command, which can include running multiple commands joined by the &, &&, or || 
operators. CreateProcess thus executes a .bat or .cmd script by prepending 
"%ComSpec% /c" to the command line. If %ComSpec% isn't defined, it defaults to 
"%SystemRoot%\System32\cmd.exe /c".

Environment variables in a command can be escaped in most cases by inserting 
the "^" escape character after the first "%" character. This disrupts matching 
the variable name (unless a variable name happens to start with "^"). The 
escape character itself gets skipped as long as it isn't quoted literally.

--
assignee:  -> docs@python
components: +Documentation
keywords: +security_issue
nosy: +docs@python, eryksun
stage:  -> needs patch
versions: +Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33515] subprocess.Popen on a Windows batch file always acts as if shell=True

[Abigail]

New submission from Abigail :

It's possible to invoke an application without interpreting any of its 
arguments as shell magic:

>>> print(subprocess.check_output(["C:/testapplication.exe", "foo", "&&", 
>>> "echo", "%PROGRAMFILES%"]))
Hello world from application! 5 arguments:
Argument 0: 'C:/testapplication.exe'
Argument 1: 'foo'
Argument 2: '&&'
Argument 3: 'echo'
Argument 4: '%PROGRAMFILES%'

But not so for batch scripts:

>>> print(subprocess.check_output(["C:/testscript.bat", "foo", "&&", "echo", 
>>> "%PROGRAMFILES%"]))
Hello world from script! 2 arguments:
Argument 0: 'C:/testscript.bat'
Argument 1: 'foo'
C:\Program Files

I don't know if this is a fundamental limitation of Windows' batch script 
processing, or of the Win32 CreateProcess API, but this looks exploitable, as 
it allows shell injection: the subprocess docs warn about shell injection in a 
big red box, and promise you'll be safe if you a list of arguments and the 
default shell=False.

Tested on Python 2.7.15 and Python 3.6.5.

--
components: Library (Lib), Windows
messages: 316638
nosy: abigail, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess.Popen on a Windows batch file always acts as if shell=True
type: security
versions: Python 2.7, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com