#990496 gcc-mingw-w64-x86-64-win32-runtime: libgcc_s_seh-1.dll built without NX and without ASLR

Package:
gcc-mingw-w64-x86-64-win32-runtime
Source:
gcc-mingw-w64
Description:
GNU Compiler Collection for MinGW-w64, x86-64/win32
Submitter:
Tim Kosse
Date:
2021-07-01 09:33:02 UTC
Severity:
important
#990496#5
Date:
2021-06-30 17:37:18 UTC
From:
To:
Dear Maintainer,

I have noticed that libgcc_s_seh-1.dll as distributed by this package
has not been built with support for the NX and ASLR security features
enabled, as can be see with objdump:

~$ x86_64-w64-mingw32-objdump -p
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libgcc_s_seh-1.dll  | grep
DllCharacteristics
DllCharacteristics      00000000

It looks like the other .dlls in this package are also missing these
important flags. I have not checked whether this affects the
corresponding package with the 32bit DLLs.

This is a regression from buster, where this file is built with support
for both features:

~$ x86_64-w64-mingw32-objdump -p
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libgcc_s_seh-1.dll  | grep
DllCharacteristics
DllCharacteristics      00000160

According to
https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32,
00000160 decomposes into
IMAGE_DLLCHARACTERISTICS_NX_COMPAT,
IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE and
IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA

These libraries should be built with both mitigations enabled.

Regards,
Tim Kosse

#990496#10
Date:
2021-06-30 19:18:52 UTC
From:
To:
Hi Tim,
with support for the features — as a result, in many cases the protection
features were unusable and even misleading. See
https://www.kb.cert.org/vuls/id/307144/ and the links therein for details.

I agree, at least those options which make sense for DLLs, but it’s still not
straightforward. Ideally, support for this should come from upstream (GCC and
MinGW-w64), not just the Debian packages.

Regards,

Stephen

#990496#15
Date:
2021-07-01 08:46:14 UTC
From:
To:
Hi Stephen,

Doesn't this issue only affect executables with a missing relocation
table? As such it would only apply to .exe files, as .dlls normally have
relocation tables. In any case, this is completely unrelated to NX.

The solution seems to be there already in the binutils-mingw-w64 package
of Bullseye, simply replacing disable-flags.patch with
default-secure-pe-flags.patch suffices.

With the rebuilt binutils, .exe files by default include relocations and
ASLR works well[*]. You originally disabled the patch in light of this
vulnerability, even though the .exe files linked with it are not
affected by it.

This behavior is different in Buster's binutils-mingw-w6 though, there
the relocations are missing in .exe files.


[*] The icing on top would be a >4GB default image base for some extra
entropy, as explained in
https://msrc-blog.microsoft.com/2013/12/11/software-defense-mitigating-common-exploitation-techniques/

According to https://sourceware.org/bugzilla/show_bug.cgi?id=19011#c14
this is being worked on upstream. At least the toolchain currently
distributed through msys2 uses ALSR/NX by default for all .exe and .dlls
built with it.

Regards,
Tim