Dne 22. 2. 2020 v 19:22 Dan Raymond napsal(a): > I don't think there is any doubt that something needs to be done to fix this. >
+1 Although I hope that any solution would still allow apps to explicly choose the MSVCRTL.DLL if the app knows what it does. It may be written with that runtime in mind. > 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. There are also other incompatibilities: - "%I64" (MSVCRT.DLL) versus "%lld" (standardized in C99; possibly supported in newer MSVCRT.DLL versions but AFAIK not in the old ones). - Or "%S" (MSVCRT.DLL) versus "%ws" (standard) (https://devblogs.microsoft.com/oldnewthing/20190830-00/?p=102823) (And possibly more.) I can imagine that use of those might also possibly have security implications. Consider what happens when _snprintf() skips what it sees as an invalid specifier. That may cause a shift in interpretation of the arguments and e.g. cause dereferencing an argument which is actually not a pointer. Also note this hits all the functions from the printf family. BR, Martin Mitas _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
