14.6 C
London
Tuesday, September 26, 2017
Home Tags Registry keys

Tag: registry keys

Security Update for Adobe Flash Player (3214628)Published: January 10, 2017Version: 1.0This security update resolves vulnerabilities in Adobe Flash Player when installed on all supported editions of Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, Windows 10, and Windows Server 2016.This security update is rated Critical.

The update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10, Internet Explorer 11, and Microsoft Edge.

For more information, see the Affected Software section.For more information about this update, see Microsoft Knowledge Base Article 3214628.This security update addresses the following vulnerabilities, which are described in Adobe Security Bulletin APSB17-02:CVE-2017-2925, CVE-2017-2926, CVE-2017-2927, CVE-2017-2928, CVE-2017-2930, CVE-2017-2931, CVE-2017-2932, CVE-2017-2933, CVE-2017-2934, CVE-2017-2935, CVE-2017-2936, CVE-2017-2937The following software versions or editions are affected.
Versions or editions that are not listed are either past their support life cycle or are not affected.

To determine the support life cycle for your software version or edition, see Microsoft Support Lifecycle. Operating System Component Aggregate Severity and Impact Updates Replaced*            Windows 8.1 Windows 8.1 for 32-bit Systems Adobe Flash Player(3214628) CriticalRemote Code Execution 3209498 in MS16-154 Windows 8.1 for x64-based Systems Adobe Flash Player(3214628) CriticalRemote Code Execution 3209498 in MS16-154 Windows Server 2012 and Windows Server 2012 R2 Windows Server 2012 Adobe Flash Player(3214628) ModerateRemote Code Execution 3209498 in MS16-154 Windows Server 2012 R2 Adobe Flash Player(3214628) ModerateRemote Code Execution 3209498 in MS16-154 Windows RT 8.1 Windows RT 8.1 Adobe Flash Player(3214628)[1] CriticalRemote Code Execution 3209498 in MS16-154 Windows 10 Windows 10 for 32-bit Systems Adobe Flash Player(3214628)[2] CriticalRemote Code Execution 3209498 in MS16-154 Windows 10 for x64-based Systems Adobe Flash Player(3214628)[2] CriticalRemote Code Execution 3209498 in MS16-154 Windows 10 Version 1511 for 32-bit Systems Adobe Flash Player(3214628)[2] CriticalRemote Code Execution 3209498 in MS16-154 Windows 10 Version 1511 for x64-based Systems Adobe Flash Player(3214628)[2] CriticalRemote Code Execution 3209498 in MS16-154 Windows 10 Version 1607 for 32-bit Systems Adobe Flash Player(3214628)[2] CriticalRemote Code Execution 3209498 in MS16-154 Windows 10 Version 1607 for x64-based Systems Adobe Flash Player(3214628)[2] CriticalRemote Code Execution 3209498 in MS16-154 Windows Server 2016 Windows Server 2016 for 64-bit Systems Adobe Flash Player(3214628)[2] CriticalRemote Code Execution 3209498 in MS16-154 [1]This update is available via Windows Update.[2]The Adobe Flash Player updates for Windows 10 updates are available via Windows Update or via the Microsoft Update Catalog.*The Updates Replaced column shows only the latest update in any chain of superseded updates.

For a comprehensive list of updates replaced, go to the Microsoft Update Catalog, search for the update KB number, and then view update details (updates replaced information is provided on the Package Details tab).How could an attacker exploit these vulnerabilities? In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a specially crafted website that is designed to exploit any of these vulnerabilities through Internet Explorer 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 IE 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 any of these vulnerabilities.
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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.In a web-based attack scenario where the user is using Internet Explorer in the Windows 8-style UI, an attacker would first need to compromise a website already listed in the Compatibility View (CV) list.

An attacker could then host a website that contains specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.

For more information about Internet Explorer and the CV List, please see the MSDN Article, Developer Guidance for websites with content for Adobe Flash Player in Windows 8.Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability.

The following mitigating factors may be helpful in your situation:In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a website that contains a webpage that is used to exploit any of these vulnerabilities.
In addition, compromised websites and websites that accept or host user-provided content or advertisements could contain specially crafted content that could exploit any of these vulnerabilities.
In all cases, however, an attacker would have no way to force users to visit these websites.
Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that takes users to the attacker's website. Internet Explorer in the Windows 8-style UI will only play Flash content from sites listed on the Compatibility View (CV) list.

This restriction requires an attacker to first compromise a website already listed on the CV list.

An attacker could then host specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email. By default, all supported versions of Microsoft Outlook and Windows Live Mail open HTML email messages in the Restricted sites zone.

The Restricted sites zone, which disables scripts and ActiveX controls, helps reduce the risk of an attacker being able to use any of these vulnerabilities to execute malicious code.
If a user clicks a link in an email message, the user could still be vulnerable to exploitation of any of these vulnerabilities through the web-based attack scenario. By default, Internet Explorer on Windows Server 2012 and Windows Server 2012 R2 runs in a restricted mode that is known as Enhanced Security Configuration.

This mode can help reduce the likelihood of the exploitation of these Adobe Flash Player vulnerabilities in Internet Explorer. Workaround refers to a setting or configuration change that would help block known attack vectors before you apply the update.Prevent Adobe Flash Player from running You can disable attempts to instantiate Adobe Flash Player in Internet Explorer and other applications that honor the kill bit feature, such as Office 2007 and Office 2010, by setting the kill bit for the control in the registry. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To set the kill bit for the control in the registry, perform the following steps: Paste the following into a text file and save it with the .reg file extension. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system.You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Note You must restart Internet Explorer for your changes to take effect. Impact of workaround.

There is no impact as long as the object is not intended to be used in Internet Explorer. How to undo the workaround. Delete the registry keys that were added in implementing this workaround.  Prevent Adobe Flash Player from running in Internet Explorer through Group Policy Note The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit, or for an entire domain.

For more information about Group Policy, visit the following Microsoft Web sites: Group Policy Overview What is Group Policy Object Editor? Core Group Policy tools and settings To disable Adobe Flash Player in Internet Explorer through Group Policy, perform the following steps: Note This workaround does not prevent Flash from being invoked from other applications, such as Microsoft Office 2007 or Microsoft Office 2010. Open the Group Policy Management Console and configure the console to work with the appropriate Group Policy object, such as local machine, OU, or domain GPO. Navigate to the following node:Administrative Templates -> Windows Components -> Internet Explorer -> Security Features -> Add-on Management Double-click Turn off Adobe Flash in Internet Explorer and prevent applications from using Internet Explorer technology to instantiate Flash objects. Change the setting to Enabled. Click Apply and then click OK to return to the Group Policy Management Console. Refresh Group Policy on all systems or wait for the next scheduled Group Policy refresh interval for the settings to take effect.  Prevent Adobe Flash Player from running in Office 2010 on affected systems Note This workaround does not prevent Adobe Flash Player from running in Internet Explorer. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. For detailed steps that you can use to prevent a control from running in Internet Explorer, see Microsoft Knowledge Base Article 240797.

Follow the steps in the article to create a Compatibility Flags value in the registry to prevent a COM object from being instantiated in Internet Explorer. To disable Adobe Flash Player in Office 2010 only, set the kill bit for the ActiveX control for Adobe Flash Player in the registry using the following steps: Create a text file named Disable_Flash.reg with the following contents: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM\Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system. Note You must restart Internet Explorer for your changes to take effect. You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Prevent ActiveX controls from running in Office 2007 and Office 2010 To disable all ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, including Adobe Flash Player in Internet Explorer, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then select Disable all controls without notifications. Click OK to save your settings. Impact of workaround. Office documents that use embedded ActiveX controls may not display as intended. How to undo the workaround. To re-enable ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then deselect Disable all controls without notifications. Click OK to save your settings. Set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones You can help protect against exploitation of these vulnerabilities by changing your settings for the Internet security zone to block ActiveX controls and Active Scripting. You can do this by setting your browser security to High. To raise the browsing security level in Internet Explorer, perform the following steps: On the Internet Explorer Tools menu, click Internet Options. In the Internet Options dialog box, click the Security tab, and then click Internet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click Local intranet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click OK to accept the changes and return to Internet Explorer. Note If no slider is visible, click Default Level, and then move the slider to High. Note Setting the level to High may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly even with the security setting set to High. Impact of workaround. There are side effects to blocking ActiveX Controls and Active Scripting. Many websites on the Internet or an intranet use ActiveX or Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use ActiveX Controls to provide menus, ordering forms, or even account statements.

Blocking ActiveX Controls or Active Scripting is a global setting that affects all Internet and intranet sites.
If you do not want to block ActiveX Controls or Active Scripting for such sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone You can help protect against exploitation of these vulnerabilities by changing your settings to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.

To do this, perform the following steps: In Internet Explorer, click Internet Options on the Tools menu. Click the Security tab. Click Internet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click Local intranet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click OK to return to Internet Explorer, and then click OK again. Note Disabling Active Scripting in the Internet and Local intranet security zones may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly. Impact of workaround. There are side effects to prompting before running Active Scripting. Many websites that are on the Internet or on an intranet use Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use Active Scripting to provide menus, ordering forms, or even account statements. Prompting before running Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround.

For each prompt, if you feel you trust the site that you are visiting, click Yes to run Active Scripting.
If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Add sites that you trust to the Internet Explorer Trusted sites zone After you set Internet Explorer to require a prompt before it runs ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone.

This will allow you to continue to use trusted websites exactly as you do today, while helping to protect you from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone. To do this, perform the following steps: In Internet Explorer, click Tools, click Internet Options, and then click the Security tab. In the Select a web content zone to specify its current security settings box, click Trusted Sites, and then click Sites. If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box. In the Add this website to the zone box, type the URL of a site that you trust, and then click Add. Repeat these steps for each site that you want to add to the zone. Click OK two times to accept the changes and return to Internet Explorer. Note Add any sites that you trust not to take malicious action on your system.

Two sites in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com.

These are the sites that will host the update, and they require an ActiveX control to install the update. For Security Update Deployment information, see the Microsoft Knowledge Base article referenced here in the Executive Summary.Microsoft recognizes the efforts of those in the security community who help us protect customers through coordinated vulnerability disclosure.
See Acknowledgments for more information.The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose.
In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages.
Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.V1.0 (January, 10 2017): Bulletin published. Page generated 2017-01-03 9:18Z-08:00.
Security Update for Adobe Flash Player (3209498)Published: December 13, 2016Version: 1.0This security update resolves vulnerabilities in Adobe Flash Player when installed on all supported editions of Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, Windows 10, and Windows Server 2016.This security update is rated Critical.

