Hi,
By default, the gcc generated PE binaries do not appear to have
directory entry #11, a.k.a 'Load Configuration', whereas MSVC generated
ones do:
$ objdump -x mingw/rufus.exe | grep "Load Configuration"
Entry a 0000000000000000 00000000 Load Configuration Directory
$ objdump -x vs2022/rufus.exe | grep "Load Configuration"
Entry a 00000000000e6f90 00000140 Load Configuration Directory
Now, per
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-load-configuration-structure-image-only,
the Load Configuration entry has a *very desirable* flag one can set to
mitigate the DLL side-loading scourge, called 'DependentLoadFlags' (also
documented at
https://learn.microsoft.com/en-us/cpp/build/reference/dependentloadflag).
When set to 0x800, this tells Windows to only load DLLs from system32
directory only, and disregard anything from the executable/current dir
(and, unlike the SetDllDirectory/SetDefaultDllDirectories API calls, the
flag is actually honoured at point during the life of the runtime that
doesn't render it utterly worthless).
Considering that the current approach to fighting DLL side-loading
vulnerabilities for MinGW generated executables is to manually run them
through something like procmon, to see if they attempt to load DLLs from
nonsystem dirs, and if so, manually apply delay-loading to the DLLs
(that is when delay-loading works, because while I didn't have an issue
with other DLLs --outside of binutils needing an annoying
DECLSPEC_IMPORT redef-- I have been entirely unable to make it work with
cfgmgr32 [1]), being able to use a simple flag that tells Windows: "Hey,
this application is designed to *not* to ever need to load anything but
system DLLs" would be a real godsend.
However, applying that flag requires the GNU PE toolchain that can
generate a 'Load Configuration' PE directory entry, and arbitrarily set
some the attributes there. And from what I can see, while LLVM has
recently introduced an option that adds such a section to set the
relevant flag, I don't expect gcc to do so anytime soon, so I would very
much like a workaround for it...
Unsurprisingly, this topic is far too advanced for ChatGPT to produce
anything useful. I am therefore asking the MinGW experts if they have a
solution for this kind of additional PE entry generation.
Thank you,
/Pete
[1]
https://github.com/pbatard/rufus/commit/622e60659cb0c7c3e69f5255c0e99127eed0ada6
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
