Workaround for Mandatory ASLR

[conioh]

The Git for Windows binaries don't work with ASLR because of the way cygwin/Mingw/MSYS/whatever implements fork. This is unfortunate, but ain't gonna change anytime soon (as per #1196 etc.).

However, running with Mandatory ASLR enabled may be useful or desired as part of computer hardening.

A (sad) workaround is to add exceptions to the system policy and exempt the Git binaries from ASLR.

Doing that through the GUI is crazy as there are 444 such EXEs. The PowerShell Set-ProcessMitigation cmdlet doesn't support using full paths; it would exempt any process with a given name. The two options left are preparing an XML of an undocumented but easily understandable schema and importing it using Set-ProcessMitigation -PolicyFilePath or editing the Registry manually.

The following is a PowerShell script that directly manipulates the Registry and adds exceptions for all the EXE files inside the Git directory except the 3 found at the root: https://gitlab.com/conio.h/GfW_ASLR_Exceptions

It expects a path to the Git directory (e.g. "C:\Program Files\Git") and looks for the git install directory in the Registry if no path is provided. The path parameter can be used for "portable git" installs.

There's virtually no error checking there. I have no idea what happens if you gives a bad path, for example. What I can say is that "it works on my computer" (RS3 x64, if anybody cares).

[dscho]

Interesting.

Are you sure that you have to exclude all .exe files, not just the ones under usr/?

[conioh]

No. I only have to exclude those who have relocations and aren't marked ASLR-ready.
If they're marked ASLR-ready there's no reason to exempt them from ASLR and if they don't have relocations ASLR is irrelevant anyway.

Maybe such binaries are only found under usr/, but as I wrote here - I got a few error messages when I launched git-bash and added exceptions for the binaries there, and then used another git command and got a bunch more, so I went on with a broad strike.

I just didn't get to it, and it wasn't that important at the moment. I just needed Git to work so I did the minimum that worked for me at the moment.

(I also wanted something that works on a clean machine, so I didn't have Python and pefile to use. I later found some PowerShell packages on GitHub that parse PE files, but didn't get to it yet. Of course, if you incorporate something like this into the GfW installer you won't have those limitations. Or you can know in advance which binaries require exemptions and which don't and generate a list of files to exempt as part of the GfW build process.)

[dscho]

Or you can know in advance which binaries require exemptions

Indeed. I know that pretty precisely because the fork() emulation is provided by usr\bin\msys-2.0.dll, and by convention all .exe files relying explicitly or implicitly on that emulation are in the usr directory tree.

In fact, it is even safe to assume that the opposite is true, too: all .exe files found in the usr directory tree link to msys-2.0.dll. That is by design, because the usr directory tree holds so-called "MSYS programs" which link to msys-2.0.dll implicitly (read: you do not have to say so explicitly when linking with usr\bin\gcc.exe).

This means that all of the .exe files in the mingw64 directory tree (or on 32-bit systems, the mingw32 one) do not link to msys-2.0.dll, and since that is the only .dll in Git for Windows (as far as I know) that is not ASLR-ready, they should not be exempt.

In fact, Git's own executables (mingw64\bin\git*.exe and mingw64\libexec\git-core\*.exe) are marked specifically to use ASLR, even without Mandatory ASLR.

And yes, I think the best place for doing essentially what your Powershell script does would be the installer, as opt-in.

Interested? It should be a fun ride.

Step 1: install Git for Windows' SDK

https://git-for-windows.github.io/#download-sdk

It will run for a while, download ~200MB of MSYS2's packages, and build a current Git.

Step 2: build an installer

This should be as easy as calling /usr/src/build-extra/installer/release.sh 0-test in Git for Windows' SDK's Bash (the git-bash.exe at the top-level directory where you installed your SDK).

Step 3: change the installer

Probably the best place would be to add it as a "component". See e.g. how the "autoupdate" feature works: https://github.com/git-for-windows/build-extra/blob/af9cff50050b15520a8a3885ccfb6c9b4b65611b/installer/install.iss#L105

You will want to add the exceptions around the same place the autoupdater is installed: https://github.com/git-for-windows/build-extra/blob/af9cff50050b15520a8a3885ccfb6c9b4b65611b/installer/install.iss#L2101-L2106

And remove those exceptions around the same place the autoupdater is uninstalled: https://github.com/git-for-windows/build-extra/blob/af9cff50050b15520a8a3885ccfb6c9b4b65611b/installer/install.iss#L2347-L2352

You can set registry values by imitating how Git for Windows' installer registers the Explorer integration: https://github.com/git-for-windows/build-extra/blob/af9cff50050b15520a8a3885ccfb6c9b4b65611b/installer/install.iss#L2040-L2054

You can enumerate files in a directory using FindFirst()/FindNext()/FindClose() just like we do when trying to hard-link the .dll files into libexec: https://github.com/git-for-windows/build-extra/blob/af9cff50050b15520a8a3885ccfb6c9b4b65611b/installer/install.iss#L1671-L1682

And you can extend this to a recursive search by handing FILE_ATTRIBUTE_DIRECTORY: https://github.com/git-for-windows/build-extra/blob/af9cff50050b15520a8a3885ccfb6c9b4b65611b/installer/install.iss#L1674

Finally, the top-level directory with which to start is the usr directory of the installed Git for Windows: ExpandConstant('{app}\usr').

Step 4: build and test a custom installer

This is really important, to verify that it worked: /usr/src/build-extra/installer/release.sh 0-test. This will overwrite the file in your home directory which was generated in step 2, and that's okay.

Step 5: open a Pull Request

... and I'll merge it as soon as possible. And then I'll celebrate!

[conioh]

... and by convention all .exe files relying explicitly or implicitly on that emulation are in the usr directory tree.

That's good to know. I'll take a look at implementing this when I could spare a little bit more time.

[dori4n]

Hello,

Please, and I must reiterate, do not automatically deactivate, disable, or otherwise circumvent security options users or administrators have set up.

Also @conioh, please be aware, that the proper method to enable system-wide ASLR is to set the following registry options:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"MitigationOptions"=hex:11,11,11,00,00,00,00,00,00,00,00,00,00,00,00,00

To properly enforce DEP, you would run bcdedit /set {current} nx alwayson at an elevated command prompt.
You will need to reboot the computer for both settings to be correctly applied.

If you have done that, using exclusion rules is not possible, and applications cannot opt-out of image relocation or execute disable bit protections.
As mentioned in #1374 (comment) the --dynamicbase compile option is broken in MinGW. Relevant issues: https://sourceforge.net/p/mingw-w64/mailman/message/31034877/, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836365, bitcoin/bitcoin#8248, and this StackOverflow question: https://stackoverflow.com/questions/24283918/

[dscho]

@NightmareJoker2 you would have a ton more credibility if you would not have claimed to be able to fix Perl with regards to ASLR "in less than 5 minutes", without ever backing up such a strong claim with anything substantial.

I am not saying that your statements are incorrect. I am saying that I doubt them, based on how past claims held up in bright daylight.

[dori4n]

@dscho I did not claim "fixing it" would take me five minutes. I said in #1196 (comment), and I quote: "[I] could send in a pull request [of what I already have] in less than 5 minutes, if I wanted to".
That said, you can read the material I have referenced yourself, verify it, and do not need to put any trust in my words. In fact, I don't want you to. If you think carefully about this, you will understand why I take that position.
What I have referenced in the last paragraph will help you with your existing toolchain, but I would still strongly advocate, since you are targeting Windows, and considering the project name, are focusing on it, that you switch to one with better platform support. It will help you long-term. If you do however for some reason need cross-platform build support, I'd suggest to look into CMake or similar abstractions. Based on how much effort you are convinced this would take, I'd prefer you do it yourself and learn from it, rather than have it done for you. Even if you don't like me saying that, it will only make you a better programmer in the end.

[dscho]

Yes, all of this makes me trust those claims even less. Now you are suggesting to switch to CMake. Seriously.

[dscho]

@conioh let's get back on track and just ignore the distraction, okay? Please feel free to reach out if anything in my write-up is unclear (or does not work as advertised).

And thank you for offering to contribute!

[dori4n]

Yes, all of this makes me trust those claims even less.

You are not supposed to trust me, you are supposed to verify them for yourself. That is the whole point of the exercise. I want you to learn something rather than take what I say at face value.

Now you are suggesting to switch to CMake. Seriously.

What is the problem with that? Using CMake or a similar build system abstraction layer gets you binaries built with the native tools and is easy to integrate with a continuous integration system that tells you about build errors on any targeted platform for each commit and pull request, if you so choose. You can even automate creation and tear-down of the build VM or container. Of course you can also tackle the problem of fixing the MinGW compiler, but I'd wager that to be a challenging endeavor, if nobody considered it in over 7 years. Quite possibly, also, because switching the toolset is so much easier, especially thanks to standardization of the programming language.

For the last time:
Compile with -Wl,--nxcompat,--dynamicbase,--export-all-symbols,--high-entropy-va and -Wl,--image-base,0x140000000 for dynamic libraries and -Wl,--image-base,0x180000000 for executables. Please stop saying this is difficult. Doing so only does two things, neither of them favorable to you.

[dscho]

1. Writing about the benefits of CMake without any consideration of the costs is just uninformed. Please stop suggesting it without even converting a single project (you would not tout that horn if you had done that; I have).
2. The MinGW compiler has no problem. If you want to be taken seriously about your claims, you have to get the facts right.
3. Passing compiler flags is not difficult. That's child's play. But it is not as easy as you say because it is not a matter of simply passing compiler flags. Again, you are just proving even further how uninformed you are about the matter you claim to understand.

And the worst part is: this here ticket is not in need of distractions like the one provided by you. It is just wasting time and good will. So let's stop here.

[dori4n]

Writing about the benefits of CMake without any consideration of the costs is just uninformed. Please stop suggesting it without even converting a single project (you would not tout that horn if you had done that; I have).

You are pretending to know something you cannot possibly have any knowledge about. You know how the saying goes: "If you assume..." (I'll stop there)

The MinGW compiler has no problem. If you want to be taken seriously about your claims, you have to get the facts right.

It does have several problems. The people from the VideoLAN, Rust, or Bitcoin projects can sing you songs about it. If you feel what I say is incorrect, point it out, detail your issue and render proof of error and I will correct it for future use. You are more likely than not, reading something into my words, that is simply not there, or focusing on an irrelevant detail that has next to no relation to the problem at hand.

Passing compiler flags is not difficult. That's child's play. But it is not as easy as you say because it is not a matter of simply passing compiler flags.

Well, do it then, because you currently aren't. Your makefile does not mention them, and the manner in which you are compiling right now causes MinGW to not emit or to emit an incorrect relocation table.

Microsoft (R) COFF/PE Dumper Version 14.11.25508.2
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:\Program Files\Git\bin\git.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
            8664 machine (x64)
               C number of sections
               0 time date stamp
               0 file pointer to symbol table
               0 number of symbols
              F0 size of optional header
             22E characteristics
                   Executable
                   Line numbers stripped
                   Symbols stripped
                   Application can handle large (>2GB) addresses
                   Debug information stripped
OPTIONAL HEADER VALUES
             20B magic # (PE32+)
            2.28 linker version
            3800 size of code
            7600 size of initialized data
           60C00 size of uninitialized data
            1510 entry point (0000000000401510)
            1000 base of code
          400000 image base (0000000000400000 to 0000000000470FFF)
            1000 section alignment
             200 file alignment
            4.00 operating system version
            0.00 image version
            5.02 subsystem version
               0 Win32 version
           71000 size of image
             400 size of headers
           14B04 checksum
               3 subsystem (Windows CUI)
             140 DLL characteristics
                   Dynamic base
                   NX compatible

This is clearly not a binary that was compiled and linked with the flags I mentioned. It is probable, that the Dynamic base and NX compatible have been added manually later or simply added by the dumpbin tool, because it was a 64-bit binary and it is assumed that these options are present, because they are mandatory (the NX compatible is at least).

Again, you are just proving even further how uninformed you are about the matter you claim to understand.

Much rather, you have proven to me, how little you care, how you can't read the information given to you or choose not to, and how you appear to rather turn off security so developers can work with the tool, and go on their merry way of ignoring it in their own applications, too, because they don't notice it missing. This is not okay, Sir.

And the worst part is: this here ticket is not in need of distractions like the one provided by you. It is just wasting time and good will. So let's stop here.

No, the worst part is, you don't even understand yourself what the actual issue is. You have started to propose, that someone create security exception rules for your application and install those by default for all users of your application, when that is precisely what the users or system administrators who manage the systems your application gets installed onto do not want, and you are able, with relative ease, to make most parts (short of those relying on Perl or external Cygwin bits) of the applications work by adjusting linker flags during compilation, which aren't set by default. So, call this a "distraction" all you want, but for as long as you are planning on compromising security or suggest to your users they do it for you, especially that of others, even though that is more work than not to, "distract you" I must. Anything else would be feigning ignorance and utterly irresponsible.
I really want to give you the benefit of the doubt here, but I am starting to get the impression you are doing this out of malice now.