From 8484fbf0f6cd2bc5fd5a5cd4d04797734e9121fc Mon Sep 17 00:00:00 2001 From: Tim Peters Date: Sat, 7 Aug 2004 19:12:27 +0000 Subject: 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). --- PC/getpathp.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/PC/getpathp.c b/PC/getpathp.c index 7c87da8..ecde205 100644 --- 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; -- cgit v0.12