On Thu, 15 Sep 2022, Alvin Wong wrote:
Hi,
On 14/9/2022 15:33, Martin Storsjö wrote:
+void __cdecl __attribute__((__noreturn__)) __stack_chk_fail(void) {
+ char msg[] = "*** stack smashing detected ***: terminated\n";
+ write(STDERR_FILENO, msg, strlen(msg));
+ abort();
+}
I have a feeling that calling `abort()` may not be the best thing to do
here. From what I recall, `abort` may call `_exit(3)` in some cases (or
perhaps some CRT combinations) and that causes DLLs to be unloaded and
global destructors to be run. In case of a stack smashing event, the
process memory has been corrupted so allowing arbitrary destructors to
run could be a security risk.
Right, that's clearly not ideal. I tested this - on UCRT, abort() doesn't
seem to run DLL destructors, while on msvcrt.dll, it does. So we should
indeed pick something else.
GCC's libssp calls a createive combo of __builtin_trap(), followed by an
explicit invalid write out of bounds, followed by _exit():
https://github.com/gcc-mirror/gcc/blob/releases/gcc-12.2.0/libssp/ssp.c#L158-L178
As we're free to use any Windows specific APIs here, I considered using
TerminateProcess() - but I preferred to avoid that as it's not available
for older Windows Store apps (targeting Windows 8.x iirc). (We do have a
fallback implementation of it for such older Windows Store builds in the
winstorecompat library, but there it only boils down to calling _exit().)
But since probably very few do care about those older Windows Store
targets at this point, maybe that's not that much of an issue any longer?
I think MSVC raises fail fast exceptions for all kinds of security
check failures including /GS buffer security checks. Perhaps the same
will be more appropriate here?
Hmm, I'm not very familiar with those APIs, can you give an example of
what that would look like?
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