The update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10, Internet Explorer 11, and Microsoft Edge.

For more information, see the Affected Software section.For more information about this update, see Microsoft Knowledge Base Article 3209498.This security update addresses the following vulnerabilities, which are described in Adobe Security Bulletin APSB16-39:CVE-2016-7867, CVE-2016-7868, CVE-2016-7869, CVE-2016-7870, CVE-2016-7871, CVE-2016-7872, CVE-2016-7873, CVE-2016-7874, CVE-2016-7875, CVE-2016-7876, CVE-2016-7877, CVE-2016-7878, CVE-2016-7879, CVE-2016-7880, CVE-2016-7881, CVE-2016-7890, CVE-2016-7892The following software versions or editions are affected.
Versions or editions that are not listed are either past their support life cycle or are not affected.

To determine the support life cycle for your software version or edition, see Microsoft Support Lifecycle. Operating System Component Aggregate Severity and Impact Updates Replaced*            Windows 8.1 Windows 8.1 for 32-bit Systems Adobe Flash Player(3209498) CriticalRemote Code Execution 3202790 in MS16-141 Windows 8.1 for x64-based Systems Adobe Flash Player(3209498) CriticalRemote Code Execution 3202790 in MS16-141 Windows Server 2012 and Windows Server 2012 R2 Windows Server 2012 Adobe Flash Player(3209498) ModerateRemote Code Execution 3202790 in MS16-141 Windows Server 2012 R2 Adobe Flash Player(3209498) ModerateRemote Code Execution 3202790 in MS16-141 Windows RT 8.1 Windows RT 8.1 Adobe Flash Player(3209498)[1] CriticalRemote Code Execution 3202790 in MS16-141 Windows 10 Windows 10 for 32-bit Systems Adobe Flash Player(3209498)[2] CriticalRemote Code Execution 3202790 in MS16-141 Windows 10 for x64-based Systems Adobe Flash Player(3209498)[2] CriticalRemote Code Execution 3202790 in MS16-141 Windows 10 Version 1511 for 32-bit Systems Adobe Flash Player(3209498)[2] CriticalRemote Code Execution 3202790 in MS16-141 Windows 10 Version 1511 for x64-based Systems Adobe Flash Player(3209498)[2] CriticalRemote Code Execution 3202790 in MS16-141 Windows 10 Version 1607 for 32-bit Systems Adobe Flash Player(3209498)[2] CriticalRemote Code Execution 3202790 in MS16-141 Windows 10 Version 1607 for x64-based Systems Adobe Flash Player(3209498)[2] CriticalRemote Code Execution 3202790 in MS16-141 Windows Server 2016 Windows Server 2016 for 64-bit Systems Adobe Flash Player(3209498)[2] CriticalRemote Code Execution 3202790 in MS16-141 [1]This update is available via Windows Update.[2]The Adobe Flash Player updates for Windows 10 updates are available via Windows Update or via the Microsoft Update Catalog.Note The vulnerabilities discussed in this bulletin affect Windows Server 2016 Technical Preview 5.

To be protected from the vulnerabilities, Microsoft recommends that customers running this operating system apply the current update, which is available exclusively from Windows Update.*The Updates Replaced column shows only the latest update in any chain of superseded updates.

For a comprehensive list of updates replaced, go to the Microsoft Update Catalog, search for the update KB number, and then view update details (updates replaced information is provided on the Package Details tab).How could an attacker exploit these vulnerabilities? In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a specially crafted website that is designed to exploit any of these vulnerabilities through Internet Explorer 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 IE 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 any of these vulnerabilities.
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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.In a web-based attack scenario where the user is using Internet Explorer in the Windows 8-style UI, an attacker would first need to compromise a website already listed in the Compatibility View (CV) list.

An attacker could then host a website that contains specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.

For more information about Internet Explorer and the CV List, please see the MSDN Article, Developer Guidance for websites with content for Adobe Flash Player in Windows 8.Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability.

The following mitigating factors may be helpful in your situation:In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a website that contains a webpage that is used to exploit any of these vulnerabilities.
In addition, compromised websites and websites that accept or host user-provided content or advertisements could contain specially crafted content that could exploit any of these vulnerabilities.
In all cases, however, an attacker would have no way to force users to visit these websites.
Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that takes users to the attacker's website. Internet Explorer in the Windows 8-style UI will only play Flash content from sites listed on the Compatibility View (CV) list.

This restriction requires an attacker to first compromise a website already listed on the CV list.

An attacker could then host specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email. By default, all supported versions of Microsoft Outlook and Windows Live Mail open HTML email messages in the Restricted sites zone.

The Restricted sites zone, which disables scripts and ActiveX controls, helps reduce the risk of an attacker being able to use any of these vulnerabilities to execute malicious code.
If a user clicks a link in an email message, the user could still be vulnerable to exploitation of any of these vulnerabilities through the web-based attack scenario. By default, Internet Explorer on Windows Server 2012 and Windows Server 2012 R2 runs in a restricted mode that is known as Enhanced Security Configuration.

This mode can help reduce the likelihood of the exploitation of these Adobe Flash Player vulnerabilities in Internet Explorer. Workaround refers to a setting or configuration change that would help block known attack vectors before you apply the update.Prevent Adobe Flash Player from running You can disable attempts to instantiate Adobe Flash Player in Internet Explorer and other applications that honor the kill bit feature, such as Office 2007 and Office 2010, by setting the kill bit for the control in the registry. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To set the kill bit for the control in the registry, perform the following steps: Paste the following into a text file and save it with the .reg file extension. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system.You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Note You must restart Internet Explorer for your changes to take effect. Impact of workaround.

There is no impact as long as the object is not intended to be used in Internet Explorer. How to undo the workaround. Delete the registry keys that were added in implementing this workaround.  Prevent Adobe Flash Player from running in Internet Explorer through Group Policy Note The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit, or for an entire domain.

For more information about Group Policy, visit the following Microsoft Web sites: Group Policy Overview What is Group Policy Object Editor? Core Group Policy tools and settings To disable Adobe Flash Player in Internet Explorer through Group Policy, perform the following steps: Note This workaround does not prevent Flash from being invoked from other applications, such as Microsoft Office 2007 or Microsoft Office 2010. Open the Group Policy Management Console and configure the console to work with the appropriate Group Policy object, such as local machine, OU, or domain GPO. Navigate to the following node:Administrative Templates -> Windows Components -> Internet Explorer -> Security Features -> Add-on Management Double-click Turn off Adobe Flash in Internet Explorer and prevent applications from using Internet Explorer technology to instantiate Flash objects. Change the setting to Enabled. Click Apply and then click OK to return to the Group Policy Management Console. Refresh Group Policy on all systems or wait for the next scheduled Group Policy refresh interval for the settings to take effect.  Prevent Adobe Flash Player from running in Office 2010 on affected systems Note This workaround does not prevent Adobe Flash Player from running in Internet Explorer. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. For detailed steps that you can use to prevent a control from running in Internet Explorer, see Microsoft Knowledge Base Article 240797.

Follow the steps in the article to create a Compatibility Flags value in the registry to prevent a COM object from being instantiated in Internet Explorer. To disable Adobe Flash Player in Office 2010 only, set the kill bit for the ActiveX control for Adobe Flash Player in the registry using the following steps: Create a text file named Disable_Flash.reg with the following contents: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM\Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system. Note You must restart Internet Explorer for your changes to take effect. You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Prevent ActiveX controls from running in Office 2007 and Office 2010 To disable all ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, including Adobe Flash Player in Internet Explorer, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then select Disable all controls without notifications. Click OK to save your settings. Impact of workaround. Office documents that use embedded ActiveX controls may not display as intended. How to undo the workaround. To re-enable ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then deselect Disable all controls without notifications. Click OK to save your settings. Set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones You can help protect against exploitation of these vulnerabilities by changing your settings for the Internet security zone to block ActiveX controls and Active Scripting. You can do this by setting your browser security to High. To raise the browsing security level in Internet Explorer, perform the following steps: On the Internet Explorer Tools menu, click Internet Options. In the Internet Options dialog box, click the Security tab, and then click Internet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click Local intranet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click OK to accept the changes and return to Internet Explorer. Note If no slider is visible, click Default Level, and then move the slider to High. Note Setting the level to High may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly even with the security setting set to High. Impact of workaround. There are side effects to blocking ActiveX Controls and Active Scripting. Many websites on the Internet or an intranet use ActiveX or Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use ActiveX Controls to provide menus, ordering forms, or even account statements.

Blocking ActiveX Controls or Active Scripting is a global setting that affects all Internet and intranet sites.
If you do not want to block ActiveX Controls or Active Scripting for such sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone You can help protect against exploitation of these vulnerabilities by changing your settings to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.

To do this, perform the following steps: In Internet Explorer, click Internet Options on the Tools menu. Click the Security tab. Click Internet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click Local intranet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click OK to return to Internet Explorer, and then click OK again. Note Disabling Active Scripting in the Internet and Local intranet security zones may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly. Impact of workaround. There are side effects to prompting before running Active Scripting. Many websites that are on the Internet or on an intranet use Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use Active Scripting to provide menus, ordering forms, or even account statements. Prompting before running Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround.

For each prompt, if you feel you trust the site that you are visiting, click Yes to run Active Scripting.
If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Add sites that you trust to the Internet Explorer Trusted sites zone After you set Internet Explorer to require a prompt before it runs ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone.

This will allow you to continue to use trusted websites exactly as you do today, while helping to protect you from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone. To do this, perform the following steps: In Internet Explorer, click Tools, click Internet Options, and then click the Security tab. In the Select a web content zone to specify its current security settings box, click Trusted Sites, and then click Sites. If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box. In the Add this website to the zone box, type the URL of a site that you trust, and then click Add. Repeat these steps for each site that you want to add to the zone. Click OK two times to accept the changes and return to Internet Explorer. Note Add any sites that you trust not to take malicious action on your system.

Two sites in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com.

