Executive Summary

Summary
Title Windows 8 and later fail to properly randomize every application if system-wide mandatory ASLR is enabled via EMET or Windows Defender Exploit Guard
Informations
Name VU#817544 First vendor Publication 2017-11-17
Vendor VU-CERT Last vendor Modification 2017-11-19
Severity (Vendor) N/A Revision M

Security-Database Scoring CVSS v3

Cvss vector : N/A
Overall CVSS Score NA
Base Score NA Environmental Score NA
impact SubScore NA Temporal Score NA
Exploitabality Sub Score NA
 
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score N/A Attack Range N/A
Cvss Impact Score N/A Attack Complexity N/A
Cvss Expoit Score N/A Authentication N/A
Calculate full CVSS 2.0 Vectors scores

Detail

Vulnerability Note VU#817544

Windows 8 and later fail to properly randomize every application if system-wide mandatory ASLR is enabled via EMET or Windows Defender Exploit Guard

Original Release date: 17 Nov 2017 | Last revised: 19 Nov 2017

Overview

Microsoft Windows 8 introduced a change in how system-wide mandatory ASLR is implemented. This change requires system-wide bottom-up ASLR to be enabled for mandatory ASLR to receive entropy. Tools that enable system-wide ASLR without also setting bottom-up ASLR will fail to properly randomize executables that do not opt in to ASLR.

Description

Address Space Layout Randomization (ASLR)

Starting with Windows Vista, a feature called ASLR was introduced to Windows that helps prevent code-reuse attacks. By loading executable modules at non-predictable addresses, Windows can help to mitigate attacks that rely on code being at predictable locations. Return-oriented programming (ROP) is an exploit technique that relies on code that is loaded to a predictable or discoverable location. One weakness with the implementation of ASLR is that it requires that the code is linked with the /DYNAMICBASE flag to opt in to ASLR.

EMET and Windows Defender Exploit Guard

In order to help protect applications that don't necessarily opt in to using ASLR and other exploit mitigation techniques, Microsoft EMET was released. Using the EMET GUI, one can specify both system-wide and application-specific mitigations that can be enabled on a system. For system-wide mitigations, EMET simply acts as a front-end GUI to enable exploit mitigations that are built in to the Windows operating system. For application-specific mitigations, the EMET library is loaded into the process space of each application that is configured to be protected. Starting with the Windows 10 Fall Creators update, the capabilities that EMET provides have been replaced with Windows Defender Exploit Guard.

Mandatory ASLR and Windows 8

Both EMET and Windows Defender Exploit Guard can enable mandatory ASLR for code that isn't linked with the /DYNAMICBASE flag. This can be done on a per-application or system-wide basis. Before Windows 8, system-wide mandatory ASLR was implemented using the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages registry value. By settings this value to 0xFFFFFFFF, Windows will automatically relocate code that has a relocation table, and the new location of the code will be different across reboots of the same system or between different systems. Starting with Windows 8, system-wide mandatory ASLR is implemented differently than with prior versions of Windows. With Windows 8 and newer, system-wide mandatory ASLR is implemented via the HKLM\System\CurrentControlSet\Control\Session Manager\Kernel\MitigationOptions binary registry value. The other change introduced with Windows 8 is that system-wide ASLR must have system-wide bottom-up ASLR enabled to supply entropy to mandatory ASLR.

The Problem

Both EMET and Windows Defender Exploit Guard enable system-wide ASLR without also enabling system-wide bottom-up ASLR. Although Windows Defender Exploit guard does have a system-wide option for system-wide bottom-up-ASLR, the default GUI value of "On by default" does not reflect the underlying registry value (unset). This causes programs without /DYNAMICBASE to get relocated, but without any entropy. The result of this is that such programs will be relocated, but to the same address every time across reboots and even across different systems.

Impact

Windows 8 and newer systems that have system-wide ASLR enabled via EMET or Windows Defender Exploit Guard will have non-DYNAMICBASE applications relocated to a predictable location, thus voiding any benefit of mandatory ASLR. This can make exploitation of some classes of vulnerabilities easier.

Solution

The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workaround:

Enable system-wide bottom-up ASLR on systems that have system-wide mandatory ASLR

To enable both bottom-up ASLR and mandatory ASLR on a system-wide basis on a Windows 8 or newer system, the following registry value should be imported:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
    "MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

Note that importing this registry value will overwrite any existing system-wide mitigations specified by this registry value. The bottom-up ASLR setting specifically is the second 01 in the binary string, while the mandatory ASLR setting is the first 01. Also note that in the past, enabling system-wide mandatory ASLR could cause problems if older AMD/ATI video card drivers are in use. This issue was addressed in the Catalyst 12.6 drivers released in June, 2012.

Vendor Information (Learn More)

VendorStatusDate NotifiedDate Updated
Microsoft CorporationAffected16 Nov 201717 Nov 2017
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

GroupScoreVector
Base0.0AV:--/AC:--/Au:--/C:--/I:--/A:--
Temporal0.0E:ND/RL:ND/RC:ND
Environmental0.0CDP:ND/TD:H/CR:ND/IR:ND/AR:ND

References

  • https://www.kb.cert.org/vuls/id/421280
  • https://insights.sei.cmu.edu/cert/2012/06/amd-video-drivers-prevent-the-use-of-the-most-secure-setting-for-microsofts-exploit-mitigation-exper.html
  • https://blogs.technet.microsoft.com/srd/2010/12/08/on-the-effectiveness-of-dep-and-aslr/
  • https://msdn.microsoft.com/en-us/library/bb384887.aspx
  • https://support.microsoft.com/en-us/help/2458544/the-enhanced-mitigation-experience-toolkit
  • https://blogs.technet.microsoft.com/srd/2013/12/11/software-defense-mitigating-common-exploitation-techniques/
  • https://blogs.technet.microsoft.com/mmpc/2017/10/23/windows-defender-exploit-guard-reduce-the-attack-surface-against-next-generation-malware/

Credit

This issue was reported by Will Dormann of the CERT/CC, with assistance from Matt Miller of Microsoft.

This document was written by Will Dormann.

Other Information

  • CVE IDs:Unknown
  • Date Public:16 Nov 2017
  • Date First Published:17 Nov 2017
  • Date Last Updated:19 Nov 2017
  • Document Revision:40

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Original Source

Url : http://www.kb.cert.org/vuls/id/817544

Alert History

If you want to see full details history, please login or register.
0
1
2
Date Informations
2017-11-20 05:21:16
  • Multiple Updates
2017-11-17 21:22:01
  • Multiple Updates
2017-11-17 17:20:52
  • First insertion