Bugs item #871026, was opened at 2004-01-05 11:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_snprintf segfaults on missing native snprintf
Initial Comment:
On architectures missing a native snprintf (checked on
win32 + Borland), PyOS_snprintf may cause a segfault
when passed a string argument (%s) larger than 512 bytes.
Btw, allocating an extra 512 bytes and hoping for the
best while calling native vsprintf is also a security
risk (due to buffer overruns.)
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2006-01-10 17:54
Message:
Logged In: YES
user_id=31435
Indeed, nine months is long enough to make a baby, so
closing this as 3rdParty + WontFix.
----------------------------------------------------------------------
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 17:42
Message:
Logged In: YES
user_id=1188172
Another year passed (almost), so this can be closed?
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-03-21 23:26
Message:
Logged In: YES
user_id=31435
Nick, Python already uses _snprintf and _vsnprintf under
MSVC on Windows. The OP said he tried using Borland on
Windows, which presumably lacks them (Borland has its own
runtime libraries, and do note that these things are not part
of the Win32 API, they're part of the compiler-specific C
runtime library).
Since snprintf and vsnprintf are required by both POSIX and
the C99 standard, and are supplied (albeit with a goofy
spelling, and non-standard endcase behavior) by MSVC, the
number of platforms they're not available on is both small and
shrinking. I doubt any current Python developer uses such a
platform, so if the OP doesn't care enough to volunteer a
patch either, we should acknowledge reality and close this as
WontFix. (The OP could still ask Borland to modernize their C
offering, of course -- if Borland is falling behind the times, it's
not really Python's problem to write a modern C library for
them.)
----------------------------------------------------------------------
Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 22:39
Message:
Logged In: YES
user_id=430343
Win32 actually *does* have snprintf, but like most functions added to the
C standard later in life, it's implemented as _snprintf(). Really, it seems
that the autoconf rule needs to be smarter than just checking for
snprintf, but rather needs to redefine snprintf as _snprintf on platforms
that have _snprintf.
Of course, the implementation of PyOS_snprintf still needs fixing.
----------------------------------------------------------------------
Comment By: Federico Di Gregorio (fog)
Date: 2004-01-05 16:12
Message:
Logged In: YES
user_id=10245
Yes, it causes a segfault when a module using PyOS_snprintf
passes it a string that is bigger than the buffer length +
512. This happens because first vsprintf is called with a
too small buffer and the stack is corrupted and then (too
late!) there is the check and the fatal error.
Py_FatalError is called (maybe) but the return address is
gone from the stack and all you get is a segfault at the end
of the function.
I know PyOS_snprintf is internal but it can be used by
extension modules and (anyway) growing a buffer 512 bytes
statically is almost the same as using sprintf (without the
'n') directly.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-01-05 12:01
Message:
Logged In: YES
user_id=31435
Does it really cause a segfault? This code is trying to cause
Py_FatalError instead in that case:
else if ((size_t)len >= size + 512)
Py_FatalError("Buffer overflow in
PyOS_snprintf/PyOS_vsnprintf");
If that part isn't working, that is indeed a bug.
WRT security, PyOS_snprintf is an internal API function --
programs written in Python can't invoke it directly. If a
(necessarily) internal use of the function triggers this case,
that's an error in the coding of the internals, but the *intent*
is that Py_FatalError() get invoked then anyway, which
immediately kills the Python process (via C abort()).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