These are the sites that will host the update, and they require an ActiveX control to install the update. For Security Update Deployment information, see the Microsoft Knowledge Base article referenced here in the Executive Summary.Microsoft recognizes the efforts of those in the security community who help us protect customers through coordinated vulnerability disclosure.
See Acknowledgments for more information.The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose.
In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages.
Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.V1.0 (December 13, 2016): Bulletin published. Page generated 2016-12-13 9:58Z-08:00.
On 28 October, the cryptocurrency world saw the emergence of a new player, the Zcash (ZEC) cryptocurrency.
Its developers have described it rather figuratively: “If Bitcoin is like HTTP for money, Zcash is HTTPS.” They continue by noting that “unlike Bitcoin, Zcash transactions can be shielded to hide the sender, the recipient and value of all transactions.” The cryptocurrency market has been looking for this level of anonymity for a while now, so ZEC has attracted considerable interest from investors, miners and cybercriminals alike.
Several major cryptocurrency exchanges were quick to offer support for the new currency. Zcash got off to a flying start; within the first few hours, 1 ZEC reached $30,000.
It should be pointed out, however, that there were only a few dozen coins in existence at that time, so the actual turnover was very low. In the following days, ZEC’s value steadily declined against Bitcoin.

At the time of writing, it had leveled out temporarily at 0.07 – 0.01 ZEC/BTC (around $70).

Despite this dramatic drop from the initial values (which was anticipated), Zcash mining remains among the most profitable compared to other cryptocurrencies. Ranking of cryptocurrency mining profitability, as reported by the CoinWarz website This has led to the revival of a particular type of cybercriminal activity – the creation of botnets for mining.

A few years ago, botnets were created for bitcoin mining, but the business all but died out after it became only marginally profitable. In November, we recorded several incidents where Zcash mining software was installed on users’ computers without permission.

Because these software programs are not malicious in themselves, most anti-malware programs do not react to them, or detect them as potentially unwanted programs (PUP). Kaspersky Lab products detect them as not-a-virus:RiskTool.Win64.BitCoinMiner. Cybercriminals use rather conventional ways to distribute mining software – they are installed under the guise of other legitimate programs, such as pirated software distributed via torrents.
So far, we have not seen any cases of mass-mailings or vulnerabilities in websites being exploited to distribute mining software; however, provided mining remains as profitable as it is now, this is only a matter of time.

The software can also be installed on computers that were infected earlier and became part of a for-rent botnet. The most popular mining software to date is nheqminer from the mining pool Micemash.
It has two known variations: one earns payments in bitcoins, the other in Zcash.

Both are detected by Kaspersky Lab products, with the respective verdicts not-a-virus:RiskTool.Win64.BitCoinMiner.bez and not-a-virus:RiskTool.Win64.BitCoinMiner.bfa. All that cybercriminals need to do to start profiting from a mining program on infected computers is to launch it and provide details of their own bitcoin or Zcash wallets.

After that, the “coin mining” profit created by the pool will be credited to the cybercriminals’ addresses, from where it can be withdrawn and exchanged for US dollars or other cryptocurrencies.

