[Bug ld/19011] New: Issues with ld on mingw-w64 and bad defaults

[theryuu at warpsharp dot info]

https://sourceware.org/bugzilla/show_bug.cgi?id=19011

            Bug ID: 19011
           Summary: Issues with ld on mingw-w64 and bad defaults
           Product: binutils
           Version: 2.25
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: theryuu at warpsharp dot info
  Target Milestone: ---

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[1] 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[2].
Executables should have a base address of 0x140000000 and dll's should use 
0x180000000.

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[3][4][5].  [3] is
especially hilarious.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17321
[2]
http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx
[3]
https://github.com/TheRyuu/FFmpeg/commit/91b668acd6decec0a6f8d20bf56e2644f96adcb9
[4]
https://github.com/TheRyuu/FFmpeg/commit/f2b805d02ee12af5593130ef06f0924422e8622e
[5]
https://github.com/TheRyuu/FFmpeg/commit/ae4e2e6cc32541ce19a716136995d605a723ac5e

-- 
You are receiving this mail because:
You are on the CC list for the bug.