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".
This commit is contained in:
Tim Peters 2004-08-08 01:00:47 +00:00
parent 95334a5d1e
commit ec8c5a9311

View file

@ -190,10 +190,14 @@ isdir(char *filename) /* Is directory */
}
/* 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 @@ joinpath(char *buffer, char *stuff)
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;