This is what allows us to ‘snoop’ on some of the wallets used by cybercriminals. Here’s just one example: Using a wallet’s address, we can find out how much money arrived and from which source (i.e. the mining pool) (https://explorer.zcha.in/accounts/t1eVeeBYfPPLgonvi1zk8e9SnrhZdoCBAeM) We see that the address was created on 31 October, just a couple of days after Zcash launched, and payments are still being made to it at the current time. You may be wondering what happened to the promised anonymity.

Actually, there are two types of wallets in Zcash: completely private purses (z-address) and public wallets like that shown above (t-address).

At the current time, the completely private wallets are not very popular (they are not supported by exchanges), and are only used to store around 1% of all existing Zcash coins. We found approximately 1,000 unique users who have some version of the Zcash miner installed on their computers under a different name, which suggests these computers were infected without their owners’ knowledge.

An average computer can mine about 20 hashes per second; a thousand infected computers can mine about 20,000 hashes a second.

At current prices, that equals about $6,200 a month, or $75,000 a year in net profits. Here are just a few real-life examples of the names used by these program and where they are installed on infected computers: diskmngr.exemssys.exeC:\system\taskmngr.exesystem.exensdiag.exetaskmngr.exesvchost.exeC:\Users\[username]\AppData\Roaming\MetaData\mdls\windlw\mDir_r\rhost.exeqzwzfx.exeC:\Users\[username]\AppData\Local\Temp\afolder\mscor.exeC:\Program Files\Common Files\nheqminer64.exeC:\Windows\Logs\Logsfiles64\conhost.exeapupd.exe As you can see, the names of many mining programs coincide with those of legitimate applications, but the installation location is different.

For instance, the legitimate Windows Task Manager app (taskmngr.exe) should be located in the system folder C:\Windows\System32 and not in C:\system. To ensure that the mining program is launched each time the operating system starts, the necessary records are added either to Task Scheduler or to the registry auto-run keys. Here are some examples of these records: Task Scheduler\Microsoft\Windows Defender\MineHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Miner A couple of detected websites distributing mining programs: http://execsuccessnow[.]com/wp-includes/m/nheqminer.exehttps://a.pomf[.]cat/qzwzfx.exe Additional DLLs are required for the mining program to work.

These DLLs, shown below, are installed along with the mining program. cpu_tromp_AVX.dllcpu_tromp_SSE2.dllcudart64_80.dllcuda_tromp.dlllogsetuplib.dllmsvcp120.dllmsvcr120.dll So, what are the threats facing a user who is unaware that their computer is being used for cryptocurrency mining? Firstly, these operations are power hungry: the computer uses up a lot more electricity, which, in some countries, could mean the user ends up with a hefty electricity bill. Secondly, a mining program typically devours up to 90% of the system’s RAM, which dramatically slows down both the operating system and other applications running on the computer. Not exactly what you want from your computer. To prevent the installation of mining programs, Kaspersky Lab users should check their security products and make sure detection of unwanted software is enabled. All other users are encouraged, at the very least, to check their folders and registry keys for suspicious files and records.
Security Update for Adobe Flash Player (3202790)Published: November 8, 2016Version: 1.0This security update resolves vulnerabilities in Adobe Flash Player when installed on all supported editions of Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, Windows 10, and Windows Server 2016.This security update is rated Critical.

The update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10, Internet Explorer 11, and Microsoft Edge.

For more information, see the Affected Software section.For more information about this update, see Microsoft Knowledge Base Article 3202790.This security update addresses the following vulnerabilities, which are described in Adobe Security Bulletin APSB16-37:CVE-2016-7857, CVE-2016-7858, CVE-2016-7859, CVE-2016-7860, CVE-2016-7861, CVE-2016-7862, CVE-2016-7863, CVE-2016-7864, CVE-2016-7865The following software versions or editions are affected.
Versions or editions that are not listed are either past their support life cycle or are not affected.

To determine the support life cycle for your software version or edition, see Microsoft Support Lifecycle. Operating System Component Aggregate Severity and Impact Updates Replaced*            Windows 8.1 Windows 8.1 for 32-bit Systems Adobe Flash Player(3202790) CriticalRemote Code Execution 3201860 in MS16-128 Windows 8.1 for x64-based Systems Adobe Flash Player(3202790) CriticalRemote Code Execution 3201860 in MS16-128 Windows Server 2012 and Windows Server 2012 R2 Windows Server 2012 Adobe Flash Player(3202790) ModerateRemote Code Execution 3201860 in MS16-128 Windows Server 2012 R2 Adobe Flash Player(3202790) ModerateRemote Code Execution 3201860 in MS16-128 Windows RT 8.1 Windows RT 8.1 Adobe Flash Player(3202790)[1] CriticalRemote Code Execution 3201860 in MS16-128 Windows 10 Windows 10 for 32-bit Systems Adobe Flash Player(3202790)[2] CriticalRemote Code Execution 3201860 in MS16-128 Windows 10 for x64-based Systems Adobe Flash Player(3202790)[2] CriticalRemote Code Execution 3201860 in MS16-128 Windows 10 Version 1511 for 32-bit Systems Adobe Flash Player(3202790)[2] CriticalRemote Code Execution 3201860 in MS16-128 Windows 10 Version 1511 for x64-based Systems Adobe Flash Player(3202790)[2] CriticalRemote Code Execution 3201860 in MS16-128 Windows 10 Version 1607 for 32-bit Systems Adobe Flash Player(3202790)[2] CriticalRemote Code Execution 3201860 in MS16-128 Windows 10 Version 1607 for x64-based Systems Adobe Flash Player(3202790)[2] CriticalRemote Code Execution 3201860 in MS16-128 Windows Server 2016 Windows Server 2016 for 64-bit Systems Adobe Flash Player(3202790)[2] CriticalRemote Code Execution 3201860 in MS16-128 [1]This update is available via Windows Update.[2]The Adobe Flash Player updates for Windows 10 updates are available via Windows Update or via the Microsoft Update Catalog.Note The vulnerabilities discussed in this bulletin affect Windows Server 2016 Technical Preview 5.

To be protected from the vulnerabilities, Microsoft recommends that customers running this operating system apply the current update, which is available exclusively from Windows Update.*The Updates Replaced column shows only the latest update in any chain of superseded updates.

For a comprehensive list of updates replaced, go to the Microsoft Update Catalog, search for the update KB number, and then view update details (updates replaced information is provided on the Package Details tab).How could an attacker exploit these vulnerabilities? In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a specially crafted website that is designed to exploit any of these vulnerabilities through Internet Explorer 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 IE 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 any of these vulnerabilities.
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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.In a web-based attack scenario where the user is using Internet Explorer in the Windows 8-style UI, an attacker would first need to compromise a website already listed in the Compatibility View (CV) list.

An attacker could then host a website that contains specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.

For more information about Internet Explorer and the CV List, please see the MSDN Article, Developer Guidance for websites with content for Adobe Flash Player in Windows 8.Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability.

The following mitigating factors may be helpful in your situation:In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a website that contains a webpage that is used to exploit any of these vulnerabilities.
In addition, compromised websites and websites that accept or host user-provided content or advertisements could contain specially crafted content that could exploit any of these vulnerabilities.
In all cases, however, an attacker would have no way to force users to visit these websites.
Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that takes users to the attacker's website. Internet Explorer in the Windows 8-style UI will only play Flash content from sites listed on the Compatibility View (CV) list.

This restriction requires an attacker to first compromise a website already listed on the CV list.

An attacker could then host specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email. By default, all supported versions of Microsoft Outlook and Windows Live Mail open HTML email messages in the Restricted sites zone.

The Restricted sites zone, which disables scripts and ActiveX controls, helps reduce the risk of an attacker being able to use any of these vulnerabilities to execute malicious code.
If a user clicks a link in an email message, the user could still be vulnerable to exploitation of any of these vulnerabilities through the web-based attack scenario. By default, Internet Explorer on Windows Server 2012 and Windows Server 2012 R2 runs in a restricted mode that is known as Enhanced Security Configuration.

This mode can help reduce the likelihood of the exploitation of these Adobe Flash Player vulnerabilities in Internet Explorer. Workaround refers to a setting or configuration change that would help block known attack vectors before you apply the update.Prevent Adobe Flash Player from running You can disable attempts to instantiate Adobe Flash Player in Internet Explorer and other applications that honor the kill bit feature, such as Office 2007 and Office 2010, by setting the kill bit for the control in the registry. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To set the kill bit for the control in the registry, perform the following steps: Paste the following into a text file and save it with the .reg file extension. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system.You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Note You must restart Internet Explorer for your changes to take effect. Impact of workaround.

There is no impact as long as the object is not intended to be used in Internet Explorer. How to undo the workaround. Delete the registry keys that were added in implementing this workaround.  Prevent Adobe Flash Player from running in Internet Explorer through Group Policy Note The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit, or for an entire domain.

For more information about Group Policy, visit the following Microsoft Web sites: Group Policy Overview What is Group Policy Object Editor? Core Group Policy tools and settings To disable Adobe Flash Player in Internet Explorer through Group Policy, perform the following steps: Note This workaround does not prevent Flash from being invoked from other applications, such as Microsoft Office 2007 or Microsoft Office 2010. Open the Group Policy Management Console and configure the console to work with the appropriate Group Policy object, such as local machine, OU, or domain GPO. Navigate to the following node:Administrative Templates -> Windows Components -> Internet Explorer -> Security Features -> Add-on Management Double-click Turn off Adobe Flash in Internet Explorer and prevent applications from using Internet Explorer technology to instantiate Flash objects. Change the setting to Enabled. Click Apply and then click OK to return to the Group Policy Management Console. Refresh Group Policy on all systems or wait for the next scheduled Group Policy refresh interval for the settings to take effect.  Prevent Adobe Flash Player from running in Office 2010 on affected systems Note This workaround does not prevent Adobe Flash Player from running in Internet Explorer. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. For detailed steps that you can use to prevent a control from running in Internet Explorer, see Microsoft Knowledge Base Article 240797.

Follow the steps in the article to create a Compatibility Flags value in the registry to prevent a COM object from being instantiated in Internet Explorer. To disable Adobe Flash Player in Office 2010 only, set the kill bit for the ActiveX control for Adobe Flash Player in the registry using the following steps: Create a text file named Disable_Flash.reg with the following contents: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM\Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system. Note You must restart Internet Explorer for your changes to take effect. You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Prevent ActiveX controls from running in Office 2007 and Office 2010 To disable all ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, including Adobe Flash Player in Internet Explorer, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then select Disable all controls without notifications. Click OK to save your settings. Impact of workaround. Office documents that use embedded ActiveX controls may not display as intended. How to undo the workaround. To re-enable ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then deselect Disable all controls without notifications. Click OK to save your settings. Set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones You can help protect against exploitation of these vulnerabilities by changing your settings for the Internet security zone to block ActiveX controls and Active Scripting. You can do this by setting your browser security to High. To raise the browsing security level in Internet Explorer, perform the following steps: On the Internet Explorer Tools menu, click Internet Options. In the Internet Options dialog box, click the Security tab, and then click Internet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click Local intranet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click OK to accept the changes and return to Internet Explorer. Note If no slider is visible, click Default Level, and then move the slider to High. Note Setting the level to High may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly even with the security setting set to High. Impact of workaround. There are side effects to blocking ActiveX Controls and Active Scripting. Many websites on the Internet or an intranet use ActiveX or Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use ActiveX Controls to provide menus, ordering forms, or even account statements.

Blocking ActiveX Controls or Active Scripting is a global setting that affects all Internet and intranet sites.
If you do not want to block ActiveX Controls or Active Scripting for such sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone You can help protect against exploitation of these vulnerabilities by changing your settings to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.

To do this, perform the following steps: In Internet Explorer, click Internet Options on the Tools menu. Click the Security tab. Click Internet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click Local intranet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click OK to return to Internet Explorer, and then click OK again. Note Disabling Active Scripting in the Internet and Local intranet security zones may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly. Impact of workaround. There are side effects to prompting before running Active Scripting. Many websites that are on the Internet or on an intranet use Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use Active Scripting to provide menus, ordering forms, or even account statements. Prompting before running Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround.

For each prompt, if you feel you trust the site that you are visiting, click Yes to run Active Scripting.
If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Add sites that you trust to the Internet Explorer Trusted sites zone After you set Internet Explorer to require a prompt before it runs ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone.

This will allow you to continue to use trusted websites exactly as you do today, while helping to protect you from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone. To do this, perform the following steps: In Internet Explorer, click Tools, click Internet Options, and then click the Security tab. In the Select a web content zone to specify its current security settings box, click Trusted Sites, and then click Sites. If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box. In the Add this website to the zone box, type the URL of a site that you trust, and then click Add. Repeat these steps for each site that you want to add to the zone. Click OK two times to accept the changes and return to Internet Explorer. Note Add any sites that you trust not to take malicious action on your system.

Two sites in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com.

These are the sites that will host the update, and they require an ActiveX control to install the update. For Security Update Deployment information, see the Microsoft Knowledge Base article referenced here in the Executive Summary.Microsoft recognizes the efforts of those in the security community who help us protect customers through coordinated vulnerability disclosure.
See Acknowledgments for more information.The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose.
In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages.
Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.V1.0 (November 8, 2016): Bulletin published. Page generated 2016-11-08 07:31-08:00.
Security Update for Adobe Flash Player (3201860)Published: October 27, 2016Version: 1.0This security update resolves a vulnerability in Adobe Flash Player when installed on all supported editions of Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, and Windows 10.This security update is rated Critical.

The update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10, Internet Explorer 11, and Microsoft Edge.

For more information, see the Affected Software section.For more information about this update, see Microsoft Knowledge Base Article 3201860.This security update addresses the following vulnerabilities, which are described in Adobe Security Bulletin APSB16-36:CVE-2016-7855The following software versions or editions are affected.
Versions or editions that are not listed are either past their support life cycle or are not affected.

To determine the support life cycle for your software version or edition, see Microsoft Support Lifecycle. Operating System Component Aggregate Severity and Impact Updates Replaced*            Windows 8.1 Windows 8.1 for 32-bit Systems Adobe Flash Player(3201860) CriticalRemote Code Execution 3194343 in MS16-127 Windows 8.1 for x64-based Systems Adobe Flash Player(3201860) CriticalRemote Code Execution 3194343 in MS16-127 Windows Server 2012 and Windows Server 2012 R2 Windows Server 2012 Adobe Flash Player(3201860) ModerateRemote Code Execution 3194343 in MS16-127 Windows Server 2012 R2 Adobe Flash Player(3201860) ModerateRemote Code Execution 3194343 in MS16-127 Windows RT 8.1 Windows RT 8.1 Adobe Flash Player(3201860)[1] CriticalRemote Code Execution 3194343 in MS16-127 Windows 10 Windows 10 for 32-bit Systems Adobe Flash Player(3201860)[2] CriticalRemote Code Execution 3194343 in MS16-127 Windows 10 for x64-based Systems Adobe Flash Player(3201860)[2] CriticalRemote Code Execution 3194343 in MS16-127 Windows 10 Version 1511 for 32-bit Systems Adobe Flash Player(3201860)[2] CriticalRemote Code Execution 3194343 in MS16-127 Windows 10 Version 1511 for x64-based Systems Adobe Flash Player(3201860)[2] CriticalRemote Code Execution 3194343 in MS16-127 Windows 10 Version 1607 for 32-bit Systems Adobe Flash Player(3201860)[2] CriticalRemote Code Execution 3194343 in MS16-127 Windows 10 Version 1607 for x64-based Systems Adobe Flash Player(3201860)[2] CriticalRemote Code Execution 3194343 in MS16-127 [1]This update is available via Windows Update.[2]The Adobe Flash Player updates for Windows 10 updates are available via Windows Update or via the Microsoft Update Catalog.Note The vulnerabilities discussed in this bulletin affect Windows Server 2016 Technical Preview 5.

To be protected from the vulnerabilities, Microsoft recommends that customers running this operating system apply the current update, which is available exclusively from Windows Update.*The Updates Replaced column shows only the latest update in any chain of superseded updates.

For a comprehensive list of updates replaced, go to the Microsoft Update Catalog, search for the update KB number, and then view update details (updates replaced information is provided on the Package Details tab).How could an attacker exploit these vulnerabilities? In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a specially crafted website that is designed to exploit any of these vulnerabilities through Internet Explorer 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 IE 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 any of these vulnerabilities.
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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.In a web-based attack scenario where the user is using Internet Explorer in the Windows 8-style UI, an attacker would first need to compromise a website already listed in the Compatibility View (CV) list.

An attacker could then host a website that contains specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.

For more information about Internet Explorer and the CV List, please see the MSDN Article, Developer Guidance for websites with content for Adobe Flash Player in Windows 8.Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability.

The following mitigating factors may be helpful in your situation:In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a website that contains a webpage that is used to exploit any of these vulnerabilities.
In addition, compromised websites and websites that accept or host user-provided content or advertisements could contain specially crafted content that could exploit any of these vulnerabilities.
In all cases, however, an attacker would have no way to force users to visit these websites.
Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that takes users to the attacker's website. Internet Explorer in the Windows 8-style UI will only play Flash content from sites listed on the Compatibility View (CV) list.

This restriction requires an attacker to first compromise a website already listed on the CV list.

An attacker could then host specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email. By default, all supported versions of Microsoft Outlook and Windows Live Mail open HTML email messages in the Restricted sites zone.

The Restricted sites zone, which disables scripts and ActiveX controls, helps reduce the risk of an attacker being able to use any of these vulnerabilities to execute malicious code.
If a user clicks a link in an email message, the user could still be vulnerable to exploitation of any of these vulnerabilities through the web-based attack scenario. By default, Internet Explorer on Windows Server 2012 and Windows Server 2012 R2 runs in a restricted mode that is known as Enhanced Security Configuration.

This mode can help reduce the likelihood of the exploitation of these Adobe Flash Player vulnerabilities in Internet Explorer. Workaround refers to a setting or configuration change that would help block known attack vectors before you apply the update.Prevent Adobe Flash Player from running You can disable attempts to instantiate Adobe Flash Player in Internet Explorer and other applications that honor the kill bit feature, such as Office 2007 and Office 2010, by setting the kill bit for the control in the registry. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To set the kill bit for the control in the registry, perform the following steps: Paste the following into a text file and save it with the .reg file extension. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system.You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Note You must restart Internet Explorer for your changes to take effect. Impact of workaround.

There is no impact as long as the object is not intended to be used in Internet Explorer. How to undo the workaround. Delete the registry keys that were added in implementing this workaround.  Prevent Adobe Flash Player from running in Internet Explorer through Group Policy Note The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit, or for an entire domain.

For more information about Group Policy, visit the following Microsoft Web sites: Group Policy Overview What is Group Policy Object Editor? Core Group Policy tools and settings To disable Adobe Flash Player in Internet Explorer through Group Policy, perform the following steps: Note This workaround does not prevent Flash from being invoked from other applications, such as Microsoft Office 2007 or Microsoft Office 2010. Open the Group Policy Management Console and configure the console to work with the appropriate Group Policy object, such as local machine, OU, or domain GPO. Navigate to the following node:Administrative Templates -> Windows Components -> Internet Explorer -> Security Features -> Add-on Management Double-click Turn off Adobe Flash in Internet Explorer and prevent applications from using Internet Explorer technology to instantiate Flash objects. Change the setting to Enabled. Click Apply and then click OK to return to the Group Policy Management Console. Refresh Group Policy on all systems or wait for the next scheduled Group Policy refresh interval for the settings to take effect.  Prevent Adobe Flash Player from running in Office 2010 on affected systems Note This workaround does not prevent Adobe Flash Player from running in Internet Explorer. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. For detailed steps that you can use to prevent a control from running in Internet Explorer, see Microsoft Knowledge Base Article 240797.

Follow the steps in the article to create a Compatibility Flags value in the registry to prevent a COM object from being instantiated in Internet Explorer. To disable Adobe Flash Player in Office 2010 only, set the kill bit for the ActiveX control for Adobe Flash Player in the registry using the following steps: Create a text file named Disable_Flash.reg with the following contents: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM\Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system. Note You must restart Internet Explorer for your changes to take effect. You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Prevent ActiveX controls from running in Office 2007 and Office 2010 To disable all ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, including Adobe Flash Player in Internet Explorer, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then select Disable all controls without notifications. Click OK to save your settings. Impact of workaround. Office documents that use embedded ActiveX controls may not display as intended. How to undo the workaround. To re-enable ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then deselect Disable all controls without notifications. Click OK to save your settings. Set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones You can help protect against exploitation of these vulnerabilities by changing your settings for the Internet security zone to block ActiveX controls and Active Scripting. You can do this by setting your browser security to High. To raise the browsing security level in Internet Explorer, perform the following steps: On the Internet Explorer Tools menu, click Internet Options. In the Internet Options dialog box, click the Security tab, and then click Internet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click Local intranet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click OK to accept the changes and return to Internet Explorer. Note If no slider is visible, click Default Level, and then move the slider to High. Note Setting the level to High may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly even with the security setting set to High. Impact of workaround. There are side effects to blocking ActiveX Controls and Active Scripting. Many websites on the Internet or an intranet use ActiveX or Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use ActiveX Controls to provide menus, ordering forms, or even account statements.

Blocking ActiveX Controls or Active Scripting is a global setting that affects all Internet and intranet sites.
If you do not want to block ActiveX Controls or Active Scripting for such sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone You can help protect against exploitation of these vulnerabilities by changing your settings to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.

To do this, perform the following steps: In Internet Explorer, click Internet Options on the Tools menu. Click the Security tab. Click Internet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click Local intranet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click OK to return to Internet Explorer, and then click OK again. Note Disabling Active Scripting in the Internet and Local intranet security zones may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly. Impact of workaround. There are side effects to prompting before running Active Scripting. Many websites that are on the Internet or on an intranet use Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use Active Scripting to provide menus, ordering forms, or even account statements. Prompting before running Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround.

For each prompt, if you feel you trust the site that you are visiting, click Yes to run Active Scripting.
If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Add sites that you trust to the Internet Explorer Trusted sites zone After you set Internet Explorer to require a prompt before it runs ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone.

This will allow you to continue to use trusted websites exactly as you do today, while helping to protect you from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone. To do this, perform the following steps: In Internet Explorer, click Tools, click Internet Options, and then click the Security tab. In the Select a web content zone to specify its current security settings box, click Trusted Sites, and then click Sites. If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box. In the Add this website to the zone box, type the URL of a site that you trust, and then click Add. Repeat these steps for each site that you want to add to the zone. Click OK two times to accept the changes and return to Internet Explorer. Note Add any sites that you trust not to take malicious action on your system.

Two sites in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com.

These are the sites that will host the update, and they require an ActiveX control to install the update. For Security Update Deployment information, see the Microsoft Knowledge Base article referenced here in the Executive Summary.Microsoft recognizes the efforts of those in the security community who help us protect customers through coordinated vulnerability disclosure.
See Acknowledgments for more information.The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose.
In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages.
Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.V1.0 (October 26, 2016): Bulletin published. Page generated 2016-10-27 9:19Z-07:00.
Security Update for Adobe Flash Player (3194343)Published: October 11, 2016Version: 1.0This security update resolves vulnerabilities in Adobe Flash Player when installed on all supported editions of Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, and Windows 10.This security update is rated Critical.

The update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10, Internet Explorer 11, and Microsoft Edge.

For more information, see the Affected Software section.For more information about this update, see Microsoft Knowledge Base Article 3194343.This security update addresses the following vulnerabilities, which are described in Adobe Security Bulletin APSB16-32:CVE-2016-4273, CVE-2016-4286, CVE-2016-6981, CVE-2016-6982, CVE-2016-6983, CVE-2016-6984, CVE-2016-6985, CVE-2016-6986, CVE-2016-6987, CVE-2016-6989, CVE-2016-6990, CVE-2016-6991, CVE-2016-6992The following software versions or editions are affected.
Versions or editions that are not listed are either past their support life cycle or are not affected.

To determine the support life cycle for your software version or edition, see Microsoft Support Lifecycle. Operating System Component Aggregate Severity and Impact Updates Replaced*            Windows 8.1 Windows 8.1 for 32-bit Systems Adobe Flash Player(3194343) CriticalRemote Code Execution 3188128 in MS16-117 Windows 8.1 for x64-based Systems Adobe Flash Player(3194343) CriticalRemote Code Execution 3188128 in MS16-117 Windows Server 2012 and Windows Server 2012 R2 Windows Server 2012 Adobe Flash Player(3194343) ModerateRemote Code Execution 3188128 in MS16-117 Windows Server 2012 R2 Adobe Flash Player(3194343) ModerateRemote Code Execution 3188128 in MS16-117 Windows RT 8.1 Windows RT 8.1 Adobe Flash Player(3194343)[1] CriticalRemote Code Execution 3188128 in MS16-117 Windows 10 Windows 10 for 32-bit Systems Adobe Flash Player(3194343)[2] CriticalRemote Code Execution 3188128 in MS16-117 Windows 10 for x64-based Systems Adobe Flash Player(3194343)[2] CriticalRemote Code Execution 3188128 in MS16-117 Windows 10 Version 1511 for 32-bit Systems Adobe Flash Player(3194343)[2] CriticalRemote Code Execution 3188128 in MS16-117 Windows 10 Version 1511 for x64-based Systems Adobe Flash Player(3194343)[2] CriticalRemote Code Execution 3188128 in MS16-117 Windows 10 Version 1607 for 32-bit Systems Adobe Flash Player(3194343)[2] CriticalRemote Code Execution 3188128 in MS16-117 Windows 10 Version 1607 for x64-based Systems Adobe Flash Player(3194343)[2] CriticalRemote Code Execution 3188128 in MS16-117 [1]This update is available via Windows Update.[2]The Adobe Flash Player updates for Windows 10 updates are available via Windows Update or via the Microsoft Update Catalog.Note The vulnerabilities discussed in this bulletin affect Windows Server 2016 Technical Preview 5.

To be protected from the vulnerabilities, Microsoft recommends that customers running this operating system apply the current update, which is available exclusively from Windows Update.*The Updates Replaced column shows only the latest update in any chain of superseded updates.

For a comprehensive list of updates replaced, go to the Microsoft Update Catalog, search for the update KB number, and then view update details (updates replaced information is provided on the Package Details tab).How could an attacker exploit these vulnerabilities? In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a specially crafted website that is designed to exploit any of these vulnerabilities through Internet Explorer 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 IE 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 any of these vulnerabilities.
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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.In a web-based attack scenario where the user is using Internet Explorer in the Windows 8-style UI, an attacker would first need to compromise a website already listed in the Compatibility View (CV) list.

An attacker could then host a website that contains specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.

For more information about Internet Explorer and the CV List, please see the MSDN Article, Developer Guidance for websites with content for Adobe Flash Player in Windows 8.Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability.

The following mitigating factors may be helpful in your situation:In a web-based attack scenario where the user is using Internet Explorer for the desktop, an attacker could host a website that contains a webpage that is used to exploit any of these vulnerabilities.
In addition, compromised websites and websites that accept or host user-provided content or advertisements could contain specially crafted content that could exploit any of these vulnerabilities.
In all cases, however, an attacker would have no way to force users to visit these websites.
Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that takes users to the attacker's website. Internet Explorer in the Windows 8-style UI will only play Flash content from sites listed on the Compatibility View (CV) list.

This restriction requires an attacker to first compromise a website already listed on the CV list.

An attacker could then host specially crafted Flash content designed to exploit any of these vulnerabilities through Internet Explorer and then convince a user 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 clicking a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email. By default, all supported versions of Microsoft Outlook and Windows Live Mail open HTML email messages in the Restricted sites zone.

The Restricted sites zone, which disables scripts and ActiveX controls, helps reduce the risk of an attacker being able to use any of these vulnerabilities to execute malicious code.
If a user clicks a link in an email message, the user could still be vulnerable to exploitation of any of these vulnerabilities through the web-based attack scenario. By default, Internet Explorer on Windows Server 2012 and Windows Server 2012 R2 runs in a restricted mode that is known as Enhanced Security Configuration.

This mode can help reduce the likelihood of the exploitation of these Adobe Flash Player vulnerabilities in Internet Explorer. Workaround refers to a setting or configuration change that would help block known attack vectors before you apply the update.Prevent Adobe Flash Player from running You can disable attempts to instantiate Adobe Flash Player in Internet Explorer and other applications that honor the kill bit feature, such as Office 2007 and Office 2010, by setting the kill bit for the control in the registry. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To set the kill bit for the control in the registry, perform the following steps: Paste the following into a text file and save it with the .reg file extension. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system.You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Note You must restart Internet Explorer for your changes to take effect. Impact of workaround.

There is no impact as long as the object is not intended to be used in Internet Explorer. How to undo the workaround. Delete the registry keys that were added in implementing this workaround.  Prevent Adobe Flash Player from running in Internet Explorer through Group Policy Note The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit, or for an entire domain.

For more information about Group Policy, visit the following Microsoft Web sites: Group Policy Overview What is Group Policy Object Editor? Core Group Policy tools and settings To disable Adobe Flash Player in Internet Explorer through Group Policy, perform the following steps: Note This workaround does not prevent Flash from being invoked from other applications, such as Microsoft Office 2007 or Microsoft Office 2010. Open the Group Policy Management Console and configure the console to work with the appropriate Group Policy object, such as local machine, OU, or domain GPO. Navigate to the following node:Administrative Templates -> Windows Components -> Internet Explorer -> Security Features -> Add-on Management Double-click Turn off Adobe Flash in Internet Explorer and prevent applications from using Internet Explorer technology to instantiate Flash objects. Change the setting to Enabled. Click Apply and then click OK to return to the Group Policy Management Console. Refresh Group Policy on all systems or wait for the next scheduled Group Policy refresh interval for the settings to take effect.  Prevent Adobe Flash Player from running in Office 2010 on affected systems Note This workaround does not prevent Adobe Flash Player from running in Internet Explorer. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. For detailed steps that you can use to prevent a control from running in Internet Explorer, see Microsoft Knowledge Base Article 240797.

Follow the steps in the article to create a Compatibility Flags value in the registry to prevent a COM object from being instantiated in Internet Explorer. To disable Adobe Flash Player in Office 2010 only, set the kill bit for the ActiveX control for Adobe Flash Player in the registry using the following steps: Create a text file named Disable_Flash.reg with the following contents: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM\Compatibility\{D27CDB6E-AE6D-11CF-96B8-444553540000}] "Compatibility Flags"=dword:00000400 Double-click the .reg file to apply it to an individual system. Note You must restart Internet Explorer for your changes to take effect. You can also apply this workaround across domains by using Group Policy.

