Bug 1003471: Python 1.5.2 security vulnerability still present in 2.3.4
That's the title of the report, but the hole was probably plugged since
Python 2.0. See corresponding checkin to PC/getpathp.c: a crucial
precondition for joinpath() was neither documented nor verified, and there
are so many callers with so many conditional paths that no "eyeball
analysis" is satisfactory. Now Python dies with a fatal error if the
precondition isn't satisfied, instead of allowing a buffer overrun.
NOT TESTED! The Windows version of the patch was, but not this one. I
don't feel like waiting for someone to notice the patch I attached to the
bug report. If it doesn't compile, sorry, but fix it <wink>. If it
does compile, it's "obviously correct".
diff --git a/Modules/getpath.c b/Modules/getpath.c
index 10ad509..418c683 100644
--- a/Modules/getpath.c
+++ b/Modules/getpath.c
@@ -190,10 +190,14 @@
}
-/* joinpath requires that any buffer argument passed to it has at
- least MAXPATHLEN + 1 bytes allocated. If this requirement is met,
- it guarantees that it will never overflow the buffer. If stuff
- is too long, buffer will contain a truncated copy of stuff.
+/* 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
joinpath(char *buffer, char *stuff)
@@ -206,6 +210,8 @@
if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN)
buffer[n++] = SEP;
}
+ if (n > MAXPATHLEN)
+ Py_FatalError("buffer overflow in getpath.c's joinpath()");
k = strlen(stuff);
if (n + k > MAXPATHLEN)
k = MAXPATHLEN - n;