An elevation of privilege vulnerability exists when the Windows kernel-mode driver fails to properly handle objects in memory. An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

To exploit this vulnerability, an attacker would first have to log on to the system. An attacker could then run a specially crafted application to take control of an affected system.

The update addresses the vulnerability by correcting how the Windows kernel-mode driver handles objects in memory.

Executive Summary

A security vulnerability exists in certain Trusted Platform Module (TPM) chipsets. The vulnerability weakens key strength. It is important to note that this is a firmware vulnerability, and not a vulnerability in the operating system or a specific application. After you have installed software and/or firmware updates, you will need to re-enroll in any security services you are running to remediate those services. For more details contact the TPM manufacturer - https://www.infineon.com/TPM-update. For specific services and use cases that are rendered insecure, see "Step 5 - Remediate services/(Use cases)" under Recommended Actions.

Advisory Details

Important This vulnerability is present in a specific vendor’s TPM firmware that is based on Trusted Computing Guidelines (TCG) specification family 1.2 and 2.0, not in the TPM standard or in Microsoft Windows. Some Windows security features and potentially third-party software rely on keys generated by the TPM (if available on the system). Microsoft is releasing Windows security updates to help work around the vulnerability by logging events and by allowing the generation of software based keys. Even after the operating system and/or TPM firmware updates are installed, you will need to carry out additional remediation steps to force regeneration of previously created weak TPM keys, depending on the applicable services you are running and on your particular use-cases. See Step 5 - "Remediate services based on your particular use cases" under Recommended Actions.

FAQ

1. What systems are at risk from this vulnerability?

• Client Operating Systems Windows client systems are at increased risk due to the prevalence of TPM on client hardware systems. There are distinct advantages to using hardware encryption modules.
• Server Operating Systems Servers with TPM modules.

2. What is a TPM?

See Trusted Platform Module Technology Overview

3. What is the associated CVE for this vulnerability?

See https://www.infineon.com/TPM-update

4. Have there been any active attacks detected?

No. When this security advisory was issued, Microsoft had not received any information to indicate that this vulnerability had been publicly used to attack customers.

5. Has this vulnerability been publicly disclosed?

No. Microsoft received information about the vulnerability through coordinated vulnerability disclosure.

6. What is the CVSS score?

https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N/E:P/RL:O/RC:C/CR:H/IR:H/AR:H/MAV:N/MAC:H/MPR:N/MUI:N/MS:U/MC:H/MI:L/MA:L

7. What if a TPM firmware update is not available from my hardware OEM?

Hardware OEMs may release a TPM firmware update independently of the Microsoft software updates. The software updates are being released as a workaround to the vulnerability. To address the underlying issue, customers need to obtain and install a TPM firmware update. It is recommended that you contact your hardware manufacturer(s) for further guidance. TPM firmware updates may be combined with OEM system firmware updates or be delivered as a standalone tool by OEMs.

In the event of a hardware OEM explicitly NOT issuing a firmware update, customers can:

• Decide that the operating system update (that generates software-based keys) is sufficient for your services and use-cases. Note Services and use-case remediation will still be necessary.
• Move critical roles and users to devices that have updated firmware
• Move critical roles and users to devices that are not impacted by this vulnerability

8. I am running Windows 7 or Windows Server 2007 R2. Why do these operating systems not appear on the Affected Products table?

Windows 7 services and use cases are limited to BitLocker. Bitlocker on Windows 7 cannot work around the hardware issue. Therefore, because the vulnerability is in the firmware, updates are only necessary for the firmware.

For customers with affected devices that are running Windows 7, Microsoft suggests the following actions:

• Move critical roles and users to devices that have updated firmware
• Move critical roles and users to devices that are not affected by this vulnerability

If you are using non-Microsoft apps that require a TPM, you should contact the app developer to see if the app is affected.

9. I am running Windows Server 2012, Windows Server 2012 R2, or Windows 8.1. Why are there two Security Updates listed in the Affected Products table for these operating systems?

The updates addressing this vulnerability are part of an industry-wide coordinated disclosure to remediate the vulnerability. Each Security Update addresses a different aspect of the vulnerability, and were released in a phased approach. Important: Because the Security Updates are not cumulative, customers who install these updates must install both September and October updates to receive all of the updates for this vulnerability.

10. What do each of the Security Updates for Windows Server 2012, Windows Server 2012 R2, and Windows 8.1 address?