For more information about Group Policy, see the TechNet article, Group Policy collection. Prevent ActiveX controls from running in Office 2007 and Office 2010 To disable all ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, including Adobe Flash Player in Internet Explorer, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then select Disable all controls without notifications. Click OK to save your settings. Impact of workaround. Office documents that use embedded ActiveX controls may not display as intended. How to undo the workaround. To re-enable ActiveX controls in Microsoft Office 2007 and Microsoft Office 2010, perform the following steps: Click File, click Options, click Trust Center, and then click Trust Center Settings. Click ActiveX Settings in the left-hand pane, and then deselect Disable all controls without notifications. Click OK to save your settings. Set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones You can help protect against exploitation of these vulnerabilities by changing your settings for the Internet security zone to block ActiveX controls and Active Scripting. You can do this by setting your browser security to High. To raise the browsing security level in Internet Explorer, perform the following steps: On the Internet Explorer Tools menu, click Internet Options. In the Internet Options dialog box, click the Security tab, and then click Internet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click Local intranet. Under Security level for this zone, move the slider to High.

This sets the security level for all websites you visit to High. Click OK to accept the changes and return to Internet Explorer. Note If no slider is visible, click Default Level, and then move the slider to High. Note Setting the level to High may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly even with the security setting set to High. Impact of workaround. There are side effects to blocking ActiveX Controls and Active Scripting. Many websites on the Internet or an intranet use ActiveX or Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use ActiveX Controls to provide menus, ordering forms, or even account statements.

