{"id":67773,"date":"2023-06-06T16:40:57","date_gmt":"2023-06-06T08:40:57","guid":{"rendered":"https:\/\/version-2.com\/?p=67773"},"modified":"2023-06-06T16:55:49","modified_gmt":"2023-06-06T08:55:49","slug":"binary-memory-protection-measures-on-windows-os","status":"publish","type":"post","link":"https:\/\/version-2.com\/en\/2023\/06\/binary-memory-protection-measures-on-windows-os\/","title":{"rendered":"Binary memory protection measures on Windows OS"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n

Binary memory protection is a core part of cybersecurity, but there are many different options for implementing it. In this article, we explore common mechanisms and protection measures for Windows OS.<\/p>\n\n

\n\n<\/div>\n
\n
\n

Why is binary memory protection important?<\/b><\/h2>\n

You may remember when the Blaster worm struck the internet, or more recently when WannaCry caused global havoc using a leaked EternalBlue Windows OS exploit. Both are examples of malware that used buffer overflow memory corruption vulnerabilities, causing remote code execution and infecting millions of machines worldwide.<\/p>\n

Most operating systems, written in C or C++, have limited memory protection, allowing these attacks to occur. Malware like Blaster and WannaCry manipulate the environment, instructions, and memory layout of a program or operating system to gain control over it.<\/p>\n

Security professionals have implemented mechanisms to prevent software exploitation and minimize damage caused by memory corruption bugs. A “silver bullet” solution would be a mechanism that makes it challenging and unreliable for attackers to exploit vulnerabilities, allowing developers to leave buggy code in place while they work on fixing or rewriting it in memory-safe languages.<\/p>\n\n

Common mechanisms and protection measures<\/b><\/h2>\n

Let\u2019s review some of the most common mechanisms and protection measures provided inside Windows OS from Windows XP to Windows 11.<\/p>\n\n

ASLR<\/b><\/h2>\n

Address space layout randomization (ASLR) is a computer security technique that prevents an attacker from reliably jumping to, for example, a particular exploited function in a program\u2019s memory. ASLR randomly arranges the address space positions of a process\u2019s key data areas, including the base of the executable and the positions of the stack, heap, and libraries. The effectiveness of ASLR depends on the entropy of the process\u2019s address space (simply put, the probability of finding a random local variable).<\/p>\n

Because of this protection, exploit payloads must be uniquely tailored to a specific process address space.<\/p>\n

Vista and Windows Server 2008 were the first operating systems in the Windows family to provide ASLR natively, though this system was first developed back in 2001. Prior to these releases, there were several third-party solutions like WehnTrust<\/a> available that provided ASLR functionality to varying degrees.<\/p>\n

When Symantec conducted research on ASLR in Windows Vista<\/a>, they found that ASLR had a significant effect when implemented in Windows 8 (or Windows 8.1). It provided higher entropy for address space layouts. The larger address space for 64-bit processes also increased the entropy of the ASLR for any given process.<\/p>\n\n

\n\n \n\nExploit mitigation improvements in Windows 8\n\n<\/div>\n

Windows 8 added randomization for all BottomUp and TopDown memory allocations, increasing the effectiveness of ASLR, which was not available in Windows 7.<\/p>\n\n

\n\n\"\"<\/span>\"Exploit<\/span>\n\n\n\n \n\nExploit mitigation improvements in Windows 8\n\n<\/div>\n

In Windows 8, Microsoft introduced operating system support to force EXEs\/DLLs to be rebased at runtime if they did not opt-in to ASLR. This mitigation can be enabled system-wide or on a per-process basis. You can modify the settings of mandatory ASLR through the Windows Security app.<\/p>\n

ASLR, like any other security technique, has its weaknesses and attack vectors (heap spray<\/a>, offset2libc<\/a>, Jump Over ASLR<\/a>, and others). Even one memory disclosure can completely defeat ASLR and provide an attacker with a significant opportunity. In addition to this, ASLR is only efficient when all executables and shared libraries loaded in the address space of a process are randomized. For example, research by Trend Micro<\/a> researchers showed that Microsoft Edge browser exploit mitigations, including ASLR, could be bypassed. You can watch a video from the BlackHat conference<\/a> to learn more.<\/p>\n\n

DEP<\/b><\/h2>\n

Data Execution Prevention (DEP) is a protection mechanism that blocks the execution of code in memory pages marked non-executable. The NX (No-Execute) bit is a protection feature on CPUs used by DEP to prevent attackers from executing shellcode (instructions injected and executed by attackers) on the stack, heap, or in data sections. If DEP is enabled and a program attempts to execute code on a non-executable page, an access violation exception will be triggered.<\/p>\n

Starting with Windows XP Service Pack 2 (2004) and Windows Server 2003 Service Pack 1 (2005), the DEP was implemented for the first time on x86 architecture.<\/p>\n

An application can be compiled with the \/NXCOMPAT flag to enable DEP for that application. You can also use editbin.exe \/NXCOMPAT over a .exe file to enable it on a previously compiled file.<\/p>\n

On 64-bit versions of Windows, DEP is always turned on for 64-bit processes and cannot be disabled. Windows also implemented software DEP (without the use of the NX bit) through Microsoft’s “Safe Structured Exception Handling” (SafeSEH), which I will talk about a bit later.<\/p>\n

Despite being a useful protection measure, the NX bit can be bypassed. This leaves us unable to execute instructions placed on the stack, but still able to control the execution flow of the application. This is where the ROP (Return Oriented Programming) technique<\/a> becomes relevant.<\/p>\n\n

GS (Stack Canaries)<\/b><\/h2>\n

Stack canaries are a security feature that helps protect against binary exploits. They are random values that are generated every time a program is run. When placed in certain locations, they can be used to detect stack corruption. The \/GS compiler option, when specified, causes the compiler to store a random value on the stack between the local variables and the return address of a function. According to Microsoft, these application elements will be protected:<\/p>\n\n