December 16, 2013 at 17:09ASLR in the latest releases of Windows
We have already mentioned ASLR many times, as MS rightly remarks, this technology makes exploit development a much more expensive event, since in addition to exploiting the vulnerability in software, an attacker needs to rely on some predictable memory addresses at the time of operation, which ASLR deprives him of. As we can see, recently, including the release of the latest Windows 8 / 8.1, MS decided to take a more serious approach to deploying this feature in the system. If, in the narrow sense, ASLR is understood as simply moving an image to unpredictable addresses with every reboot,
We will not touch on the history of ASLR, which is already known to almost everyone, we note only some not quite obvious features that Microsoft uses to improve ASLR in its flagship Windows 7-8-8.1.
ASLR rules
Microsoft uses an approach similar to DEP with respect to ASLR, i.e., allow it to be used as needed if the application is compiled with support. This practice is used in view of the obvious compatibility problems that may arise when programs run with technologies to which they may respond inappropriately. But in the case of working with ASLR, this situation used tothe best 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 bit depth of the OS and bootloader parameter). With ASLR, the situation is different, even when running on Windows 8 / 8.1, it relies on the rules for its support by the application itself and does not include image randomization if the header does not have this flag.
Attackers can take advantage of the system library, which 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 the practice of recent years shows, this opportunity was used more than once in the organization of targeted attacks. The following are exploited in-the-wild vulnerabilities like RCE (drive-by download).
As you can see, the MS Office library (hxds.dll) does not support ASLR (Office 2007-2010), and 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 oversight (called the 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 ASLR support features that MS introduced with Windows 8 is the Force ASLR (Force ASLR) feature. This feature is somewhat reminiscent of the OptIn DEP policy setting for the entire system. Now using the Image File Execution Options (IFEO) registry key HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Image File Execution Options and the MitigationOptions parameter, the user can manually enable ASLR for PE executable files. The table below shows the behavior of the OS when loading an executable file with and without ForceASLR into memory.
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 for Windows 7 with KB2639308 installed ) for all libraries loaded into the browser address space (ForceASLR). Thus, if any of the libraries or plugins was originally compiled without support for this function, it will be applied to it forcibly.
Attackers take advantage of Windows, which applies some optimization when working with virtual memory by sequentially allocating adjacent regions of the right size for clients (processes) through VirtualAlloc. An application can request a way to allocate a block of virtual memory as bottom-up (by default), top-down (MEM_TOP_DOWN) or at a fixed address (address specified by the function). By default, Windows uses the bottom-up selection method, that is, from lower to higher addresses, it will look for a block of the required size in order to give it to the application.
Starting with Windows 8, ASLR can affect virtual memory allocation. Prior to Windows 8, such a policy was already used to allocate memory blocks on the heap when reserving blocks for stream stacks, as well as TEB and PEB. The last 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 libraries in memory. On windows 8VirtualAlloc also distinguishes between top-down and bottom-up selection options, but now the base address of the start of these allocations is fixed by ASLR each time the OS boots, that is, it cannot be predicted. Obviously, in the address space it is impossible to allocate memory quite randomly due to fast fragmentation, therefore, it is through ASLR that the base address of the start of block allocation for processes is recorded. According to the MS for the process, this option is enabled only if the ASLR is properly supported by its executable file ( / DYNAMICBASE ).
High Entropy ASLR
ASLR can potentially work more efficiently in a 64-bit address space, since there is a much greater opportunity for arbitrary memory allocation 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 (i.e., the degree of randomness / predictability of the choice of address) and how many bits of the address will be used to calculate the randomness 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 both to virtual memory blocks allocated by the process and to downloadable executables. For 64-bit applications compiled with the / LARGEADDRESSAWARE flag, Windows 8 allocates 8 TB of virtual memory to use (128 TB in 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 use ASLR for the base address of the bottom-up memory allocation, using 24 bits of address to obtain entropy and for top-down allocations of 17 bits of address for entropy. To use this ASLR level and when using bottom-up selections (by default), a 64-bit application must be compiled with the / HIGHENTROPYVA and / DYNAMICBASE flags .
It should be noted that / HIGHENTROPYVA itself is used as the OptIn restriction mode of using HEASLR in the OS. That is VirtualAllocin its usual behavior (bottom-up block allocation) on Windows 8 it will not use reinforced ASLR for applications that are compiled without this flag. This limitation is related to compatibility issues and possible unpredictable behavior of these applications in this situation. As indicated above, the High Entropy Randomization feature is also applicable to 64-bit executable files.
Internet Explorer 10+ uses High Entropy ASLR (x64) mode. The property of its running process on Windows 8 is shown below. Note that all system executables that Microsoft ships 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 a strategy for 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 attacking addresses greatly reduces the capabilities of existing DEP & ASLR technologies and increases the possibility of attackers' success in exploitation.
One striking example is the MS13-031 update , which introduces a zero-page memory allocation limit (Windows 7+). Placing code on this page with the subsequent exploitation of the vulnerability in the driver is used by attackers as LPE, that is, raising their privileges to system privileges and executing their code in kernel mode. The kernel uses the EPROCESS! LowVaAccessible fieldto regulate such situations, namely, to detect the minimum address from which it is possible to reserve regions of virtual memory.
Another example is the MS13-063 update for Windows Vista + (Windows 8 by default). This update removes the pointer to ntdll! LdrHotPatchRoutine from UserSharedData (KUSER_SHARED_DATA) , which was used to quickly load the libraries the attacker needed into memory. UserSharedData is very useful for attackers, as 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). We wrote more about this feature here.. Important ntoskrnl functions return an error status upon request for information about the addresses of various kernel objects.
PS You can use the free BinScope tool from Microsoft to check 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 on the history of ASLR, which is already known to almost everyone, we note only some not quite obvious features that Microsoft uses to improve ASLR in its flagship Windows 7-8-8.1.
ASLR rules
Microsoft uses an approach similar to DEP with respect to ASLR, i.e., allow it to be used as needed if the application is compiled with support. This practice is used in view of the obvious compatibility problems that may arise when programs run with technologies to which they may respond inappropriately. But in the case of working with ASLR, this situation used tothe best 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 bit depth of the OS and bootloader parameter). With ASLR, the situation is different, even when running on Windows 8 / 8.1, it relies on the rules for its support by the application itself and does not include image randomization if the header does not have this flag.
Attackers can take advantage of the system library, which 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 the practice of recent years shows, this opportunity was used more than once in the organization of targeted attacks. The following are exploited in-the-wild vulnerabilities like RCE (drive-by download).
As you can see, the MS Office library (hxds.dll) does not support ASLR (Office 2007-2010), and 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 oversight (called the 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 ASLR support features that MS introduced with Windows 8 is the Force ASLR (Force ASLR) feature. This feature is somewhat reminiscent of the OptIn DEP policy setting for the entire system. Now using the Image File Execution Options (IFEO) registry key HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Image File Execution Options and the MitigationOptions parameter, the user can manually enable ASLR for PE executable files. The table below shows the behavior of the OS when loading an executable file with and without ForceASLR into memory.
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 for Windows 7 with KB2639308 installed ) for all libraries loaded into the browser address space (ForceASLR). Thus, if any of the libraries or plugins was originally compiled without support for this function, it will be applied to it forcibly.
Attackers take advantage of Windows, which applies some optimization when working with virtual memory by sequentially allocating adjacent regions of the right size for clients (processes) through VirtualAlloc. An application can request a way to allocate a block of virtual memory as bottom-up (by default), top-down (MEM_TOP_DOWN) or at a fixed address (address specified by the function). By default, Windows uses the bottom-up selection method, that is, from lower to higher addresses, it will look for a block of the required size in order to give it to the application.
Starting with Windows 8, ASLR can affect virtual memory allocation. Prior to Windows 8, such a policy was already used to allocate memory blocks on the heap when reserving blocks for stream stacks, as well as TEB and PEB. The last 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 libraries in memory. On windows 8VirtualAlloc also distinguishes between top-down and bottom-up selection options, but now the base address of the start of these allocations is fixed by ASLR each time the OS boots, that is, it cannot be predicted. Obviously, in the address space it is impossible to allocate memory quite randomly due to fast fragmentation, therefore, it is through ASLR that the base address of the start of block allocation for processes is recorded. According to the MS for the process, this option is enabled only if the ASLR is properly supported by its executable file ( / DYNAMICBASE ).
High Entropy ASLR
ASLR can potentially work more efficiently in a 64-bit address space, since there is a much greater opportunity for arbitrary memory allocation 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 (i.e., the degree of randomness / predictability of the choice of address) and how many bits of the address will be used to calculate the randomness 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 both to virtual memory blocks allocated by the process and to downloadable executables. For 64-bit applications compiled with the / LARGEADDRESSAWARE flag, Windows 8 allocates 8 TB of virtual memory to use (128 TB in 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 use ASLR for the base address of the bottom-up memory allocation, using 24 bits of address to obtain entropy and for top-down allocations of 17 bits of address for entropy. To use this ASLR level and when using bottom-up selections (by default), a 64-bit application must be compiled with the / HIGHENTROPYVA and / DYNAMICBASE flags .
It should be noted that / HIGHENTROPYVA itself is used as the OptIn restriction mode of using HEASLR in the OS. That is VirtualAllocin its usual behavior (bottom-up block allocation) on Windows 8 it will not use reinforced ASLR for applications that are compiled without this flag. This limitation is related to compatibility issues and possible unpredictable behavior of these applications in this situation. As indicated above, the High Entropy Randomization feature is also applicable to 64-bit executable files.
Internet Explorer 10+ uses High Entropy ASLR (x64) mode. The property of its running process on Windows 8 is shown below. Note that all system executables that Microsoft ships 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 a strategy for 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 attacking addresses greatly reduces the capabilities of existing DEP & ASLR technologies and increases the possibility of attackers' success in exploitation.
One striking example is the MS13-031 update , which introduces a zero-page memory allocation limit (Windows 7+). Placing code on this page with the subsequent exploitation of the vulnerability in the driver is used by attackers as LPE, that is, raising their privileges to system privileges and executing their code in kernel mode. The kernel uses the EPROCESS! LowVaAccessible fieldto regulate such situations, namely, to detect the minimum address from which it is possible to reserve regions of virtual memory.
Another example is the MS13-063 update for Windows Vista + (Windows 8 by default). This update removes the pointer to ntdll! LdrHotPatchRoutine from UserSharedData (KUSER_SHARED_DATA) , which was used to quickly load the libraries the attacker needed into memory. UserSharedData is very useful for attackers, as 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). We wrote more about this feature here.. Important ntoskrnl functions return an error status upon request for information about the addresses of various kernel objects.
PS You can use the free BinScope tool from Microsoft to check 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