Blocking ActiveX Controls or Active Scripting is a global setting that affects all Internet and intranet sites.
If you do not want to block ActiveX Controls or Active Scripting for such sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone You can help protect against exploitation of these vulnerabilities by changing your settings to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.

To do this, perform the following steps: In Internet Explorer, click Internet Options on the Tools menu. Click the Security tab. Click Internet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click Local intranet, and then click Custom Level. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK. Click OK to return to Internet Explorer, and then click OK again. Note Disabling Active Scripting in the Internet and Local intranet security zones may cause some websites to work incorrectly.
If you have difficulty using a website after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites.

This will allow the site to work correctly. Impact of workaround. There are side effects to prompting before running Active Scripting. Many websites that are on the Internet or on an intranet use Active Scripting to provide additional functionality.

For example, an online e-commerce site or banking site may use Active Scripting to provide menus, ordering forms, or even account statements. Prompting before running Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround.

For each prompt, if you feel you trust the site that you are visiting, click Yes to run Active Scripting.
If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".   Add sites that you trust to the Internet Explorer Trusted sites zone After you set Internet Explorer to require a prompt before it runs ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone.

This will allow you to continue to use trusted websites exactly as you do today, while helping to protect you from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone. To do this, perform the following steps: In Internet Explorer, click Tools, click Internet Options, and then click the Security tab. In the Select a web content zone to specify its current security settings box, click Trusted Sites, and then click Sites. If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box. In the Add this website to the zone box, type the URL of a site that you trust, and then click Add. Repeat these steps for each site that you want to add to the zone. Click OK two times to accept the changes and return to Internet Explorer. Note Add any sites that you trust not to take malicious action on your system.

Two sites in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com.

These are the sites that will host the update, and they require an ActiveX control to install the update. For Security Update Deployment information, see the Microsoft Knowledge Base article referenced here in the Executive Summary.Microsoft recognizes the efforts of those in the security community who help us protect customers through coordinated vulnerability disclosure.
See Acknowledgments for more information.The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose.
In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages.
Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.V1.0 (October 11, 2016): Bulletin published. Page generated 2016-10-06 13:38-07:00.
*Turns out to be very unsafe mode thanks to this hack Security researcher Doron Naim has cooked an attack that abuses Windows 10's Safe Mode to help hackers steal logins. The Cyberark man says remote attackers need to have access to a PC before they can spring this trap, which involves rebooting a machine into Safe Mode to take advantage of the lesser security controls offered in that environment. One in Safe Mode, logins can be stolen and otherwise with defeated pass-the-hash lateral techniques can be used to compromise other networked machines. A fake login screen can be shown using a COM object technique to emulate a normal boot and cloak Safe Mode. Users who then type in their credentials assuming a normal reboot will hand their logins to attackers. "Once attackers break through the perimeter and gain local administrator privileges on an infected Windows-based machine, they can remotely activate Safe Mode to bypass and manipulate endpoint security measures," Naim says. "In Safe Mode, the attackers are able to freely run tools to harvest credentials and laterally move to connected systems – all while remaining undetected. "This exploit can also work in Windows 10, despite the presence of the Microsoft’s Virtual Secure Module." Microsoft will not fix the attack vector since it depends on hackers already having access to a Windows machine. However Naim says gaining access to at least one Windows machine in an organisation is easy, and cites a Fireeye study [PDF] which reveals most organisations had recorded falling for targeted phishing attack last year. Entering Safe Mode avoids a host of security controls including the Virtual Security Module which would otherwise serve to limit the ability for attackers to deploy tools and steal password hashes. "This pattern of credential capture and lateral movement can be reused by an attacker multiple times until an eventual domain compromise in achieved," Naim says. Attackers can either wait until victims reboot or generate a notice prompting that a reboot is necessary. Security controls can be disabled using the altered conditions under Safe Mode that allow registry keys to be tampered, Naim found. Popular post-exploitation tool Mimikatz in lab tests went undetected when antivirus from Microsoft, Trend Micro, McAfee, and Avira was disabled from safe boot. Naims recommends administrators cycle privileged account credentials to disrupt pass-the-hash attacks, enforce least privilege by stripping local administrator rights, and deploy security tools capable of running in Safe Mode. ®
So long as Windows remain a popular attack target, researchers and hackers will keep pounding the platform to uncover advanced strategies to subvert Microsoft's defenses. The bar for security is much higher than it used to be, as Microsoft has added multiple advanced mitigations in Windows 10 that take out entire classes of attacks. While hackers at this year’s Black Hat conference came armed with sophisticated exploitation techniques, there was tacit recognition that developing a successful technique is now much harder with Windows 10.

Breaking into Windows through an OS vulnerability is harder than it was even a few years ago. Use built-in antimalware tools Microsoft has developed antimalware scan interface (AMSI) tools that can catch malicious scripts in memory.

Any application can call it, and any registered antimalware engine can process the content submitted to AMSI, said Nikhal Mittal, penetration tester and associate consultant with NoSoSecure, to attendees at his Black Hat session. Windows Defender and AVG currently use AMSI, and it should become more widely adopted. “AMSI is a big step toward blocking script-based attacks in Windows,” Mittal said. Cybercriminals increasingly rely on script-based attacks, especially those that execute on PowerShell, as part of their campaigns.
It's tough for organizations to discover attacks using PowerShell because they're hard to differentiate from legitimate behavior.
It's also difficult to recover because PowerShell scripts can be used to touch any aspect of the system or network. With practically every Windows system now preloaded with PowerShell, script-based attacks are becoming much more common. Criminals started using PowerShell and loading scripts in memory, but it took the defenders a while to catch on. “No one cared about PowerShell until a few years back,” Mittal said. “Our scripts are not getting detected at all.

Antivirus vendors have only in the past three years embraced it.” While it's easy to detect scripts saved on disk, it’s not so easy to stop scripts saved to memory from executing.

AMSI tries to catch scripts at the host level, which means the input method -- whether saved on disk, stored in memory, or launched interactively -- doesn’t matter, making it a “game changer,” as Mittal said. However, AMSI can’t stand alone, as the usefulness relies on other security methods.
It's very difficult for script-based attacks to execute without generating logs, so it’s important for Windows administrators to regularly monitor their PowerShell logs. AMSI isn’t perfect -- it's less helpful detecting obfuscated scripts or scripts loaded from unusual places like WMI namespace, registry keys, and event logs. PowerShell scripts executed without using powershell.exe (tools such as network policy server) can also trip up AMSI.

