Bug#990496: gcc-mingw-w64-x86-64-win32-runtime: libgcc_s_seh-1.dll built without NX and without ASLR
Hi Stephen, On 2021-06-30 21:18, Stephen Kitt wrote: On Wed, 30 Jun 2021 19:37:18 +0200, Tim Kosse ~$ x86_64-w64-mingw32-objdump -p /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libgcc_s_seh-1.dll | grep DllCharacteristics DllCharacteristics 0160 Not quite: the DLLs were built with those flags set, but they weren’t built 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. 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. IMAGE_DLLCHARACTERISTICS_NX_COMPAT, IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE and IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA These libraries should be built with both mitigations enabled. I agree, at least those options which make sense for DLLs, but it’s still not straightforward. 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/ Ideally, support for this should come from upstream (GCC and MinGW-w64), not just the Debian packages. 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
Bug#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 Version: 10.2.1-6+24.2 Severity: important X-Debbugs-Cc: tim.ko...@filezilla-project.org 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 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 0160 According to https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32, 0160 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 -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/32 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages gcc-mingw-w64-x86-64-win32-runtime depends on: ii gcc-mingw-w64-base 10.2.1-6+24.2 gcc-mingw-w64-x86-64-win32-runtime recommends no packages. gcc-mingw-w64-x86-64-win32-runtime suggests no packages. -- no debconf information
Bug#990496: gcc-mingw-w64-x86-64-win32-runtime: libgcc_s_seh-1.dll built without NX and without ASLR
Hi Tim, On Wed, 30 Jun 2021 19:37:18 +0200, Tim Kosse wrote: > 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 > > 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 0160 Not quite: the DLLs were built with those flags set, but they weren’t built 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. > According to > https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32, > > 0160 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. 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 pgpLgp09v8JH3.pgp Description: OpenPGP digital signature
