The module search path is constructed from PYTHONPATH env-var, then zip path, then HKCU PythonPath, then HKLM PythonPath, then PYTHONPATH define (in pyconfig.h), and finally argv[0]. If PYTHONHOME is available, the PYTHONPATH define is expanded. These paths are separated by semicolon.

Without PYTHONHOME, PYTHONPATH define is appended to module_search_path as-is, and a semicolon comes **after** that. With PYTHONHOME, PYTHONPATH define is expanded, and there is no semicolon after it. Then, finally, when argv[0] is added to module_search_path, a semicolon is **prepended** before it.

This inconsistency in handling path delimiter leads to a case where two semicolons are next to each other (;;), which is translated to the current directory. It happens when PYTHONHOME is not found. The current directory is put in front of the application directory (argv[0]) causing a security issue whereby external modules might be imported inadvertently.

This patch makes semicolon handling consistent. A semicolon is appended at the end of every path component, except argv[0].

Barry, Benjamin, do you agree that this is a security issue as far as future 2.6 and 3.1 security fix releases are concerned?

I'm not Barry or Benjamin, but having followed the thread on psrt@python.org, this certainly looks like a security issue to me. As a second pair of eyes, I recommend MvL, who builds our Windows installers.

Approved for 3.1 as far as I'm concerned.

Brian, you marked this 'patch review', bypassing 'test needed'. Should this have any visible effect at the Python level that can be tested?

The first chunk of that patch is for when pythonhome==NULL.  There is also a similar block just under it when MS_WINDOWS is not defined.  While I don't know in which cases this will be built without that define, it looks as though the *buf++ = DELIM; should also be added to that block?

Also, there is an existing conditional:
     if (argv0_path) {

which can never be false (as argv0_path is a char array).  It could be changed to if (argv0_path[0]) but ISTM that it could also be removed completely - ie, the 2 lines left in that block should have no effect in the case where the buffer is empty.

I haven't actually tested it though, but apart from the first comment above, it *looks* like it does the right thing :)

If this is a security issue shouldn't it have been actioned?  If not does the type move to behaviour or what?

Hum, it would be nice to have a unit test for this change.

The patch is three parts that adds one line, moves one line and deletes one line.  I've checked 2.6, 2.7, 3.2, 3.3, 3.4 and default.  In all cases the second part has already been implemented, the first and third have not.  Assuming that these changes must still be done, do we also need additional unit tests?

Steve, is this bug still relevant and a security problem?

This code has been significantly rewritten since this bug, and I believe it's no longer an issue.

stage: patch review -> resolved

messages: + msg277327

assignee: steve.dower