2 messages in org.python.python-bugs-list[ python-Bugs-871026 ] PyOS_snprintf ...
FromSent OnAttachments
SourceForge.netMar 21, 2004 10:39 pm 
SourceForge.netMar 21, 2004 11:26 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[ python-Bugs-871026 ] PyOS_snprintf segfaults on missing native snprintfActions...
From:SourceForge.net (nore@sourceforge.net)
Date:Mar 21, 2004 10:39:33 pm
List:org.python.python-bugs-list

Bugs item #871026, was opened at 2004-01-05 11:37 Message generated for change (Comment added) made by mondragon 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.)

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

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

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