-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gcc: DEP and ASLR not enabled by default #6674
Comments
mingw-w64 gcc environment has many reputation of being flagged by anti virus programs. Search "mingw-w64 virus alert" and you will get many related issues. The alerts are mainly false positive which may not be related to disabled DEP and ASLR. |
@Biswa96 Unfortunately in this case I believe this is not a false positive as I can't see these flags in any of the binaries. |
Last time I looked gcc didn't support DEP and ASLR by default, maybe that has changed in the meantime. I'd certainly welcome it. |
@lazka support was added in gcc 10.1.0, it's indeed disabled by default (i'm not sure why) |
@salowenh because various LD versions had problem with it. |
Also gobject-introspection has problems with it, try enabling it and then watch what happens heh. |
btw you can also pretty much forget using PCH if you enable ASLR and DEP they are incompatible as is. |
https://sourceware.org/bugzilla/show_bug.cgi?id=19011 I have no idea about GCC, but they're just flags on the PE file, controlled by the linker (ld). I actually looked at this a bit. You can turn the options on by default in a gcc spec file, but there is no corresponding negative option to turn them back off on a case-by-case basis. peflags.exe in the rebase package comes in handy in that case 😉 |
@jeremyd2019 we can add flags in https://github.com/msys2/MSYS2-packages/blob/master/pacman/makepkg_mingw64.conf |
I've uncommented the LDFLAGS stuff and built ninja as a test: Before:
After:
Looks like the last remaining upstream changes (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=dc9bd8c92af67947db44b3cb428c050259b15cd0) are in binutils 2.34, which we have. Should we try enabling this by default? What about 32 bit? |
Everything but high entropy va should work on 32-bit as well. MS tools actually let you set highentropyva on 32-bit modules, but ld doesn't, and I don't think it means anything there. |
gtk3 works, python (which uses pgo/lto) segfaults at link time. |
We should upgrade to binutils 2.35 first. |
I wonder if @revelator meant PGO rather than PCH in that comment. I was scratching my head how these would break precompiled headers, but now that you saw they broke profile-guided optimization it makes perfect sense why that could be a problem. |
Another option to consider adding to those that were commented out in makepkg_mingw64.conf would be to set the image base above 2^32. This appears to be the default for -cygwin (or -msys in this patch). Unfortunately, the default base for exes and dlls is supposed to be different, and it isn't known when setting LDFLAGS which is being built. |
@jeremyd2019 appropriate bases for executables and libraries have to be set in those lines: https://github.com/bminor/binutils-gdb/blob/d262797294039fc828e36f76c45e462966c5c72a/ld/emultempl/pep.em#L102 |
The last time this was tried also mentions PCH: 2602139#diff-c8386c579acf251c791f3c68b4d22e65 |
I was wondering why nobody had a patch for that binutils bug in all this time. 😕 Well, I finished mine and added to the bug in any event, maybe save the next guy some confusion. |
Are you relating to the base address bug? can you please share how to apply it when compiling with mingw? |
The base address was just one part of this. https://sourceware.org/bugzilla/show_bug.cgi?id=19011 has my two patches, one to provide options to turn off dll characteristics flags, and a second one to change the defaults. This second one does change the default on x86_64 to use base addresses greater than 2^32, using the same variation that was already in place for cygwin/msys. They could be applied in the PKGBUILD for binutils if desired. It sounds though like this might open a can of worms. |
Ah, GCC puts pointers in their PCH output, so can't use it if gcc's base address changed. Sounds like this is a problem for everyone... https://bugzilla.redhat.com/show_bug.cgi?id=1721553#c34 |
If it still fails with 2.35 then there must be some other Binutils bug. |
for the python segfault, only |
So, as far as I understand, one way forward would be:
edit: |
This sets image base to special ones used by Cygwin. If we are going to change it then we should patch BFD to use the same address as MSVC and LLD. Then try if Python still crashes. |
(I don't know how any of this works, so I don't understand the details.. as for python, to clarify, the linking process crashes, not python) edit: ah, I see, that options is for cygwin, which uses other default addresses. |
I didn't see a need to --disable-auto-image-base - I don't think it would hurt anything if ASLR is enabled, and could be helpful if something needs to disable ASLR (though I guess they could re-enable it if they needed to) |
I didn't notice this, thanks. I guess I should update my patch to do this too. 0x1 4000 0000 for EXEs and 0x1 8000 0000 for DLLs? That kind of makes move_default_addr_high a misnomer 😁 |
@jeremyd2019 this might be the same issue as in #6932 (comment) |
Could be. I have no idea what GCC does. |
Finally fixed my compiler back to its original state (not easy), basically i had to build a gcc-4.9.2 cross compiler first to bootstrap gcc-9.3.0 with TDM's patches, this turned up some interresting things that basically means i cannot ever hope to use aslr as long as i use the TDM based patchset. TDM uses sortof a hack to get shared memory pointers to allow throwing exceptions across dll boundaries even if linked to the static runtimes. Sadly this mechanism changes libgcc's internals as the code wraps certain calls and is therefore no longer wholly compatible with main unmodified gcc (example some libgcc internals wraps with an _shmem prefix). non aslr executables and libraries are still useable with normal mingw-w64-gcc though. |
I knew there was something odd about your env 😀 3rd party patches that I'm not seeing... |
Well the idea was nice if it had worked, codeblocks still uses the TDM compilers to create executables that are as close to the windows environment as possible without having to rely on the gcc runtime for anything but internals. And my build environment was pretty much based around codeblocks with msys2 as a package manager for a TDM based build. Besides my mingw64 environment being different by using sjlj exceptions my msys2 also uses a slightly different and some might say outdated sgml docbook format based around openjade because it plays nicer with latex (more tested). In fact i can build any doc format for any package. Aslr would have been a nice addition but as you seen it wont work with my environment, dep is still solid though it probably wont keep pesky AV solutions quiet. |
Hmm with the latest binutils i can build gcc if i disable gnat, if i dont disable it the gnat tool binaries will segfault. |
The current state of affairs in the mingw-w64-binutils package is that all of the options (higher image base, dynamicbase, etc) are disabled by default, and are enabled in makepkg_mingw{32,64}.conf for packages. |
Aye i noticed, it also works fine with my compiler if i disable the hardening flags but enabling it causes some packages to fail building like clang / gcc etc. |
Damn it was the shared memory patch that breaks aslr :/ after removing it gcc builds with aslr on with no problem. |
Hmm the default flags in makepkg-mingw* breaks building clang (unknown linker flag --default-image-base-high) which causes anything after clang itself to fail building with an error since ldd seems to not know this flag (maybe relegate this flag to PKGBUILD untill ldd supports it or atleast ignores it). gcc seems to work fine after i removed the shared memory patch though it also seems to have gone a bit wonky on reliably building some packages (btw why was plugin support disabled ? it works here). |
LLD doesn't understand that option, I'll open PR with upgrade to version 11 and fix for that flag later today/tomorrow. |
Sounds good :) |
@revelator I think there are different makepkg config files for clang. @mati865 I never did send the patch adding that flag upstream to binutils. I had hoped it was just a temporary workaround while we got the bugs ironed out. |
@jeremyd2019 I don't plan to upstream LLD patch either. |
Hmm but if i use the makepkg config files for clang does it even build ? seing as there is no compiler present by default in the clang dirs. I could symlink gcc to the clang dirs to get the compile going and remove the symlinks afterwards before installing clang if that is what is intended. I understand it might just have been a temporary solution, and its quite easy to get around if unsetting LDFLAGS in the PKGBUILD script just before clang takes over compiling libc++ libc++abi libunwind etc. then set LDFLAGS to the same hardening options minus the problematic flag. What im not clear on is does lld push the base address high by default on 64 bit builds ?. Here is what i do ->
|
sounds reasonable. I believe that @mati865 said that was the default in lld. You could verify an executable/dll's base with |
Well if it is the default behaviour of ldd i guess im safe. |
codelite plugins seem to not like it to much -> terminate called after throwing an instance of 'wxSQLite3Exception' |
still having problems with gobject-introspection also, non zero return error. Fixed TDM's shared memory patch, turned out it was an error on my part as the function needs to have exceptions disabled, i got wise some time back and changed the way it normally disabled exceptions by using #pragma GCC optimize "no-exceptions" unfortunatly while this works i forgot to reset it for the rest of the libgcc build. |
--nxcompat works for gobject-introspection --dynamicbase does not ugh... and while gcc now builds i found out that it is broken even with the fix to exceptions so i had to remove the shared memory patch for now. It seems to work somewhat reliable without it but i guess problems might crop up downhill. added LDFLAGS+=" -Wl,--disable-dynamicbase" to gobject-introspection and a whole ballpark of other packages that rely on it so no aslr for these but atleast i get DEP support. I have a feeling that it will newer work fully with statically linked runtimes like my version of gcc defaults to so i can either bite the apple and just revert the TDM changes or i will have to live with some packages that wont have ASLR. |
Btw. ld from binutils-2.35.1 reports two instances of some features.
|
...doh i forgot the 64 bit binutils supports both targets forget the above. |
DEP and ASLR are enabled by default for some time now. |
The libgsf is flagged by tools such as BinSkim due to apparently not enabled safe exception handlers, DEP and ASLR security options.
Any thoughts on how to create a more secure compilation?
The text was updated successfully, but these errors were encountered: