ASLR in the latest releases of Windows
We have repeatedly mentioned ASLR, according to MS, this technology allows making exploit development a much more costly measure, because in addition to exploiting the vulnerability in the software, the attacker must rely on certain predictable addresses in the memory at the time of operation, which ASLR deprives of it. As we can see, recently, including the release of the newest Windows 8 / 8.1, MS decided to take a more serious approach to the deployment of this feature in the system. If in the narrow sense, ASLR is understood as simply moving the image to unpredictable addresses with each reboot, then in a more general sense, this possibility at the system level should deprive the attackers of any opportunity to catch on with certain addresses of system library functions and other system objects (ASLR bypass mitigation / Address Space Information Disclosure Hardening) in those several dozen bytes of shellcode that can be executed bypassing DEP (ROP).
We will not touch upon the history of ASLR, which is already known to almost everyone, let us note only some of the not quite obvious possibilities that Microsoft uses to improve ASLR in its flagship OS Windows 7-8-8.1.
ASLR rules
')
Microsoft uses a similar approach to DLP in relation to ASLR, that is, allow its use as needed if the application is compiled with support. This practice is applied in view of the obvious compatibility problems that may arise when working with technology programs to which they may not respond adequately. But in the case of the ASLR, this situation works with more restrictions. For example, on modern releases of Windows 8 / 8.1, DEP is always enabled for applications, regardless of whether they are compiled with its support or not (at least on a 64-bit processor and regardless of the bitness of the OS and the boot loader setting). With ASLR, the situation is different, even when working on Windows 8 / 8.1, it relies on the rules of its support by the application itself and does not include image randomization if the header does not have this flag.
Attackers can use the “benefits” of a system library that is not compiled with ASLR support for their own purposes, for example, to implement a stable ROP chain that will work in all supported OSs. As practice has shown in recent years, this opportunity has been used more than once in the organization of targeted attacks. The following are such in-the-wild exploited vulnerabilities like RCE (drive-by download).
As you can see, the MS Office library (hxds.dll) does not support ASLR (Office 2007-2010) and the attackers were able to use its unchanged download address to successfully exploit the vulnerability. As part of the December patch tuesday, the company closed this mistake (called Security Feature Bypass) using MS13-106 , providing Windows users who work with this version of Office with the proper level of protection.
One of the main opportunities for ASLR support that MS introduced with Windows 8 is the Force ASLR (Force ASLR) function. This function is somewhat similar to the OptIn parameter of the DEP policy for the entire system. Now using the registry key Image File Execution Options (IFEO) HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Image File Execution Options and the MitigationOptions parameter, the user can manually enable ASLR for executable PE files. The table below shows the behavior of the OS when an executable file is loaded into memory with and without ForceASLR.
A similar feature is also available for Windows 7 users when installing the optional update KB2639308 .
In order to make Internet Explorer (10+) more secure, the company introduced support for the ASLR enforcement function (on Windows 8+ and on Windows 7 with KB2639308 installed) for all libraries loaded into the browser process address space (ForceASLR). Thus, if any of the libraries or plug-ins are initially compiled without the support of this function, it will be applied to it by force.
Attackers take advantage of Windows, which applies some optimization when working with virtual memory through sequential allocation of adjacent regions of the right size for clients (processes) via VirtualAlloc . An application can request a way to allocate a block of virtual memory as bottom-up (the default), top-down (MEM_TOP_DOWN), or at a fixed address (the address specified by the function). By default, Windows uses a bottom-up selection method, i.e., from lower to upper addresses, it will look for a block of the required size in order to give it to the application.
Starting with Windows 8, allocating virtual memory can be affected by ASLR. This policy before Windows 8 was already used to allocate blocks of memory on the heap, when reserving blocks for stacks of threads, as well as TEB and PEB. The latter two structures are very useful for attackers because they potentially contain a certain number of pointers to various system functions, thus revealing the location of the libraries in memory. In Windows 8, VirtualAlloc also distinguishes top-down and bottom-up selection options, but now the base address of the beginning of these allocations is fixed by ASLR every time the OS boots up, i.e. it cannot be predictable. Obviously, in the address space it is impossible to allocate memory completely chaotic due to the rapid fragmentation, therefore, through ASLR, it is the base address of the beginning of the allocation of blocks for processes that is fixed. According to MS for the process, such an option is enabled only if the ASLR supports its executable file ( / DYNAMICBASE ).
High Entropy ASLR
ASLR can potentially work more efficiently in a 64-bit address space, because there is a much greater opportunity for arbitrary memory placement in such a large address space. Obviously, its use itself is already a complicating factor for heap spray. See Internet Explorer EPM for Windows 7 x64 . At the same time, OSs prior to Windows 8 do not use ASLR on x64 in the most complete way. This mainly concerns the possibility of entropy (that is, the degree of arbitrariness / predictability of address selection) and how many bits of the address will be used to calculate the arbitrariness of this allocation. In Windows 8, this feature is called High Entropy Randomization.
Windows 8+ contains features that implement High Entropy Randomization and this technology extends to both the virtual memory blocks allocated by the process and downloadable executable files. For 64-bit applications bundled with the / LARGEADDRESSAWARE flag, Windows 8 allocates 8 TB of virtual memory for use (128 TB for Windows 8.1). For comparison, in 32-bit applications, the size of the user part of the address space is limited to 2 GB. In this case, the High Entropy Randomization feature allows you to apply ASLR for the base address of the bottom-up memory allocation reference, using 24 address bits for entropy and for the top-down selection, 17 bits for the entropy address. To use this level of ASLR and using bottom-up selections (default), a 64-bit application must be compiled with the / HIGHENTROPYVA and / DYNAMICBASE flags .
It should be noted that / HIGHENTROPYVA itself is used as an OptIn restriction mode of using HEASLR in the OS. That is, VirtualAlloc in its usual behavior (block-to-bottom allocation) on Windows 8 will not use enhanced ASLR for applications that are compiled without this flag. This limitation is related to compatibility issues and the possible unpredictable behavior of these applications in this situation. As stated above, the High Entropy Randomization feature also applies to 64-bit executables.
Internet Explorer 10+ uses High Entropy ASLR (x64). Below is a property of its running process on Windows 8. Note that all system executable files that Microsoft supplies in Windows 8 use HEASLR.
ASLR bypass mitigations (aka Address Space Information Disclosure Hardening)
With the release of Windows 8, the company tried to follow the strategy of hiding various addresses of system functions and objects. Some of these features were delivered as updates for Windows 7. The presence of such information at predictable addresses for attackers greatly reduces the capabilities of existing DEP & ASLR technologies and increases the likelihood of attackers' success in exploitation.
One striking example is the MS13-031 update, which introduces a limit on memory allocation for a zero page (Windows 7+). Placing the code on this page and then exploiting the vulnerability in the driver is used by the attackers as LPE, that is, raising their privileges to system privileges and executing their code in kernel mode. The kernel uses the EPROCESS! LowVaAccessible field to handle such situations, namely, to find the minimum address from which virtual memory regions can be backed up.
Another example is the MS13-063 update for Windows Vista + (Windows 8 by default). This update removes from UserSharedData (KUSER_SHARED_DATA) a pointer to ntdll! LdrHotPatchRoutine , which was used to quickly load the necessary attacking library into memory. UserSharedData is very useful for attackers, because it is available at the same address in all processes, and is also used in kernel mode.
In Windows 8.1, it became possible to hide information about the addresses of kernel objects for untrusted applications (whose Integrity Level <Medium). In more detail about this function we wrote here . Important ntoskrnl functions return an error status for a request to obtain information about the addresses of various kernel objects.
PS You can use Microsoft's free BinScope tool to test the modules of your programs for ASLR support (iTunes is taken as an example).
blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx
We will not touch upon the history of ASLR, which is already known to almost everyone, let us note only some of the not quite obvious possibilities that Microsoft uses to improve ASLR in its flagship OS Windows 7-8-8.1.
ASLR rules
')
Microsoft uses a similar approach to DLP in relation to ASLR, that is, allow its use as needed if the application is compiled with support. This practice is applied in view of the obvious compatibility problems that may arise when working with technology programs to which they may not respond adequately. But in the case of the ASLR, this situation works with more restrictions. For example, on modern releases of Windows 8 / 8.1, DEP is always enabled for applications, regardless of whether they are compiled with its support or not (at least on a 64-bit processor and regardless of the bitness of the OS and the boot loader setting). With ASLR, the situation is different, even when working on Windows 8 / 8.1, it relies on the rules of its support by the application itself and does not include image randomization if the header does not have this flag.
Attackers can use the “benefits” of a system library that is not compiled with ASLR support for their own purposes, for example, to implement a stable ROP chain that will work in all supported OSs. As practice has shown in recent years, this opportunity has been used more than once in the organization of targeted attacks. The following are such in-the-wild exploited vulnerabilities like RCE (drive-by download).
As you can see, the MS Office library (hxds.dll) does not support ASLR (Office 2007-2010) and the attackers were able to use its unchanged download address to successfully exploit the vulnerability. As part of the December patch tuesday, the company closed this mistake (called Security Feature Bypass) using MS13-106 , providing Windows users who work with this version of Office with the proper level of protection.
One of the main opportunities for ASLR support that MS introduced with Windows 8 is the Force ASLR (Force ASLR) function. This function is somewhat similar to the OptIn parameter of the DEP policy for the entire system. Now using the registry key Image File Execution Options (IFEO) HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Image File Execution Options and the MitigationOptions parameter, the user can manually enable ASLR for executable PE files. The table below shows the behavior of the OS when an executable file is loaded into memory with and without ForceASLR.
A similar feature is also available for Windows 7 users when installing the optional update KB2639308 .
In order to make Internet Explorer (10+) more secure, the company introduced support for the ASLR enforcement function (on Windows 8+ and on Windows 7 with KB2639308 installed) for all libraries loaded into the browser process address space (ForceASLR). Thus, if any of the libraries or plug-ins are initially compiled without the support of this function, it will be applied to it by force.
Attackers take advantage of Windows, which applies some optimization when working with virtual memory through sequential allocation of adjacent regions of the right size for clients (processes) via VirtualAlloc . An application can request a way to allocate a block of virtual memory as bottom-up (the default), top-down (MEM_TOP_DOWN), or at a fixed address (the address specified by the function). By default, Windows uses a bottom-up selection method, i.e., from lower to upper addresses, it will look for a block of the required size in order to give it to the application.
Starting with Windows 8, allocating virtual memory can be affected by ASLR. This policy before Windows 8 was already used to allocate blocks of memory on the heap, when reserving blocks for stacks of threads, as well as TEB and PEB. The latter two structures are very useful for attackers because they potentially contain a certain number of pointers to various system functions, thus revealing the location of the libraries in memory. In Windows 8, VirtualAlloc also distinguishes top-down and bottom-up selection options, but now the base address of the beginning of these allocations is fixed by ASLR every time the OS boots up, i.e. it cannot be predictable. Obviously, in the address space it is impossible to allocate memory completely chaotic due to the rapid fragmentation, therefore, through ASLR, it is the base address of the beginning of the allocation of blocks for processes that is fixed. According to MS for the process, such an option is enabled only if the ASLR supports its executable file ( / DYNAMICBASE ).
High Entropy ASLR
ASLR can potentially work more efficiently in a 64-bit address space, because there is a much greater opportunity for arbitrary memory placement in such a large address space. Obviously, its use itself is already a complicating factor for heap spray. See Internet Explorer EPM for Windows 7 x64 . At the same time, OSs prior to Windows 8 do not use ASLR on x64 in the most complete way. This mainly concerns the possibility of entropy (that is, the degree of arbitrariness / predictability of address selection) and how many bits of the address will be used to calculate the arbitrariness of this allocation. In Windows 8, this feature is called High Entropy Randomization.
Windows 8+ contains features that implement High Entropy Randomization and this technology extends to both the virtual memory blocks allocated by the process and downloadable executable files. For 64-bit applications bundled with the / LARGEADDRESSAWARE flag, Windows 8 allocates 8 TB of virtual memory for use (128 TB for Windows 8.1). For comparison, in 32-bit applications, the size of the user part of the address space is limited to 2 GB. In this case, the High Entropy Randomization feature allows you to apply ASLR for the base address of the bottom-up memory allocation reference, using 24 address bits for entropy and for the top-down selection, 17 bits for the entropy address. To use this level of ASLR and using bottom-up selections (default), a 64-bit application must be compiled with the / HIGHENTROPYVA and / DYNAMICBASE flags .
It should be noted that / HIGHENTROPYVA itself is used as an OptIn restriction mode of using HEASLR in the OS. That is, VirtualAlloc in its usual behavior (block-to-bottom allocation) on Windows 8 will not use enhanced ASLR for applications that are compiled without this flag. This limitation is related to compatibility issues and the possible unpredictable behavior of these applications in this situation. As stated above, the High Entropy Randomization feature also applies to 64-bit executables.
Internet Explorer 10+ uses High Entropy ASLR (x64). Below is a property of its running process on Windows 8. Note that all system executable files that Microsoft supplies in Windows 8 use HEASLR.
ASLR bypass mitigations (aka Address Space Information Disclosure Hardening)
With the release of Windows 8, the company tried to follow the strategy of hiding various addresses of system functions and objects. Some of these features were delivered as updates for Windows 7. The presence of such information at predictable addresses for attackers greatly reduces the capabilities of existing DEP & ASLR technologies and increases the likelihood of attackers' success in exploitation.
One striking example is the MS13-031 update, which introduces a limit on memory allocation for a zero page (Windows 7+). Placing the code on this page and then exploiting the vulnerability in the driver is used by the attackers as LPE, that is, raising their privileges to system privileges and executing their code in kernel mode. The kernel uses the EPROCESS! LowVaAccessible field to handle such situations, namely, to find the minimum address from which virtual memory regions can be backed up.
Another example is the MS13-063 update for Windows Vista + (Windows 8 by default). This update removes from UserSharedData (KUSER_SHARED_DATA) a pointer to ntdll! LdrHotPatchRoutine , which was used to quickly load the necessary attacking library into memory. UserSharedData is very useful for attackers, because it is available at the same address in all processes, and is also used in kernel mode.
In Windows 8.1, it became possible to hide information about the addresses of kernel objects for untrusted applications (whose Integrity Level <Medium). In more detail about this function we wrote here . Important ntoskrnl functions return an error status for a request to obtain information about the addresses of various kernel objects.
PS You can use Microsoft's free BinScope tool to test the modules of your programs for ASLR support (iTunes is taken as an example).
blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx
Source: https://habr.com/ru/post/206244/
All Articles