> There is a privacy leak problem in many Python implementations > for Windows which allow a malicious Web page or HTML email message > to read the contents of file from a user's hard drive and send the > contents back to a Web site. The problem occurs in Windows Python > implementations that supports Python as a scripting language for Web > pages in Internet Explorer. Specifically, the problem seems to be in the AXScript package, which is bundled with Pythonwin and win32com. > The problem exists because the Python runtime library does not > consider file read operations to be a security risk. File read > operations are allowed to execute on a Web page without restriction. > File write operations, on the other hand, are blocked. I'm not an expert, but this package uses the RExec restricted execution facilities that are in the Python core modules. RExec was designed to allow filesystem read operations, but not write operations, as outlined explicitly in the documentation. I think RExec was intended for more general restricted execution, where filesystem reads might be acceptable, although that's debatable - my RExec systems certainly disable it. Since it's generally accepted that Web browser applets shouldn't be able to access the filesystem, I think the problem is with the AXScript package, which should have removed all access to the os module. AXScript actually uses a subclass of the RExec class called AXRExec in order to add an extra module and the mechanics of the ActiveX scripting system (not sure how it works). > This directory listing example is available online to test to see > if a particular computer system is vulnerable to the problem or not: > > http://www.computerbytesman.com/privacy/pythondirdemo.htm > > To fix this privacy leak, the Python runtime library should block > all file operations when Python code is being used on a Web page, > not just file write operations. I disabled this example by adding the following line to pyscript.py, line 413: ok_posix_names = () This simply removes all access to the os module, as I stated above. I don't know what all this might break, since I don't do much with AXScript, but a couple of the demos still seemed to work normally, so I don't think the change would break any of AXScript's internal mechanics. Just a quick, amateur analysis, -A Linux: The ultimate video game.
