x86 binaries not compiled with common security flags

[JiriH01]

We tried to use x86 libopenblas.dll (v0.3.13 and v0.3.10) in our project. However, no version is compiled with the following security flags, see the errors from BinSkim below

libopenblas.dll: error BA2009: 'libopenblas.dll' is not marked as DYNAMICBASE. This means that the binary is not eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. To resolve this issue, configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later.

\libopenblas.dll: error BA2016: 'libopenblas.dll' is not marked NX compatible. The NXCompat bit, also known as "Data Execution Prevention" (DEP) or "Execute Disable" (XD), is a processor feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit, because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment. To resolve this issue, ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker.

libopenblas.dll: error BA2018: 'libopenblas.dll' is an x86 binary which does not contain a load configuration table, indicating that it does not enable the SafeSEH mitigation. SafeSEH makes it more difficult to exploit memory corruption vulnerabilities that can overwrite SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64.

Would it be possible to get compiled x86 dll with these flags set?

[martin-frbg]

The current Windows binaries are cross-compiled with mingw on Linux, I'll need to look into which if any of these settings are available in that context. Alternatively, it may be possible to set them as needed on the compiled library with the editbin utility.

[TiborGY]

The current Windows binaries are cross-compiled with mingw on Linux, I'll need to look into which if any of these settings are available in that context. Alternatively, it may be possible to set them as needed on the compiled library with the editbin utility.

I am not sure if editbin-ing these flags on is safe.

[brada4]

Does editbin work to change header flag ? It is safe to use, OpenBLAS works nicely when Linux disrtibutions build with their runtime hardening standard, including best ASLR they have.

[martin-frbg]

I see editbin recommended in various contexts, at least for changing the DYNAMICBASE and NXCOMPAT flags (though its most common use appears to be for changing the default stacksize or enabling 3GB address space on x86). SAFESEH would appear to be outside the capabilities of this tool due to the extra table requirement, and it may not even be available in gcc/mingw (or its ld). (Possibly it is available in very recent llvm)

[brada4]

It kind of works, thensome say not. https://github.com/msys2/MINGW-packages/issues/6682

SEH is C++ thing, similar to LAPACK XERBLA in its function, OpenBLAS is fully compatible because it will not catch C++ exception due to C++ code absence. Should it really be linked in C and Fortran library where it is never hit from? That is if outer program has safeseh (mprotect on exception handler?) does it maintain SEH block safety while in dependent libraries?

[martin-frbg]

As I understand it, the issue with SAFESEH is that the VS linker rejects a library without this property (even if irrelevant) unless SAFESEH is disabled on the entire project (?)

[brada4]

Says nolinking problem, but somebody has to measure, next page SEHOP says does almost same without linker flags already. REF: p28+ https://www.cs.bu.edu/~goldbe/teaching/HW55813/vulNmit.pdf

Almost all BLAS API calls take result array as a pointer, it will attempt to overwrite any location in visible memory space, not specifically SEH, or stack or anything unsafe. Would be hard to get predictable x86 code there after float calculations, but not impossible.

I dont know if we should add all parametritis every linux package ever added, and every other windows guide tells to do at once. If it was so good and worked so well it would be made compiler default since inception.