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

Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None 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.)

----------------------------------------------------------------------

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()).

----------------------------------------------------------------------