• September 2017 Security Updates provide the functionality to generate software keys.
• October 2017 Security Updates provide detection in TPM.MSC to determine if your device has a vulnerable TPM module.

It is recommended that you install BOTH Security Updates. Note that the Monthly Updates are cumulative, while Security Updates are not. Customers who install the monthly updates will receive both updates for this vulnerability.

Recommended Actions

1. Apply the Windows operating system updates (see Affected Products table for specific package KB numbers) first

WARNING: Do NOT apply the TPM firmware update prior to applying the Windows operating system mitigation update. Doing so will render your system unable to determine if your system is affected. You will need this information to conduct full remedation.

• The mitigation and detection update for Windows:
  • Addresses the vulnerability by preventing the generation of weak keys by the TPM hardware. New keys are generated using a software algorithm. Microsoft recommends that customers running systems that use affected TPM chipsets install the Windows security update as an interim measure until a firmware update is available from the system manufacturer.
  • Generates event log entries when a vulnerable TPM is detected.
  • Does NOT reduce BitLocker risk.

The majority of customers have automatic updating enabled and will not need to take any action because the updates will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install applicable updates manually. For administrators and enterprise installations, or end users who want to install the updates manually, Microsoft recommends applying the update immediately using update management software, or by checking for updates using the Microsoft Update service. For more information on how to manually apply this specific update, see the Affected Products table.

2. Determine devices in your organization that are affected

Because both mobile and stationary systems may be affected, mixing reactive and proactive measures may be best to determine affected devices. Depending on your use-case scenario, Microsoft recommends that you use one of the following methods to determine affected devices.

a. Option 1 - Use event log entries.

After the applicable Windows update is applied, the system will generate Event ID 1794 in the Event Viewer after each reboot under Windows Logs - System when vulnerable firmware is identified.

NOTE: Microsoft recommends that enterprise or home office users leverage this step as a reactive method to identify affected software.

b. Option 2 - Use a script (See Additional Context) to detect if firmware on your systems contain the vulnerability.

NOTE: Microsoft recommends that enterprise users leverage this step as a proactive method to identify affected software.

c. Option 3 - Manually check the Trusted Platform Module (TPM) Management snap-in (TPM.MSC) on each Windows 10 device

OOn devices running Windows 10 that have the October 2017 security update installed, in a CMD prompt, type "TPM.MSC" to open the Trusted Platform Module (TPM) Management snap-in. Devices with affected TPM modules will display the following error message:

"The TPM is ready for use. The TPM firmware on this PC has a known security problem. Please contact your PC manufacturer to find out if an update is available. For more information please go to https://go.microsoft.com/fwlink/?linkid=852572."

NOTE: Microsoft recommends that consumers and Home office users leverage this step to identify affected software.

3. If you determine that devices in your organization are affected, analyze your risk tolerance and create short and long term resolution plans

A firmware update may or may not be available at the time of advisory release. Furthermore, the affected devices may represent a only small portion of your overall resources. Even though the Windows update is not a true replacement for fixing the firmware flaw it can be used as a temporary mitigation. However, even after the operating system and TPM firmware updates are installed, you will need to assess your TPM usage scenarios and take manual actions to force new keys to be generated

4. Apply applicable firmware updates

• If your hardware is a Surface device, firmware updates are yet not available as of October 10, 2017. Microsoft is working to make firmware updates available for affected devices and will provide links in this advisory when the updates become available. Note that the Surface Laptop and the Surface Pro (released in June 2017) are NOT affected by this vulnerability.
• If your device is not from Microsoft, apply the firmware provided by the OEM.
• If your device OEM is not listed in the following table, please contact the OEM's Customer Support.

5. Remediate services based on your particular use cases Microsoft will continue to provide additional support to help identify and remediate this issue as it becomes available. The following table contains a list of services that you may be running on your device and a link to instructions for applying remediation steps for that service.

IMPORTANT BEFORE any remedition steps can be taken, Microsoft strongly recommends that a firmware update be applied. This is not a simple one-step procedure and you should fully understand the scope of the impact to you before proceeding.

6. Clear TPM

Important: Before using one of these methods for clearing TPM, please take note of the following:

• Be aware that clearing a TPM will render ALL services that use TPM keys unusable until you complete any required remeditation steps. You may need to contact any third-party service vendors for those steps.

