Mitigation-page

MID-004: Memory Hardening Against Code Injection

Mitigation Tier: Foundational

Description

Mechanisms to protect memory against code injection include restricting what parts of memory can execute code and randomizing address space to prevent the development of effective exploits.

Executable Space Protection and Write xor Execute (W^X) should be used to restrict what code can be executed in memory. Executable Space Protection uses either hardware or software features to mark memory as non-executable, thereby preventing injected code from being executed. W^X restricts a memory page from being both writable and executable, therefore, any memory that can be overwritten by a threat actor (W), cannot be executable (X).

Address space layout randomization (ASLR) is designed to reduce the predictability of memory addresses so that a threat actor cannot consistently find areas of memory that are able to be exploited or manipulated. This can be done across the application and kernel (KASLR) data spaces.

Lastly, program stack specific mitigations, such as stack canaries [5], safe/unsafe stack schemes [4], etc. can be used to detect or increase the difficulty of stack overwrite attacks.

Devices should use a combination of the above classes of code and memory injection protections to give their device a more secure posture.

Limitations: Some mechanisms that specifically address code injection can be bypassed by attacks that reuse existing code, such as return-to-libc and return-oriented programming (ROP). Further, ASLR can be undermined by secondary vulnerabilities that disclose memory space addresses.

IEC 62443 4-2 Mappings

  • SAR / EDR / HDR / NDR 3.2 – Protection from malicious code

References

[1] Microsoft. “What is Data Execution Prevention (DEP)?.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://support.microsoft.com/en-us/topic/what-is-data-execution-prevention-dep-60dabc2b-90db-45fc-9b18-512419135817

[2] The kernel development community. “Kernel Self-Protection.” kernel.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.kernel.org/doc/html/v5.4/security/self-protection.html?highlight=kaslr

[3] J. Thompson. “Six Facts about Address Space Layout Randomization on Windows.” google.com. Accessed: Aug. 28, 2024. [Online.] Available: https://cloud.google.com/blog/topics/threat-intelligence/six-facts-about-address-space-layout-randomization-on-windows/

[4] The Clang Team. “SafeStack.” llvm.org. Accessed: Aug. 28, 2024. [Online.] Available: https://releases.llvm.org/15.0.0/tools/clang/docs/SafeStack.html

[5] E. Styger. “Stack Canaries with GCC: Checking for Stack Overflow at Runtime.” mcuoneclipse.com. Accessed: Aug. 28, 2024. [Online.] Available: https://mcuoneclipse.com/2019/09/28/stack-canaries-with-gcc-checking-for-stack-overflow-at-runtime/