Enabling Windows exploit mitigations by default in Rust programs?


Firefox and Chrome enable various Windows exploit mitigations using the HeapSetInformation and SetProcessMitigationPolicy APIs. Some of these mitigations may be useful (or at least harmless) for the Rust compiler to enable by default in Rust programs on Windows.

Is enabling these mitigations something the Rust team would consider?

While some of these “belt and suspenders” mitigations might not be necessary for safe Rust code, they could still protect against issues in unsafe Rust code, third-party C++ libraries, or third-party DLLs injected into the current process. In contrast, I believe Go programs do not enable ASLR/PIE by default.

Some of these mitigations could cause compatibility issues with existing Rust code (e.g. changing assumptions about the DLL search path) or third-party C++ code (e.g. that have “harmless” bugs such as passing an invalid or already closed HANDLE to CloseHandle).

Most of these mitigations can’t be disabled once enabled, so there would be no escape hatch if a Rust program needed to use a buggy third-party C++ library (in the same process).

Some example mitigations:

  • Use HeapEnableTerminationOnCorruption to terminate the process when Windows system heap corruption is detected.

  • Use SetDefaultDllDirectories to remove the current directory from the DLL search path.

  • Use SetProcessDEPPolicy to enable Data Execution Prevention (DEP) for 32-bit programs. It’s enabled by default in 64-bit programs.

  • Use ProcessASLRPolicy to harden the ASLR policy, such as forcing DLL relocations.

  • Use ProcessStrictHandleCheckPolicy to raise an exception when an invalid HANDLE is passed to a Windows API.

  • Use ProcessSystemCallDisablePolicy to disallow Win32k’s NTUser/GDI system calls.

  • Use ProcessExtensionPointDisablePolicy to disable legacy extension point DLLs.

… There are more but these are some basic mitigations that would probably not cause significant compatibility issues.


I believe there’s already issues open for some of these, though I’m on my phone and can’t search for them right now.

In general we are in favor of doing this kind of thing by default.


Most of these seem fine to have as defaults. Some will need escape hatches to build programs that need to intentionally not use them, such as programs that do need to make raw system calls.


Should I open GitHub issues for each suggested mitigation? I can provide links to documentation and example usage in Firefox, but I don’t think I will have time to write and submit patches myself.


I think that seems good, yeah. Don’t forget to search for duplicates first :slight_smile:


I filed issues for some of these proposed mitigations:

Here are some existing issues for other Windows exploit mitigations:

closed #7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.