• For systems running Windows 7, you must suspend BitLocker protection before clearing TPM from the operating system. See Suspend-BitLocker

• For systems running Windows Server 2012, Windows Server 2012 R2, or Windows 8.1, it is not necessary to suspend BitLocker before clearing TPM from the operating system. It is not recommended that you clear the TPM from a firmware menu because if you have activated Device Encryption, you will be unable to suspend it in the operating system. Additionally, you will need to retrieve your Device Encryption Recovery Key from the MSA cloud to boot after clearing the TPM.

• Devices running Windows 10 that are protected by Credential Guard will lose secrets. For more information, see Credential Guard Considerations: Clearing TPM considerations.

• To clear TPM via powershell, see Clear-Tpm

• To clear TPM via GUI, see Clear all the keys from the TPM

Additional context

• Azure AD - What is Azure Active Directory?
• Bitlocker suspension - Suspend-BitLocker
• Credential Guard: Clearing TPM considerations - Clearing TPM Considerations
• Domain-joined Device Public Key Authentication - Automatic public key provisioning
• MSA Microsoft Account- Microsoft Accounts
• TPM - Windows Trusted Platform Module Management Step-by-Step Guide
• TPM Key Attestation - TPM Key Attestation
• Virtual Smart Card overview - Virtual Smart Card Overview
• Windows hello / Next Gen Credential - Windows Hello for Business

Quick methods for determining the firmware version:

• Use PowerShell cmd: Get-TPM (run as an administrator) on each device.
• Use the following PowerShell script, run as an administrator. Failing to run the script as an administrator will return a false positive.

$IfxManufacturerIdInt = 0x49465800 # 'IFX'
		
		function IsInfineonFirmwareVersionAffectedRiemann ($FirmwareVersion)
		{
			$FirmwareMajor = $FirmwareVersion[0]
			$FirmwareMinor = $FirmwareVersion[1]
			switch ($FirmwareMajor)
			{
				4 { return $FirmwareMinor -le 33 -or ($FirmwareMinor -ge 40 -and $FirmwareMinor -le 42) }
				5 { return $FirmwareMinor -le 61 }
				6 { return $FirmwareMinor -le 42 }
				7 { return $FirmwareMinor -le 61 }
				133 { return $FirmwareMinor -le 32 }
				default { return $False }
			}
		}
		
		function IsInfineonFirmwareVersionRiemannSusceptible ($FirmwareMajor)
		{
			switch ($FirmwareMajor)
			{
				4 { return $True }
				5 { return $True }
				6 { return $True }
				7 { return $True }
				133 { return $True }
				default { return $False }
			}
		}
		
		$Tpm = Get-Tpm
		$ManufacturerIdInt = $Tpm.ManufacturerId
		$FirmwareVersion = $Tpm.ManufacturerVersion -split "\."
		$FirmwareVersionAtLastProvision = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\TPM\WMI" -Name "FirmwareVersionAtLastProvision" -ErrorAction SilentlyContinue).FirmwareVersionAtLastProvision
		
		if (!$Tpm)
		{
			Write-Host "No TPM found on this system, so the Riemann issue does not apply here."
		}
		else
		{
			if ($ManufacturerIdInt -ne $IfxManufacturerIdInt)
			{
				Write-Host "This non-Infineon TPM is not affected by the Riemann issue."
			}
			else
			{
				if ($FirmwareVersion.Length -lt 2)
				{
					Write-Error "Could not get TPM firmware version from this TPM."
				}
				else
				{
					if (IsInfineonFirmwareVersionRiemannSusceptible($FirmwareVersion[0]))
					{
						if (IsInfineonFirmwareVersionAffectedRiemann($FirmwareVersion))
						{
							Write-Host ("This Infineon firmware version {0}.{1} TPM is not safe. Please update your firmware." -f [int]$FirmwareVersion[0], [int]$FirmwareVersion[1])
						}
						else
						{
							Write-Host ("This Infineon firmware version {0}.{1} TPM is safe." -f [int]$FirmwareVersion[0], [int]$FirmwareVersion[1])
							if (!$FirmwareVersionAtLastProvision)
							{
								Write-Host ("We cannot determine what the firmware version was when the TPM was last cleared. Please clear your TPM now that the firmware is safe.")
							}
							elseif ($FirmwareVersion -ne $FirmwareVersionAtLastProvision)
							{
								Write-Host ("The firmware version when the TPM was last cleared was different from the current firmware version. Please clear your TPM now that the firmware is safe.")
							}
						}
					}
					else
					{
						Write-Host ("This Infineon firmware version {0}.{1} TPM is safe." -f [int]$FirmwareVersion[0], [int]$FirmwareVersion[1])
					}
				}
			}
		}

