Python for Windows Extensions Privacy Concern
It was recently pointed out on comp.lang.python that there is a privacy issue in the ActiveScripting support in the Python for Windows extensions.
About the problem
The basic issue is that the contents of your hard disk could be read by an arbitrary web page. These pages are not capable of modifying the contents of your disk, but almost any file on the disk can be read.
It is extremely unlikely that anyone would use this for any kind of privacy invasion. The total number of computers with these extensions installed is so tiny compared to the number of web browsers that no useful information would be able to be gathered. The chances of hitting a user with Python installed is negligible.
That said, it is a hole worth closing.
Who is affected?
If you have simply installed the core Python for windows (for example, from www.python.org) and have not installed either win32all or ActivePython, then you are not at risk.
If you are not affected (see above) then you need do nothing. Otherwise perform one of the following:
To verify that your installation no longer has this issue, first
shutdown all instances of Internet Explorer, then open
What will later versions do?
Builds later than win32all-142 use a slightly different strategy. There are two ActiveScripting engines supplied - one that supports untrusted code, and one that does not. By default, only the one that does not support untrusted code is registered. This means that Python will continue to work in all trusted environments (eg, IIS/ASP, WSH, etc) but will refuse to work in untrusted environments (such as IE).
If a user desires, they may manually register the version that supports untrusted environments. Once registered, IE will be able to use Python in the exact same way it could before - meaning this privacy issue still exists once this version is registered.
How did it happen?
The ActiveScripting engine in Python, when used by IE, uses the "rexec" module to restrict what the code can do - Python's closest thing to a "sandbox". This rexec module does prevent file writes etc, but allows file reads - it uses a "safety" model rather than a "privacy" model.
After some discussion, it was decided that even if this particular hole was closed, there may be others waiting to appear; the Python rexec module has simply not had enough critical analysis to trust in this environment. Hence we came up with the solution outlined above.
[Wed Jul 27 08:02:53 2005 GMT+10]