SF bug 1003471: Python 1.5.2 security vulnerability

This was probably fixed in rev 1.32 of getpath.c, but there are so
many paths thru the code that invoke joinpath() it's not at all
obvious that it *is* fixed.  It doesn't help confidence that a crucial
precondition for calling joinpath() was neither documented nor verified.
It is now, and joinpath() will barf with a fatal error now rather than
overrun the buffer, if the precondition isn't met.

Note that this patch only changes the Windows flavor.  I attached another
patch to the bug report for the POSIX flavor (which I can't test
conveniently).

diff --git a/PC/getpathp.c b/PC/getpathp.c
index 7c87da85481880d8ff7a1c7c5b48f6d216e32ea9..ecde205b53ea1a6cfbb4ec75fa89fc2262ff2039 100644 (file)
--- a/PC/getpathp.c
+++ b/PC/getpathp.c
@@ -133,7 +133,15 @@ ismodule(char *filename)   /* Is module -- check for .pyc/.pyo too */
        return 0;
 }
 
-/* guarantees buffer will never overflow MAXPATHLEN+1 bytes */
+/* Add a path component, by appending stuff to buffer.
+   buffer must have at least MAXPATHLEN + 1 bytes allocated, and contain a
+   NUL-terminated string with no more than MAXPATHLEN characters (not counting
+   the trailing NUL).  It's a fatal error if it contains a string longer than
+   that (callers must be careful!).  If these requirements are met, it's
+   guaranteed that buffer will still be a NUL-terminated string with no more
+   than MAXPATHLEN characters at exit.  If stuff is too long, only as much of
+   stuff as fits will be appended.
+*/
 static void
 join(char *buffer, char *stuff)
 {
@@ -145,6 +153,8 @@ join(char *buffer, char *stuff)
                if (n > 0 && !is_sep(buffer[n-1]) && n < MAXPATHLEN)
                        buffer[n++] = SEP;
        }
+       if (n > MAXPATHLEN)
+               Py_FatalError("buffer overflow in getpathp.c's joinpath()");
        k = strlen(stuff);
        if (n + k > MAXPATHLEN)
                k = MAXPATHLEN - n;