There are ways to bypass AMSI, such as changing the signature of scripts, using PowerShell version 2, or disabling AMSI. Regardless, Mittal still considers AMSI “the future of Windows administration.” Protect that Active Directory Active Directory is the cornerstone of Windows administration, and it’s becoming an even more critical component as organizations continue moving their workloads to the cloud. No longer used to handle authentication and management for on-premises internal corporate networks, AD can now help with identity and authentication in Microsoft Azure. Windows administrators, security professionals, and attackers all have different perspectives of Active Directory, Sean Metcalf, a Microsoft Certified Master for Active Directory and founder of security company Trimarc, told Black Hat attendees.

For the administrator, the focus is on uptime and ensuring AD responds to queries within a reasonable window.
Security professionals monitor Domain Admin group membership and keep up with software updates.

The attacker looks at the security posture for the enterprise to find the weakness. None of the groups has the complete picture, Metcalf said. All authenticated users have read access to most, if not all, objects and attributes in Active Directory, Metcalf said during the talk.

A standard user account can compromise an entire Active Directory domain because of improperly granted modify rights to domain-linked group policy objects and organizational unit.
Via custom OU permissions, a person can modify users and groups without elevated rights, or they can go through SID History, an AD user account object attribute, to gain elevated rights, Metcalf said. If Active Directory is not secured, then AD compromise becomes even more likely. Metcalf outlined strategies to help enterprises avoid common mistakes, and it boils down to protecting administrator credentials and isolating critical resources.
Stay on top of software updates, especially patches addressing privilege-escalation vulnerabilities, and segment the network to make it harder for attackers to move through laterally. Security professionals should identify who has administrator rights for AD and to virtual environments hosting virtual domain controllers, as well as who can log on to domain controllers.

They should scan active directory domains, AdminSDHolder object, and group policy objects (GPO) for inappropriate custom permissions, as well as ensure domain administrators (AD administrators) never log into untrusted systems such as workstations with their sensitive credentials.
Service account rights should also be limited. Get AD security right, and many common attacks are mitigated or become less effective, Metcalf said. Virtualization to contain attacks Microsoft introduced virtualization-based security (VBS), a set of security features baked into the hypervisor, in Windows 10.

The attack surface for VBS is different from that of other virtualization implementations, said Rafal Wojtczuk, chief security architect at Bromium. “Despite its limited scope, VBS is useful -- it prevents certain attacks that are straightforward without it,” Wojtczuk said. Hyper-V has control over the root partition, and it can implement extra restrictions and provide secure services. When VBS is enabled, Hyper-V creates a specialized virtual machine with a high trust level to execute security commands. Unlike other VMs, this specialized machine is protected from the root partition. Windows 10 can enforce code integrity of user-mode binaries and scripts, and VBS handles kernel-mode code.
VBS is designed to not allow any unsigned code from executing in the kernel context, even if the kernel has been compromised.

Essentially, trusted code running in the special VM grant execute rights in the root partition’s extended page tables (EPT) to pages storing signed code.
Since the page can’t be both writeable and executable at the same time, malware can’t enter kernel mode that way. Since the whole concept hinges on the ability to keep going even if the root partition has been compromised, Wojtczuk examined VPS from the perspective of an attacker who has already broken into the root partition -- for example, if an attacker bypasses Secure Boot to load a Trojanized hypervisor. “The security posture of VBS looks good, and it improves the security of a system -- certainly it requires additional highly nontrivial effort to find suitable vulnerability allowing the bypass,” Wojtczuk wrote in the accompanying white paper. Existing documentation suggests Secure Boot is required, and VTd and Trusted Platform Module (TPM) are optional for enabling VBS, but that isn’t the case.

Administrators need to have both VTd and TPM to protect the hypervisor against a compromised root partition.
Simply enabling Credential Guard isn’t enough for VBS.

Additional configuration to ensure that credentials don’t show up in the clear in the root partition is necessary. Microsoft has put in a lot of effort to make VBS as secure as possible, but the unusual attack surface is still cause for concern, Wojtczuk said. The security bar is higher The breakers, which includes criminals, researchers, and hackers interested in seeing what they can do, are engaged in an elaborate dance with Microsoft.

As soon as the breakers figure out a way to bypass Windows defenses, Microsoft closes the security hole.

By implementing innovative security technology to make attacks harder, Microsoft forces breakers to dig deeper to get around them. Windows 10 is the most secure Windows ever, thanks to those new features. The criminal element is busy at work, and the malware scourge doesn’t show signs of slowing down soon, but it’s worth noting that most attacks nowadays are the result of unpatched software, social engineering, or misconfigurations. No software applications can be perfectly bug-free, but when the built-in defenses make it harder to exploit existing weaknesses, that is a victory for the defenders. Microsoft has done a lot over the past few years to block attacks on the operating system, and Windows 10 is the direct beneficiary of those changes. Considering that Microsoft beefed up its isolation technologies in Windows 10 Anniversary Update, the road to successful exploitation for a modern Windows system looks even tougher.
Multiple Edge Memory Corruption Vulnerabilities Multiple remote code execution vulnerabilities exist when Microsoft Edge improperly accesses objects in memory.

The vulnerabilities could corrupt memory in a way that enables an attacker to execute arbitrary code in the context of the current user.

An attacker who successfully exploited the vulnerabilities could gain the same user rights as the current user.
If the current user is logged on with administrative user rights, an 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 that is designed to exploit the vulnerabilities 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 by adding specially crafted content that could exploit the vulnerabilities.
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 way of an enticement in an email or instant message, or by getting them to open an email attachment.

The update addresses the vulnerabilities by modifying how Microsoft Edge handles objects in memory. The following table contains links to the standard entry for each vulnerability in the Common Vulnerabilities and Exposures list: Vulnerability title CVE number Publicly disclosed Exploited Microsoft Browser Memory Corruption Vulnerability CVE-2016-3289 No No Microsoft Browser Memory Corruption Vulnerability CVE-2016-3293 No No Microsoft PDF Remote Code Execution Vulnerability CVE-2016-3319 No No Microsoft Browser Memory Corruption Vulnerability CVE-2016-3322 No No Mitigating Factors Microsoft has not identified any mitigating factors for these vulnerabilities. Workarounds Microsoft has not identified any workarounds for these vulnerabilities. For CVE-2016-3319 only: Remove Microsoft EDGE from the PDF reader default file type association Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. Interactive Method: Click Start, click Run, type regedit, and then click OK. Expand HKEY_CLASSES_ROOT, click .EXTENSION, and then click the File menu and select Export. In the Export Registry File window, type a file name of EXTENSION HKCR file association registry backup.reg and then click Save.

This will create a backup of the registry key in the My Documents folder by default. Press the Delete key on the keyboard to delete the registry key. When prompted to delete the registry value, click Yes. Expand HKEY_CURRENT_USER, then Software, then Microsoft, then Windows, then CurrentVersion, then Explorer, then FileExts. Click .EXTENSION and then click the File menu and select Export. In the Export Registry File window, type a file name of EXTENSION HKCU file association registry backup.reg and then click Save.

This will create a backup of the registry key in the My Documents folder by default. Press the Delete key on the keyboard to delete the registry key. When prompted to delete the registry value, click Yes. Managed Deployment Script: Make a backup copy of the registry keys using a managed deployment script with the following commands: Regedit.exe /e EXTENSION_HKCR_registry_backup.reg HKEY_CLASSES_ROOT\.EXTENSION Regedit.exe /e EXTENSION_HKCU_registry_backup.reg HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.EXTENSION Next save the following to a file with a .REG extension (e.g., Delete_EXTENSION_file_association.reg): Windows Registry Editor Version 5.00 [-HKEY_CLASSES_ROOT\.EXTENSION] [-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.EXTENSION] On the target system, run the registry script created in step 2 using the following command: Regedit.exe /s Delete_EXTENSION_file_association.reg Impact of Workaround. PDF documents will no longer open with Microsoft Edge by default. How to undo the workaround To undo the workaround, restore the original registry keys that were saved in the initial steps of the workaround. Scripting Engine Memory Corruption Vulnerability – CVE-2016-3296 A remote code execution vulnerability exists in the way that the Chakra JavaScript engine renders 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 that is 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 Edge 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 update addresses the vulnerability by modifying how the Chakra JavaScript scripting engine handles objects in memory. The following table contains links to the standard entry for the vulnerability in the Common Vulnerabilities and Exposures list: Vulnerability title CVE number Publicly disclosed Exploited Scripting Engine Memory Corruption Vulnerability CVE-2016-3296 No No Mitigating Factors Microsoft has not identified any mitigating factors for this vulnerability. Workarounds Microsoft has not identified any workarounds for this vulnerability. Multiple Microsoft Edge Information Disclosure Vulnerabilities Multiple information disclosure vulnerabilities exist when Microsoft Edge improperly handles objects in memory.

An attacker who successfully exploited the vulnerabilities could obtain information to further compromise the user’s system. To exploit the vulnerabilities, in a web-based attack scenario, an attacker could host a website that is used to attempt to exploit the vulnerabilities.
In addition, compromised websites and websites that accept or host user-provided content could contain specially crafted content that could exploit the vulnerabilities.
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.

For example, an attacker could trick users into clicking a link that takes them to the attacker's site.

The update addresses the vulnerabilities by changing how certain functions handle objects in memory. The following table contains links to the standard entry for each vulnerability in the Common Vulnerabilities and Exposures list: Vulnerability title CVE number Publicly disclosed Exploited Microsoft Browser Information Disclosure Vulnerability CVE-2016-3326 No No Microsoft Browser Information Disclosure Vulnerability CVE-2016-3327 No No Mitigating Factors Microsoft has not identified any mitigating factors for these vulnerabilities. Workarounds Microsoft has not identified any workarounds for these vulnerabilities. Microsoft Edge Information Disclosure Vulnerability – CVE-2016-3329 An information disclosure vulnerability exists when Microsoft Edge improperly handles page content, which could allow an attacker to detect the existence of specific files on the user's system.

The update addresses the vulnerability by helping to ensure that page content is properly validated in Microsoft Edge. To exploit the vulnerability, in a web-based attack scenario, an attacker could host a website that is used to attempt to exploit the vulnerability.
In addition, compromised websites and websites that accept or host user-provided content could contain 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.

For example, an attacker could trick users into clicking a link that takes them to the attacker's site.