Microsoft is releasing an optional security enhancement to NT LAN Manager (NTLM), limiting which network resources various clients in the Windows 10 or the Windows Server 2016 operating systems can use NTLM Single Sign On(SSO) as an authentication method. When you deploy the new security enhancement with a Network Isolation Policy defining your organization's resources, attackers can no longer redirect a user to a malicious resource outside your organization to obtain the NTLM authentication messages. This new behavior is optional, and requires customers who wish to enable it to opt in via a Windows Registry Setting or other means described below.

Customers should be aware that enabling this new behavior will prevent NTLM SSO authentication with resources that are not marked as internal by the Windows Firewall. This may break some functionality by preventing NTLM SSO authentication to resources marked external, though other authentication methods will remain available. Examples where NTLM SSO authentication appear would be Internet Explorer or Edge, or a service calling WinHTTP to access a web resource; a user trying to connect to an SMB file share; or processes making RPC calls. Microsoft is releasing this new functionality as a mitigation to NTLM dictionary attacks. Microsoft continues to recommend that customers move to public key authentication methods for applications which do not support modern authentication, and use negotiate with Kerberos authentication whenever possible.

The new functionality works by denying NTLM SSO authentication as a method for public resources. This is achieved when the NTLM client leverages the Windows Firewall’s ability to determine if a resource is a Public, Private, or Enterprise resource as defined by the customer-configured Windows Information Protection settings. Depending on this determination, the connection will either be allowed or denied.

FAQ

1. Which registry setting should I set to enable this behavior?

Customers can add a DWORD32 key named “EnterpriseAccountSSO” to the Windows Registry location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0 with the following options:

• 2 – Always allow SSO. (This is the default state.)
• 1 – Deny SSO if the resource is public. Allow if the resource is private or enterprise. Allow SSO if the resource is unspecified.
• 0 – Deny SSO if the resource is public. Allow if the resource is private or enterprise. Deny SSO if the resource is unspecified.

2. Is any other configuration necessary for this new behavior?

Yes. Customers need to configure a Network Isolation Policy(NIP) that defines which networks should be considered internal/enterprise and thus will permit NTLM as an SSO Authentication method. A correctly configured NIP is critical for NTLM SSO to continue to function.

3. Which operating systems are vulnerable to this type of attack?

All versions of Windows that use NTLM are susceptible to this type of attack. Microsoft is releasing this new behavior only on the Windows 10 and Server 2016 platforms due to limitations in the older versions of the Windows Firewall, which preclude older operating systems from using this new behavior. Microsoft recommends customers upgrade to the newest, and most secure offerings.

4. Where can I find more information about Windows Information Protection?

See the following articles:

• Introducing Windows Information Protection
• Protect your enterprise data using Windows Information Protection (WIP)

5. Where can I find details about enabling this functionality through Group Policy?

See https://technet.microsoft.com/en-us/library/jj865668(v=ws.10).aspx

6. Are there other ways to opt-in to this new behavior?

Yes. Both the Group Policy network isolation settings and Windows Information Protection cover the same area, both for Apps and for NTLM SSO Authentication. Using either is equally effective at mitigating NTLM SSO hash theft, but customers should select between these options. Mixing various means could create unexpected behavior.

7. Is a reboot required to enable this new behavior?

A reboot will be required to install the security update. When you then enable this new behavior with a Windows Registry change, the new behavior will be immediately take effect and not require a reboot. The changes to the Windows Firewall will have a varied delay depending on whether WIP or GP was used, and when this configuration is refreshed.

8. My enterprise has enabled this behavior, and now users are being prompted for credentials where they previously were not. Why is this happening?

This is an indication that the resource is marked as public or that its designation is uncertain, if the strictest mode has been enabled. This is most likely a symptom of the resource being inaccurately represented in your enterprise’s NIP, or you have configured 0 and the application is not using SMB, RPC, or HTTP.

