Open to using HeapEnableTerminationOnCorruption and SetProcessDEPPolicy?

[nmathewson]

Hi! Would you be open to adding the ability to restrict executable heap on Windows32 with SetProcessDEPPolicy, and to make heap errors fatal on Windows with HeapEnableTerminationOnCorruption? If so I can write the patch.

[niluxv]

Thank you for the suggestions! They look like valuable additions.

I have to admit that I'm not entirely into Windows, and I find the documentation rather sparse, so I hope I understand correctly what these functions do.

• HeapEnableTerminationOnCorruption: I'm not entirely sure what windows counts as heap corruption, but reading the remark in the documentation

  Setting the HeapEnableTerminateOnCorruption option is strongly recommended because it reduces an application's exposure to security exploits that take advantage of a corrupted heap.

  suggests that it would indeed be a good idea to set this.

• SetProcessDEPPolicy: According to the documentation

  If the system DEP policy is AlwaysOff or AlwaysOn, SetProcessDEPPolicy returns an error.

  , but it doesn't say which error code it gives, which is unfortunate since we'll want to ignore errors caused by an AlwaysOn system DEP configuration.

[niluxv]

The win32.rs internals file is currently a bit of a mess though. Probably not much fun writing a PR against it. If you aren't in a hurry I can try to clean it up a bit (which would hopefully make a PR easier), or implement this feature myself.

[nmathewson]

I have to admit that I'm not entirely into Windows, and I find the documentation rather sparse, so I hope I understand correctly what these functions do.

After some research, I think this might not actually be needed. If you agree with my findings below, please feel free to close this ticket.

My Windows understanding is... second-hand, so please take these explanations with a little skepticism.

First: the HeapEnableTerminationOnCorruption flag makes the process abort if the allocator finds corruption in the heap. It is on-by-default on 64-bit windows, and apparently on 32-bit executables if they are linked with subsystem version 6 or later. Supposedly, Rust always does that, so this one might not be necessary?

The glibc equivalent is mallopt(M_CHECK_ACTION, 1) in glibc, which is the default.

References:

• Enable HeapEnableTerminationOnCorruption for all Windows Rust programs rust-lang/rust#56054
• https://devblogs.microsoft.com/oldnewthing/20131227-00/?p=2243

Second: SetProcessDEPPolicy makes data segments non-executable, to make exploits harder to write. It's on by default on 64-bit windows, and needs to be enabled on 32-bit windows.

But it looks like Rust already merged a linker flag to do this:

• enable DEP on 32-bit Windows rust-lang/rust#16533

So it may be that there isn't anything to do here, unless we are concerned about the case where executables are being linked by something other than rustc.

If you agree, please feel free to close this ticket. Sorry there! I'll double-check what Rust does by default before opening any more tickets.

[niluxv]

Great. Thank you for the investigation!

unless we are concerned about the case where executables are being linked by something other than rustc.

I think this crate only makes sense for binaries for which the main function is written in Rust, since secmem_proc::harden_process is expected to be called as early as possible from main. So I think we can assume the compiler is rustc.