DLLs and executables with no exception handlers need to be marked with
IMAGE_DLL_CHARACTERISTICS_NO_SEH, even if they have a load config.
Discovered here when building Chromium with LLD on Windows:
https://crbug.com/833951
Differential D45778
[COFF] Mark images with no exception handlers for /safeseh rnk on Apr 18 2018, 10:39 AM. Authored by
Details DLLs and executables with no exception handlers need to be marked with Discovered here when building Chromium with LLD on Windows:
Diff Detail
Event TimelineComment Actions @mstorsjo will this be a problem for mingw? Does the mingw CRT provide a load config for each image? This could be an undesirable behavior change if mingw does not provide a load config, and the user links in a 32-bit object file that has exception handlers that they don't actually need for program correctness, but now the DLL is marked as not using safe SEH. Comment Actions I have no idea what a load config is - what should I look for and where?
Fwiw, no mingw setups use SEH for exceptions on i386 so far - it's only used on x86_64. On i386, it's either dwarf or sjlj. What effect does it have if a DLL is marked as not using safe SEH? Comment Actions If it also lacks a load config, it is more easily expoitable. If a DLL doesn't have a IMAGE_LOAD_CONFIG_DIRECTORY64 and it doesn't have the "no SEH" flag set, then any address in that DLL can be used as an exception handler. For 32-bit, exception handler function pointers are stored on the stack, so only a stack buffer overrun followed by an exception is needed to start an exploit chain. After thinking that through, I think we should adjust the check to always add the "no SEH" flag if there is no load config. That's the safe thing to do.
Comment Actions
|
Maybe we should move these conditions to createSEHTable and make it a Config member (such as Config->SEH?)