To check whether a resource is public, please enable the “Network Isolation Operational” logs under Windows Firewall with Advanced Security in Event Viewer. For the purposes of the log, enterprise resources are considered private. Please note that Network Isolation policies from Group Policy and WIP settings only affect networks whose profile is “Domain”. For more information about network profiles, please see: Understanding Firewall Profiles.

A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Microsoft Edge. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker who successfully exploited the vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

In a web-based attack scenario, an attacker could host a specially crafted website that is designed to exploit the vulnerability through Microsoft Edge and then convince a user to view the website. The attacker could also take advantage of compromised websites and websites that accept or host user-provided content or advertisements. These websites could contain specially crafted content that could exploit the vulnerability.

The update addresses the vulnerability by modifying how the scripting engine handles objects in memory.

A remote code execution vulnerability exists when Internet Explorer improperly accesses objects in memory. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, the attacker could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

An attacker could host a specially crafted website designed to exploit the vulnerability through Internet Explorer and then convince a user to view the website. The attacker could also take advantage of compromised websites, or websites that accept or host user-provided content or advertisements, by adding specially crafted content that could exploit the vulnerability. However, in all cases an attacker would have no way to force a user to view the attacker-controlled content. Instead, an attacker would have to convince a user to take action, typically by an enticement in an email or instant message, or by getting the user to open an attachment sent through email.

The security update addresses the vulnerability by modifying how Internet Explorer handles objects in memory.

A security feature bypass vulnerability exists in Device Guard that could allow an attacker to inject malicious code into a Windows PowerShell session. An attacker who successfully exploited this vulnerability could inject code into a trusted PowerShell process to bypass the Device Guard Code Integrity policy on the local machine.

To exploit the vulnerability, an attacker would first have to access the local machine, and then inject malicious code into a script that is trusted by the Code Integrity policy. The injected code would then run with the same trust level as the script and bypass the Code Integrity policy.

The update addresses the vulnerability by correcting how PowerShell exposes functions and processes user supplied code.

Microsoft has released an update for Microsoft Office that provides enhanced security as a defense-in-depth measure.

How should this update be deployed?

The update can be applied from Microsoft Update or the Download Center to existing Office installations by following the links in the KB articles listed in the Affected Products table. In addition, the update can be deployed in a new installation of Office by placing the Office setup files in the Updates folder in the Office installation image as follows:

1. Download OfficeSetupFiles.zip from the following link: OfficeSetupFiles.
2. Extract the files from OfficeSetupFiles.zip. There are x86 and x64 versions of OSE.EXE and OSETUP.DLL for Office 2010, Office 2013, and Office 2016.
3. Copy the files for the appropriate Office version and architecture into the Updates folder in the installation image. If the Updates folder already contains older versions of the same files, replace the old files with the new ones.
4. Install Office.

An elevation of privilege vulnerability exists when Skype for Business fails to properly handle specific authentication requests.

An authenticated attacker who successfully exploited this vulnerability could steal an authentication hash that can be reused elsewhere. The attacker could then take any action that the user had permissions for, causing possible outcomes that could vary between users.

To exploit the vulnerability, an attacker could invite a user to an instant message session while using a malicious profile image.

The security update addresses the vulnerability by correcting how Skype for Business handles authentication requests.

Microsoft has released an update for Microsoft Windows Server 2008 that provides enhanced security as a defense-in-depth measure.

An information disclosure vulnerability exists when the Microsoft Windows Graphics Component improperly handles objects in memory. An attacker who successfully exploited the vulnerability could obtain information to further compromise the user’s system.

To exploit this vulnerability, an attacker would have to log on to an affected system and run a specially crafted application. The vulnerability would not allow an attacker to execute code or to elevate user rights directly, but it could be used to obtain information that could be used to try to further compromise the affected system.

The update addresses the vulnerability by correcting the way in which the Windows Graphics Component handles objects in memory.

An elevation of privilege vulnerability exists when the Windows kernel-mode driver fails to properly handle objects in memory. An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

To exploit this vulnerability, an attacker would first have to log on to the system. An attacker could then run a specially crafted application to take control of an affected system.

The update addresses the vulnerability by correcting how the Windows kernel-mode driver handles objects in memory.

A denial of service vulnerability exists when Windows Subsystem for Linux improperly handles objects in memory. An attacker who successfully exploited this vulnerability could cause a denial of service against the local system.

