There are a number of issues that ld has on mingw-w64 (or otherwise targeting mingw-w64). Most of them stem from the fact that ld's defaults for mingw-w64 targets are terrible and unfortunately most or all of these settings have security implications. I would like this thread to be a consolidation of any previous threads that may have reported a subset of these issues.
Put simply, for mingw-w64 targets (32 and 64-bit) binutil's ld should do the following:
- Default to enabling dynamicbase and nxcompat.
- Never strip the reloc section.
- Default to enabling HEASLR (high-entropy-va)
- Use a base address > 4GB for 64-bit binaries.
- Default to disable-auto-image-base
All of the above will bring binaries created with gcc/ld in line with what's produced by msvc (visual studio/Microsoft's compiler/linker). Any compatibility issues caused by these changes should be acceptably small and msvc has been defaulting to all of these since they were brought about in VS2008 (yes 2008 for dynamicbase and nxcompat).
Going through the list in a little more detail, dynamicbase and nxcompat is universally safe for mingw-w64 targets (and only mingw-w64 targets on windows) and should cause no compatibility issues at all. Furthermore if you specify dynamicbase it should automatically cause the linker to output a reloc section (or not strip it or however it works internally). Otherwise you get weird stuff like this where another option is being invented for the wrong reasons. There's no reason for this option because ld should never be stripping the reloc section from executables in the first place (or perhaps better logic should be if you specify dynamicbase it should just have the reloc section, no reason to split this into another option).
Defaulting to HEASLR is also a no brainer. It's ignored on targets which don't support it. Specifying a base address > 4GB is a compatibility single to the loader that there are no "latent pointer truncation issues" and it can use extra entropy (8 -> 17 bits) for the base address randomization.
Executables should have a base address of 0x140000000 and dll's should use
All of the above ties into my last point of switching the default to --disable-auto-image-base. Thanks to ASLR there's no reason to be generating random image base's anymore for mingw-w64 binaries.
The above should bring binaries produced with ld in line with what Microsoft's linker uses and is way more sane than what's currently used so we don't have to use a million workarounds in order to get something sane.  is especially hilarious.
Is it possible for you to produce a consolidated patch that addresses all of these issues ?
I am all in favour of these changes unless someone has strenuous objections - and I seriously doubt that anyone will. But it will make my life easier if I only have one patch to test instead of 5.
I don't mind having a go but I'm unfamiliar with the binutils/ld source so I'll have to figure out where everything is first.
On that note are you (or anyone who might be able to help) on irc?
Sorry - I am not on IRC, but do feel free to email me direct.
Created attachment 11152 [details]
Don't strip reloc sections when building with dynamicbase
This should address the "- Never strip the reloc section." part.
The attached patch fixes the IMAGE_FILE_RELOCS_STRIPPED bit to be set in the headers when no symbol is exported, when building with -Wl,--dynamicbase.
Please let me know if some corrections are to be made!
AFAIU I need to explicitly state that I'm ok with the copyright being assigned to the FSF, so I'm ok with it.
Well, apparently the attached fixes the header, but makes windows fail to run the resulting executable, so I guess something's missing.
Any help would be appreciated!
This is a big drive-by, as I don't have much understanding on the details of the problem; but Tor uses the following patch to add a relocation section so Windows builds of Tor Browser can have ASLR: https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/binutils/enable-reloc-section-ld.patch
Googling for "mingw-w64 aslr" turned up a CERT vulnerability note for this issue along with CVE-2018-5392. It wasn't apparent from the VN or the CVE whether or not Sourceware had been notified of the CVE assignment.