Pali Rohár recently raised an issue regarding snprintf() and he pointed
out a valid concern. The MinGW toolchain has been silently redirecting
snprintf() to the MSFT-specific non-conforming _snprintf(). This
creates a substantial security risk for any application compiled using
MinGW. When a developer uses snprintf() he assumes that it will not
write outside the bounds of his buffer *and* it will NUL terminate the
string that gets written there. The MSFT-specific _snprintf() does not
make that guarantee. It does not NUL terminate the string if it gets
truncated due to insufficient space. Subsequent use of a string that is
not NUL terminated results in incorrect program behavior at best and a
security hole at worst. There is a reason MSFT requires callers to use
an underscore prefix and subverting that is harmful. This impacts code
written specifically for MinGW and it also impacts code that is ported
from another environment that may otherwise be perfectly secure.
I don't think there is any doubt that something needs to be done to fix
this. Pali submitted a patch that continues to use _snprintf but checks
the result and writes the necessary NUL terminator when truncation
occurs. That fixes the security hole. He also added a call to
_vscprintf to calculate the required buffer size after truncation and
uses that to fix the return value (_snprintf returns -1 on truncation).
The latter change raises a new issue because _vscprintf is not present
in the VC6 C-runtime library. The VC6 APIs are the only ones in
msvcrt.dll that we can rely on according to these blogs:
https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=1273
https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/
The VC6 APIs in msvcrt.dll are safe to use because applications compiled
using VC6 and earlier rely on them. MSFT can't remove those APIs or
make backwards incompatible changes to them or it will break those
applications. All APIs added to msvcrt.dll after VC6, however, were
intended for internal use by Windows itself. That includes _vscprintf.
Those APIs can be removed or altered by MSFT at any time. If MinGW uses
them every application compiled with MinGW is at risk of breaking every
time a Windows Update occurs.
There has been some discussion about this in the #mingw-w64 IRC channel
but I think we should open this up to a broader audience here to make
sure everyone gets a chance to weigh in and to make sure we do the right
thing.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