A attacker could exploit this vulnerability by running a specially crafted application.

The update addresses the vulnerability by correcting how Windows Subsystem for Linux handles objects in memory.

A security feature bypass vulnerability exists in Device Guard that could allow an attacker to inject malicious code into a Windows PowerShell session. An attacker who successfully exploited this vulnerability could inject code into a trusted PowerShell process to bypass the Device Guard Code Integrity policy on the local machine.

To exploit the vulnerability, an attacker would first have to access the local machine, and then inject malicious code into a script that is trusted by the Code Integrity policy. The injected code would then run with the same trust level as the script and bypass the Code Integrity policy.

The update addresses the vulnerability by correcting how PowerShell exposes functions and processes user supplied code.

A buffer overflow vulnerability exists in the Microsoft JET Database Engine that could allow remote code execution on an affected system. An attacker who successfully exploited this vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

To exploit the vulnerability, a user must open or preview a specially crafted Excel file while using an affected version of Microsoft Windows. In an email attack scenario, an attacker could exploit the vulnerability by sending a specially crafted Excel file to the user, and then convincing the user to open the file.

The security update addresses the vulnerability by modifying how the Microsoft JET Database Engine handles objects in memory.

A buffer overflow vulnerability exists in the Microsoft JET Database Engine that could allow remote code execution on an affected system. An attacker who successfully exploited this vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

To exploit the vulnerability, a user must open or preview a specially crafted Excel file while using an affected version of Microsoft Windows. In an email attack scenario, an attacker could exploit the vulnerability by sending a specially crafted Excel file to the user, and then convincing the user to open the file.

The security update addresses the vulnerability by modifying how the Microsoft JET Database Engine handles objects in memory.

A remote code execution vulnerability exists in the way affected Microsoft scripting engines render when handling objects in memory in Microsoft Edge. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker who successfully exploited the vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

In a web-based attack scenario, an attacker could host a specially crafted website designed to exploit the vulnerability through Microsoft Edge and then convince a user to view the website. An attacker could also embed an ActiveX control marked "safe for initialization" in an application or Microsoft Office document that hosts the scripting rendering engine. The attacker could also take advantage of compromised websites and websites that accept or host user-provided content or advertisements. These websites could contain specially crafted content that could exploit the vulnerability.

The security update addresses the vulnerability by modifying how affected Microsoft scripting engines handle objects in memory.

A remote code execution vulnerability exists when Internet Explorer improperly accesses objects in memory via the Microsoft Windows Text Services Framework. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, the attacker could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

An attacker could host a specially crafted website designed to exploit the vulnerability through Internet Explorer, and then convince a user to view the website. The attacker could also take advantage of compromised websites, or websites that accept or host user-provided content or advertisements, by adding specially crafted content that could exploit the vulnerability. In all cases, however, an attacker would have no way to force users to view the attacker-controlled content. Instead, an attacker would have to convince users to take action, typically by an enticement in an email or instant message, or by getting them to open an attachment sent through email.

The security update addresses the vulnerability by modifying how the Microsoft Windows Text Services Framework handles objects in memory.

A remote code execution vulnerability exists when the Windows font library improperly handles specially crafted embedded fonts. An attacker who successfully exploited the vulnerability could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

There are multiple ways an attacker could exploit the vulnerability:

• In a web-based attack scenario, an attacker could host a specially crafted website that is designed to exploit the vulnerability and then convince users to view the website. An attacker would have no way to force users to view the attacker-controlled content. Instead, an attacker would have to convince users to take action, typically by getting them to click a link in an email or instant message that takes users to the attacker's website, or by opening an attachment sent through email.
• In a file-sharing attack scenario, an attacker could provide a specially crafted document file designed to exploit the vulnerability and then convince users to open the document file.

The security update addresses the vulnerability by correcting how the Windows font library handles embedded fonts.

A remote code execution vulnerability exists when the Windows font library improperly handles specially crafted embedded fonts. An attacker who successfully exploited the vulnerability could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

There are multiple ways an attacker could exploit the vulnerability:

• In a web-based attack scenario, an attacker could host a specially crafted website that is designed to exploit the vulnerability and then convince users to view the website. An attacker would have no way to force users to view the attacker-controlled content. Instead, an attacker would have to convince users to take action, typically by getting them to click a link in an email or instant message that takes users to the attacker's website, or by opening an attachment sent through email.
• In a file-sharing attack scenario, an attacker could provide a specially crafted document file designed to exploit the vulnerability and then convince users to open the document file.