The update addresses the vulnerability by changing how certain functions handle objects in memory. The following table contains links to the standard entry for each vulnerability in the Common Vulnerabilities and Exposures list: Vulnerability title CVE number Publicly disclosed Exploited Microsoft Browser Information Disclosure Vulnerability CVE-2016-3329 No No Mitigating Factors Microsoft has not identified any mitigating factors for this vulnerability. Workarounds Microsoft has not identified any workarounds for this vulnerability.
Are you ready for the coming SHA-1 deprecation deadline? I suspect most companies aren't.

They don't know about the issue -- and the pending January 1, 2017 deadline. Others are probably aware that there is something called "SHA-1 deprecation" and have gotten some browser certificate errors, but don't fully appreciate the need to be substantially migrated to SHA-2 by the end of the year. To recap, the SHA-1 cryptographic signing algorithm has significant mathematical weaknesses.

The powers that be have decided that the digital certificate world needs to migrate or replace some (or all) SHA-1 signed digital certificates with SHA-2 digital certificates by the start of 2017 at the latest.

Certificates affected by SHA-1 deprecation policies but still signed by SHA-1 algorithms will be treated as untrusted once the deadline comes. So what's the impact? When SHA-1 deprecation is enforced, it should apply to the presented endpoint certificate and all involved CA (certification authority) certificates in the same PKI chain, with the exception of the root CA's own CA certificate.

The root CA certificate can be SHA-1 or SHA-2 without impacting enforcement. Although December 31, 2016 was agreed upon as the "final" date that SHA-1 will be accepted for affected certificates, many vendors don't agree on what certificate types will be affected.
Some have different intermediate dates (for different certificates types) and different treatments over time. I wish all certificate types were slated to be deprecated on the same day.

A single cutover date would be less confusing and less work. Right now, what we have is similar to an extended Y2K problem, where instead of everything going haywire on January 1, 2000, the Y2K crash dates fall all over the calendar. When SHA-1 enforcement arrives, in some cases this means a browser will produce a warning or temporary operational block until the user acknowledges that warning and bypasses it.
In other cases, it means the "lock icon" normally present on a HTTPS-protected website will not be presented (even if the original level of protection is still enabled). On some products and dates, it means the certificate will be completely untrusted and the user will be prevented from going to the desired site or service. On others, nothing will be affected until a much later date. Microsoft's deprecation policy applies only to certificates originating from CAs in its Microsoft Trusted Root Certificate Program, or what most people call "public CAs." This means that Windows and Microsoft software will not apply SHA-1 depreciation enforcement to any certificate originating from a company's private CA. Unfortunately, most other vendors and programs do not make the distinction between public and private certificates, which means most people have to worry about both types of certificates, unless they only have Microsoft software (pretty unlikely). Currently, Microsoft SHA-1 depreciation enforcement applies only to code-signing certificates with Mark of the Web, which took effect on January 1 of this year.

Treatment varies depending on whether or not the involved certificate was timestamped by January 1, 2016. Microsoft moves its SHA-1 deprecation deadline The major vendors have tended to update their SHA-1 deprecation policies, especially deadlines and certificate treatments, every few months.

This month, Microsoft has moved its ultimate January 1, 2017 deadline to February 14, 2017.
I know a ton of my customers will appreciate the additional month and half to get prepared. Regarding code signing certificates without the Mark of the Web: Microsoft will block them on January 1, 2017 if they were time stamped before January 1, 2016 -- and if time stamped after that date, on February 14, 2017. When Windows 7 through 10 users apply the forthcoming, summer-released, Windows 10 Anniversary Update, Internet Explorer and Edge browsers will no longer treat SHA-1 signed TLS certificates as trusted.

The lock icon will not be displayed, but users will be able to continue onto the site. Once February 14, 2017 arrives, the certificates will be blocked completely. Luckily, Microsoft's SHA-1 enforcement can be disabled by a few registry edits. Unfortunately, this defangs Microsoft software only. Regardless, you really need to get rid of SHA-1 anyway, so don't delay even if you can. Moving Active Directory Certificate Services to SHA-2 One of the most popular installed server roles on Microsoft Windows server is ADCS (Active Directory Certificate Services), Microsoft's PKI software.
If you have one or more Microsoft CAs, the CAs below the root CA may need to be migrated from SHA-1 to SHA-2 due to non-Microsoft software SHA-1 deprecation treatment. If the SHA-1 enabled ADCS servers are already running a KSP (key storage provider) instead of the legacy CSP (cryptographic storage provider), in most cases you can switch them to SHA-2 with a single registry edit. Just change HKLMSYSTEMCurrentControlSetServicesCertSvcConfiguration<Your CA Common Name>CSPCNGHashAlgorithm registry key value from SHA1 to SHA256 (or one of the other supported and desired SHA-2 key sizes) and restart Certificate Services.
It's really that easy to convert a KSP SHA1 CA to a SHA2 CA. That single registry edit is enough to make the modified CA begin issuing new SHA-2 signed certificates and CRLs (certificate revocation lists), but if the issuing CAs currently have SHA-1 signed certificates, you will have to renew the CA certificates and get them signed by a SHA-2 signing parent CA and install them. Moving CSP to KSP If the involved ADCS CA is currently running a legacy CSP rather than a newer KSP, the conversion requires a lot more than a single registry edit. You have to extract the CSP-protected CA key pair (including private key), re-wrap it with the intended KSP, and reimport.

Then you have to uninstall and re-install ADCS, choosing the newly-wrapped key pair. Unfortunately, this wipes out all the related registry keys and previous CA database (which logs all the issued certificates and CRLs).

This mean you must back up your previous registry keys and database before doing the uninstall.

The previous database can be easily re-installed after the ADCS reinstall is complete, but the critical registry keys and other settings should be manually re-created.

That's a lot of precise steps. Luckily, I have documented every mouse click and command prompt command in the most recent version of my SHA-2 migration paper.
If you follow my guide step-by-step, you'll have a great, working, migrated SHA-2 KSP CA. The whitepaper includes all the detailed information behind why you need to do SHA-2 migration and includes project planning steps. You can use the related SHA-2 migration PPT slide deck for educational and project implementation purposes. So do yourself a favor and upgrade your SHA-1 CAs to SHA-2 before the deadline hits. You're probably already seeing warnings and issues. Upgrade before operational interruption strikes!
Anti-virus engine easily disable. Intel Security has fixed a flaw that made it possible to shut down its McAfee Enterprise virus engine, thereby allowing the installation of malware and pirated software. The hotfix addresses an issue that Agazzini Maurizio, senior security advisor at Rome-based consultancy Mediaservice, first warned about 15 months ago. McAfee acknowledged the bypass in December 2014 and released the patch on 25 February 2016. The flaw requires users or attackers first gain local administrator privileges, a level of access that many organisations lazily afford staff. "McAfee VirusScan Enterprise has a feature to protect the scan engine from local Windows administrators [and] a management password is needed to disable it," Maurizio says. "From our understanding this feature is implemented insecurely: the McAfee VirusScan Console checks the password and requests the engine to unlock the safe registry keys. "No checks are done by the engine itself, so anyone can directly request the engine to stop without knowing the correct management password." All versions are affected. Attackers can either use Maurizio's tool or alter registry keys before opening the McAfee console and choosing 'no password' Removing administrator rights from user accounts goes a long way to helping organisational security postures. In May Manchester-based security firm Avecto reckoned 97 percent of critical Microsoft vulnerabilities released in 2014 would be mitigated by removing admin rights. ® Sponsored: Five essentials for improving endpoint security
Original release date: October 27, 2014Systems Affected Microsoft Windows Overview Since mid-October 2014, a phishing campaign has targeted a wide variety of recipients while employing the Dyre/Dyreza banking malware. Elements of this phishing campaign vary from target to target including senders, attachments, exploits, themes, and payload(s).[1][2] Although this campaign uses various tactics, the actor’s intent is to entice recipients into opening attachments and downloading malware. Description The Dyre banking malware specifically targets sensitive user account credentials. The malware has the ability to capture user login information and send the captured data to malicious actors.[3] Phishing emails used in this campaign often contain a weaponized PDF attachment which attempts to exploit vulnerabilities found in unpatched versions of Adobe Reader.[4][5] After successful exploitation, a user's system will download Dyre banking malware. All of the major anti-virus vendors have successfully detected this malware prior to the release of this alert.[6]Please note, the below listing of indicators does not represent all characteristics and indicators for this campaign.Phishing Email Characteristics:Subject: "Unpaid invoic" (Spelling errors in the subject line are a characteristic of this campaign)Attachment: Invoice621785.pdfSystem Level Indicators (upon successful exploitation):Copies itself under C:Windows[RandomName].exeCreated a Service named "Google Update Service" by setting the following registry keys:HKLMSYSTEMCurrentControlSetServicesgoogleupdateImagePath: "C:WINDOWSpfdOSwYjERDHrdV.exe"HKLMSYSTEMCurrentControlSetServicesgoogleupdateDisplayName: "Google Update Service"Impact A system infected with Dyre banking malware will attempt to harvest credentials for online services, including banking services. Solution Users and administrators are recommended to take the following preventive measures to protect their computer networks from phishing campaigns:Do not follow unsolicited web links in email. Refer to the Security Tip Avoiding Social Engineering and Phishing Attacks [7] for more information on social engineering attacks.Use caution when opening email attachments. For information on safely handling email attachments, see Recognizing and Avoiding Email Scams.[8]Follow safe practices when browsing the web. See Good Security Habits [9]and Safeguarding Your Data [10] for additional details.Maintain up-to-date anti-virus software.Keep your operating system and software up-to-date with the latest patches.US-CERT collects phishing email messages and website locations so that we can help people avoid becoming victims of phishing scams.You can report phishing to us by sending email to phishing-report@us-cert.gov. References [1] MITRE Summary of CVE-2013-2729, accessed October 16, 2014 [2] MITRE Summary of CVE-2010-0188, accessed October 16, 2014 [3] New Banking Malware Dyreza, accessed October 16, 2014 [4] Adobe Security Updates Addressing CVE-2013-2729, accessed October 16, 2014 [5] Adobe Security Updates Addressing CVE-2010-0188, accessed October 16, 2014 [6] VirusTotal Analysis, accessed October 16, 2014 [7] US-CERT Security Tip (ST04-014) Avoiding Social Engineering and Phishing Attacks [8]US-CERT Recognizing and Avoiding Email Scams [9] US-CERT Security Tip (ST04-003) Good Security Habits [10] US-CERT Security Tip (ST06-008) Safeguarding Your Data Revision History October 27, 2014: Initial Release This product is provided subject to this Notification and this Privacy & Use policy.