The security descriptors of python binaries in Windows are not strict enough

[kindloaf]

BPO	5802
Nosy	@ezio-melotti, @bitdancer, @briancurtin, @florentx
Superseder	bpo-1284316: Win32: Security problem with default installation directory

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2010-03-01.15:45:54.587>
created_at = <Date 2009-04-20.16:42:29.890>
labels = ['type-security', 'OS-windows']
title = 'The security descriptors of python binaries in Windows are not strict enough'
updated_at = <Date 2010-03-03.04:42:55.431>
user = 'https://bugs.python.org/kindloaf'

bugs.python.org fields:

activity = <Date 2010-03-03.04:42:55.431>
actor = 'kindloaf'
assignee = 'none'
closed = True
closed_date = <Date 2010-03-01.15:45:54.587>
closer = 'brian.curtin'
components = ['Windows']
creation = <Date 2009-04-20.16:42:29.890>
creator = 'kindloaf'
dependencies = []
files = []
hgrepos = []
issue_num = 5802
keywords = []
message_count = 7.0
messages = ['86201', '99038', '99047', '100219', '100257', '100288', '100332']
nosy_count = 5.0
nosy_names = ['ezio.melotti', 'r.david.murray', 'brian.curtin', 'kindloaf', 'flox']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'test needed'
status = 'closed'
superseder = '1284316'
type = 'security'
url = 'https://bugs.python.org/issue5802'
versions = ['Python 2.6']

[kindloaf]

The security descriptors of python binaries (like python.exe,
pythonw.exe, etc) allow any Authenticated Users to modify these
binaries. This may cause a privilege-escalation problem since
administrators may use python binaries when performing administrative
tasks. A normal unprivileged user may turn a python binary into a
trojan and acquire administrator's sids.

Test environment: windows vista, python 2.6

[kindloaf]

Thanks for the reply. I can log in as a non-admin user and replace
python.exe with another binary. Does that serve as an attack example?

Hong

On Sun, Feb 7, 2010 at 7:14 PM, Brian Curtin <report@bugs.python.org> wrote:

Changes by Brian Curtin <curtin@acm.org>:

----------
stage:  -> test needed

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue5802\>

---

[briancurtin]

Is the situation any different if you install Python to "C:\Program Files"? This seems to be at least part of the reason IronPython installs to "C:\Program Files", which was discussed on the IronPython list [1] a few months ago.

[1] http://lists.ironpython.com/pipermail/users-ironpython.com/2009-October/011345.html

[kindloaf]

Sorry for the delay, it's been a busy month.

I just tried python 3.1 If installed under c:\program files, the
access control list would be correct, only system & administrator
accounts get the modify privilege.

The default installation is to c:\python31, in which the access
control list has the issue that unprivileged users can modify it.

I guess a possible remedy to this is that after installation, the
setup program can just remove "authenticated users" from the access
control list, or at least remove the "modify" privilege from the
corresponding entry.

Thanks,
Hong

On Mon, Feb 8, 2010 at 7:23 AM, Brian Curtin <report@bugs.python.org> wrote:

Brian Curtin <curtin@acm.org> added the comment:

Is the situation any different if you install Python to "C:\Program Files"? This seems to be at least part of the reason IronPython installs to "C:\Program Files", which was discussed on the IronPython list [1] a few months ago.

[1] http://lists.ironpython.com/pipermail/users-ironpython.com/2009-October/011345.html

----------
nosy: +brian.curtin

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue5802\>

---

[briancurtin]

Even if we changed the ACL of the executable, any user could still add malicious code to be executed on import, as the C:\PythonXY directory doesn't require specific privileges for writing to it, and it shouldn't by default. When installed to "C:\Program Files", certain privileges are required to install anything, so regular users can't install third party code or swap out the interpreter.

If you need the added security, you are more than welcome to choose to install Python to a more secure location. Defaulting to "C:\Program Files" isn't necessary.

See also: issues bpo-1074873 and bpo-818030

[bitdancer]

See also bpo-1284316, which is still open, and should probably remain open even though there's no consensus to make a change (yet?).

[kindloaf]

Sure. Thank you for the information!

Hong

On Tue, Mar 2, 2010 at 4:26 AM, R. David Murray <report@bugs.python.org> wrote:

R. David Murray <rdmurray@bitdance.com> added the comment:

See also bpo-1284316, which is still open, and should probably remain open even though there's no consensus to make a change (yet?).

----------
nosy: +ezio.melotti, flox, r.david.murray
priority:  -> normal
superseder:  -> Win32: Security problem with default installation directory

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue5802\>

---