The security update addresses the vulnerability by correcting how the Windows font library handles embedded fonts.

An information disclosure vulnerability exists when the Windows kernel improperly handles objects in memory. An attacker who successfully exploited this vulnerability could obtain information to further compromise the user’s system.

To exploit this vulnerability, an attacker would have to log on to an affected system and run a specially crafted application. The vulnerability would not allow an attacker to execute code or to elevate user rights directly, but it could be used to obtain information that could be used to try to further compromise the affected system.

The update addresses the vulnerability by correcting how the Windows kernel handles objects in memory.

A remote code execution vulnerability exists in the way that certain Windows components handle the loading of DLL files. An attacker who successfully exploited this vulnerability could take complete control of an affected system.

An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

A remote code execution vulnerability exists when Windows Search handles objects in memory. An attacker who successfully exploited this vulnerability could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

To exploit the vulnerability, the attacker could send specially crafted messages to the Windows Search service. An attacker with access to a target computer could exploit this vulnerability to elevate privileges and take control of the computer. Additionally, in an enterprise scenario, a remote unauthenticated attacker could remotely trigger the vulnerability through an SMB connection and then take control of a target computer.

The security update addresses the vulnerability by correcting how Windows Search handles objects in memory.

1. Click Start, click Run, type "regedit" (without the quotation marks), and then click OK.
2. Expand HKEY_LOCAL_MACHINE
3. Expand System, then CurrentControlSet, then Services
4. Click on WSearch
5. Click the File menu and select Export.
6. In the Export Registry File dialog type “WSearch_configuration_backup.reg” and press Save.
7. Double-click the value named Start and change the Value data field to 4
8. Click OK
9. Run the following command at a command prompt running as an administrator:
                  sc stop WSearch

1. Click Start , click Run , type "regedit " (without the quotation marks), and then click OK.
2. Click the File menu and select Import.
3. In the Import Registry File dialog select “WSearch_configuration_backup.reg” and press Open.

1. First a backup copy of the registry keys can be made from a managed deployment script with the following command:
                   regedit /e WSearch_configuration_backup.reg HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WSearch
   
2. Next save the following to a file with a .REG extension (e.g. Disable_WSearch.reg)
                   Windows Registry Editor Version 5.00
   
                   [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WSearch]
                    "Start"=dword:00000004
   
3. Run the registry script created in step 2 on the target machine with the following command:
                    regedit /s Disable_WSearch .reg
   
4. Run the following command at a command prompt running as an administrator:
                     sc stop WSearch

An Information disclosure vulnerability exists when Windows Search improperly handles objects in memory. An attacker who successfully exploited the vulnerability could obtain information to further compromise the user’s system.

To exploit the vulnerability, the attacker could send specially crafted messages to the Windows Search service. Additionally, in an enterprise scenario, a remote unauthenticated attacker could trigger the vulnerability through an SMB connection.

The security update addresses the vulnerability by correcting how Windows Search handles objects in memory.

1. Click Start, click Run, type "regedit" (without the quotation marks), and then click OK.
2. Expand HKEY_LOCAL_MACHINE
3. Expand System, then CurrentControlSet, then Services
4. Click on WSearch
5. Click the File menu and select Export.
6. In the Export Registry File dialog type “WSearch_configuration_backup.reg” and press Save.
7. Double-click the value named Start and change the Value data field to 4
8. Click OK
9. Run the following command at a command prompt running as an administrator:
                  sc stop WSearch

1. Click Start , click Run , type "regedit " (without the quotation marks), and then click OK.
2. Click the File menu and select Import.
3. In the Import Registry File dialog select “WSearch_configuration_backup.reg” and press Open.

1. First a backup copy of the registry keys can be made from a managed deployment script with the following command:
                   regedit /e WSearch_configuration_backup.reg HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WSearch
   
2. Next save the following to a file with a .REG extension (e.g. Disable_WSearch.reg)
                   Windows Registry Editor Version 5.00
   
                   [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WSearch]
                    "Start"=dword:00000004
   
3. Run the registry script created in step 2 on the target machine with the following command:
                    regedit /s Disable_WSearch .reg
   
4. Run the following command at a command prompt running as an administrator:
                     sc stop WSearch