To provide a more secure experience, both the Windows 10 Creators Update and Cumulative Security Update for Internet Explorer-April 11, 2017 introduce an option to block VBScript execution in Internet Explorer for all document modes. Users can configure this behavior per site security zone via registry or via Microsoft Easy fix solution. Enterprise customers can also configure this behavior via Group Policy.
As a security best practice, we recommend that Microsoft Internet Explorer users disable VBScript execution for websites in Internet Zone and Restricted Sites Zone. Details on how to configure this behavior can be found in KB4012494.
In subsequent Windows releases and future updates, we intend to disable VBScript execution by default in Internet Explorer 11 for websites in the Internet Zone and the Restricted Sites Zone. The settings to enable, disable, or prompt for VBScript execution in Internet Explorer 11 will remain configurable per site security zone, via Registry or via Group Policy, for a limited time. We will post future updates here in advance of changes to default settings for VBScript execution in Internet Explorer 11.
Most customers have automatic updates enabled, and updates will be downloaded and installed automatically. Customers who have automatic updates turned off, will need to check for updates and install them manually.
Today, the Windows 10 Creators Update began rolling out to over 400 million Windows 10 devices. With the Creators Update, we’re upgrading Microsoft Edge with dozens of new features and under-the-hood improvements to make the best browser on Windows 10 faster, leaner, and more capable than ever.
This release updates the Windows web platform to EdgeHTML 15, the fourth release of EdgeHTML and a major step forward both in terms of the browser user experience, web platform capabilities, and fundamentals like performance, efficiency, and accessibility. In this post, we’ll share a quick overview of what’s new in each area, for both users and web developers. Stay tuned over the coming weeks, as we’ll be sharing a deeper look at many of these topics individually.
Introducing Microsoft Edge in the Windows 10 Creators Update
Over the last eight months, the Microsoft Edge team has been focused on exciting new features to make the browsing experience better than ever:
Organize your web with new tab management experiences
Windows users spend more than half of their time on the web, and it’s all too easy to get tangled up in the chaos of search results, sites, and other content that can build up over hours, days, or weeks of browsing. In this update, we’ve introduced two new features to take the pain out of tab management.
Microsoft Edge now lets you set your tabs aside for later, sweeping them aside and organizing them neatly in a special section for easy access when you’re ready.
Set your tabs aside for later
Simply click the new “Set these tabs aside” button next to your row of tabs, and they are moved out of sight. When you’re ready to come back to them, just click the “Tabs you’ve set aside” icon, and you get a tidy, visual view of previous sessions. Restore one tab, or restore the full set!
If you have a lot of tabs open, it can be daunting to tell them apart, or to find a specific page in the sea of tiny icons and titles. Microsoft Edge now includes the ability to preview all your open tabs at once, so you can get back to what you’re looking for in a snap.
Show tab previews to scan your tabs more easily
Simply click the “Show tab previews” arrow to the right of your new tab button, and your tabs will expand to show a preview of the full page. You can scroll through this list to see as many tabs as you have open – when you find what you want, just click it to get back to browsing!
New reading experiences in Microsoft Edge
Microsoft Edge now lets you read books from right inside the browser, putting your favorite e-books from the Windows Store or from EPUBs on the web alongside your reading list and other content you expect to find in your browser.
That’s just the beginning – you’ll find new features and extensions, and improvements to performance, usability, and more, all throughout Microsoft Edge. You can find tips on what’s new and how to get the most out of Microsoft Edge at Microsoft Edge Tips.
These improvements translate into hours more browsing time for our customers – time to finish a crucial report while you’re at a coffee shop with no power, or to watch an extra movie on a long flight. In a head-to-head video rundown test, Microsoft Edge outlasted Google Chrome by more than three hours when streaming video!
There are countless enhancements to improve efficiency in the Creators Update, and we’re methodical about measuring the impact of each fix or new feature to make sure you get the most out of your browser. Watch this space for a detailed update on the engineering work that enables our greater power efficiency, and more on how we measure power consumption, coming early next week.
Responsiveness that puts the user first
Comparing scrolling on a busy page, before and after the input responsiveness improvements in EdgeHTML 15.
That just scratches the surface – for example, over the past two releases, we’ve been working on an ongoing, multi-year refactoring of the Microsoft Edge DOM tree, which is now substantially complete. Together with a number of performance optimizations, this has resulted in a more than twofold improvement in performance in many real-world scenarios, as measured by the Speedometer benchmark, which simulates real-world app patterns using common frameworks.
Chart showing Microsoft Edge scores on the Speedometer benchmark over the past four release. Edge 12: 5.44. Edge 13: 37.83. Edge 14: 53.92. Edge 15: 82.67.
We’ll be exploring these performance and responsiveness improvements in more detail over the coming weeks – stay tuned!
Safer than ever
Microsoft Edge in the Creators Update includes two broad categories of security improvements which make the browser more resilient to typical attack strategies.
First, we’ve introduced a series of mitigations to prevent arbitrary native code execution: Code Integrity Guard and Arbitrary Code Guard. These mitigations make it much more difficult to load harmful code into memory, making it less likely and less economical for attackers to be successful in building a compete exploit. You can read more about this work in Mitigating arbitrary native code execution in Microsoft Edge.
Second, we’ve dramatically improved the resiliency of the Microsoft Edge sandbox. Microsoft Edge has always been sandboxed in a series of app containers on Windows 10 – in the Creators Update, we’ve tuned these app containers by reducing the access scope to only the capabilities that are directly necessary for Microsoft Edge to work properly. This work dramatically reduces Microsoft Edge’s attack surface area (including a 90% reduction in access to WinRT and DCOM APIs), and when combined with the exploit mitigations that apply to Microsoft Edge and its brokers, increases the difficult of exploiting any remaining vulnerabilities. You can read more about this work in Strengthening the Microsoft Edge Sandbox.
Modern capabilities for web developers
The Windows 10 Creators Update upgrades the Windows web platform to EdgeHTML 15, which introduces a number of new, modern capabilities for web developers. A few of these are highlighted below – you can find the full list of changes on the Microsoft Edge Dev Guide.
Simpler web payments with the Payment Request API
The new W3C Payment Request API enables simpler checkouts and payments on Windows 10 PCs and phones. In Microsoft Edge, the Payment Request API connects to the user’s Microsoft Account (with the user’s permission), allowing easy access to payment information. Because payment information is securely saved in a digital wallet, shoppers don’t have to navigate through traditional checkout flows and repeatedly enter the same payment and shipping address information repeatedly.
WebVR Developer Preview
Microsoft Edge now supports the WebVR 1.1 draft specification, which has been collaboratively authored by Mozilla, Google, Samsung, Microsoft, Oculus and others. Developers can now use this API to create immersive VR experiences on the web with the recently available Windows Mixed Reality dev kits. You can even get started without a headset using the Windows Mixed Reality Simulator. Acer, ASUS, Dell, HP, and Lenovo will ship the world’s first Windows Mixed Reality-enabled headsets later this year, starting at just $299 USD. Note that while WebVR is enabled by default in Microsoft Edge, using the Windows Mixed Reality Portal or Mixed Reality dev kits currently requires Developer Mode to be turned on in Windows settings.
Brotli is a compression format that achieves up to 20% better compression ratios with similar compression and decompression speeds (PDF). This ultimately results in substantially reduced page weight for users, improving load times without substantially impacting client-side CPU costs. As compared to existing algorithms, like Deflate, Brotli compression is more efficient in terms of file size and CPU time. Learn more about Brotli in our blog post, Introducing Brotli compression in Microsoft Edge.
At An Event Apart Seattle, we recently announced the development has begun on our updated CSS Grid implementation. With this announcement, every one of the features pictured are in development (or, in the case of CSS Custom Properties, shipping today!).
Beyond CSS, our roadmap for preview releases over the rest of 2017 is focused on three areas: doubling down on fundamentals like performance and reliability, delivering Progressive Web Apps on Windows, and continuing to innovate in the user experience of Microsoft Edge. We’re excited to share more about what the future holds soon!
Get started today on Windows 10, or test for free via BrowserStack
In a recent post, we outlined the layered strategy that the Microsoft Edge security team employs to protect you from vulnerabilities that could be used to compromise your device or personal data. In particular, we showed how Microsoft Edge is leveraging technologies like Code Integrity Guard (CIG) and Arbitrary Code Guard (ACG) to break some of the techniques that hackers rely on when exploiting vulnerabilities to obtain Remote Code Execution (RCE). This is where the attacker seeks to escape from web code (JS and HTML) in the browser to run native CPU code of the attacker’s choosing. This lets the attacker violate all of the browser’s rules for the web, such as same-origin policy, and so it is important to web users that we try as hard as possible to block RCE attacks.
However, despite our best efforts, sometimes attackers get RCE anyway. In this post, we’ll explore some of the significant improvements we’ve made in the Windows 10 Creators Update to strengthen our next line of defense: the Microsoft Edge sandbox.
The history of the Microsoft Edge sandbox
Because RCE can happen, and in the past, often did, browser vendors have sought to sandbox the browser to defend the rest of the user’s PC from attack. In 2007, IE7 introduced Protected Mode, the first web browser sandbox. Windows 8 added app container to the OS, primarily to support the new Windows Store app model and support the confidence promise that apps are safe to use. IE10 and IE11 leveraged app container to create EPM (Enhanced Protected Mode) a stronger browser sandbox. However, the EPM sandbox restrictions were incompatible with older ActiveX controls that predated app container, and so EPM was provided as a security enhancing option.
The Manager provides browser features such as the URL bar, the back button, tabs, and your favorites list. The other app containers are:
Internet AC: hosts content from Internet sites.
Intranet AC: hosts content from Intranet sites. For enterprise users, that is enterprise web sites. For consumers, that is “web sites” that are control interfaces for devices on your home network, such as your Wi-Fi router, or IoT devices. Separating this RAC from the Internet e.g. protects your home Wi-Fi router from Internet attackers.
Extensions AC: hosts the new extensions for Microsoft Edge.
Flash AC: hosts the Adobe Flash player, to isolate it from the main content processes.
Service UI AC: hosts special web pages, such as about:flags, and the default home page.
The Internet AC is where the action is. Its job is to host web pages from anywhere, including the JS code provided by that web page, images, and multimedia. Hosting web pages is extremely complex, due to the richness of the modern web; this is the platform of the Internet, and developers need to be able to create any application and run it in this environment. Because it is complex, and hosts web pages from anywhere, this is where web security attacks begin. A malicious web site presents content intended to exploit bugs in the content hosting system, to take over control of the content process.
If an attacker gains control of an Internet AC process, they need to find some way to achieve their goals. If their goals involve compromising the user’s device or personal data stored on the device, then they’ll need to contend with escaping from the sandbox first.
Reducing the attack surface of the Microsoft Edge sandbox
One of the most effective ways to eliminate vulnerabilities in complex applications is to minimize the amount of code that an attacker can try to find vulnerabilities in. This is often referred to as attack surface reduction and it is a key tactic in our overall strategy security. To this end, Microsoft Edge in the Creators Update of Windows 10 has significantly reduced the attack surface of the sandbox by configuring the app container to further reduce its privilege.
To understand how we tuned the Microsoft Edge AC, it is first necessary to know how app container itself works. An app container process is deny-by-default for any secured object unless the object security descriptor has an allow access control entry (ACE) that would permit the app container to have access. There are three kinds of SIDs that can be used in such ACEs:
Capabilities: if a Capability SID based allow ACE is in the security descriptor, and the requesting AC has that Capability SID in its token, then it gets access. E.g. Webcam-related devices are accessible to processes that have the WEBCAM Capability SID such as Microsoft Edge.
AppID SIDs: if a specific AppID SID based allow ACE is in the security descriptor, and the requesting AC is that specific AppID, then it gets access. The main use for this is per-app storage, which uses the AppID of that app in the security descriptor, ensuring that its storage is private to that app.
“ALL APPLICATION PACKAGES” (“AC” SID): this is the AC wild card, allowing all app containers to access the resource. The “AC” SID exists so that Windows can provide an app platform that is useful to developers, allowing rich UWPs in the Windows Store. For instance, most of the WinRT API surface is open to the “AC” SID, so that all UWP apps can access the WinRT APIs.
The Microsoft Edge AC has been made different in only one way: the “AC” SID is not sufficient to let a requesting process access a resource. To get access, the AC must either have a matching Capability SID, or be precisely one of the named AppIDs in the security descriptor.
Thus the AC loses access to the entire WinRT API set, and every other resource that app containers normally can access. That’s great for security, with the slight problem that it would break everything about the browser, turning it into a highly secure brick.
Microsoft Edge “Tuned” AC
“Normal” app container
So to make Microsoft Edge work again, we used specific Capabilities to light up specific areas of functionality. For instance, we created a Capability that enables COM to work. We similarly added other new capabilities, granting access to specific resources, until Microsoft Edge worked again. Then we added some telemetry to detect access control failures for the content process and shared it to users in the Windows Insider Program (WIP) to ensure that we had granted access to all resources needed for all scenarios.
What we just did here was to create a tuned sandbox for the Microsoft Edge content process, with a much tighter fit to the functional needs of the software than a normal app container provides. That is a lot of work, which is why this is not how the UWP platform works. But because web browsers are among some of the most threatened software there is, it is worth it in this case.
We repeated this work of hand-tuning a sandbox for the Flash AC, because it also is subject to a lot of attacks. Placing Flash in a tighter sandbox complements our work in this release to make Flash be click-to-run.
Making it more difficult to exploit sandbox escape vulnerabilities
The main threats in a sandbox are the broker interfaces that provide access to resources according to a defined policy. So why have brokers at all? Brokers exist to grant access according to policy, e.g. the File broker allows a website to say “upload a file by browsing your files” and the user gets to pick the file to be uploaded, without giving the web site access to all of the user’s files.
Brokers are a threat to sandboxes because brokers are code (and therefore can have bugs) and because the brokers run outside the sandbox. If an attacker can hack a broker and run code in the broker, then the attacker can escape, similar to an inmate mugging a prison guard and then putting on the guard’s uniform to escape.
The tightened Microsoft Edge content process sandbox cuts off access to many brokers (reduced attack surface) but leaves the needed brokers accessible (residual threat). An attacker might try to exploit bugs in the accessible brokers to elevate privileges and execute arbitrary native code in the broker, and thus escape. To mitigate this threat, we have applied many of the same exploit mitigation technologies to the brokers that provide service to Microsoft Edge.
Microsoft Edge also has some surprising brokers, because the exploit mitigation work forced several components to move out-of-process (OOP), including the Chakra JIT code generator and the Flash runtime process. These components had to move out of process because they necessarily do code generation (JIT) and that is not compatible with the ACG mitigation applied to the content process. Thus, these components function as the “JS code generator” broker and the “Run Flash bytecode” broker.
They can be viewed as brokers precisely because they have permission to do something that the content process is not permitted to do for itself. They are also a threat, because an attacker that can gain control of OOP JIT or the Flash sandbox could e.g. create executable code and use that for further exploitation, bypassing ACG. Because they are a threat, we have also have put these processes into tuned, less privileged app containers, again with a custom-crafted container profile built from capabilities.
Impact to attackers
Making the Microsoft Edge content process run in this tighter sandbox reduces the sandbox attack surface, but by how much? As it turns out, the reduction is quite significant:
100% reduction access to MUTEXes: allow a process to lock up a resource, causing hangs.
90% reduction in access to WinRT and DCOM APIs: this is the large win here, dramatically reducing Microsoft Edge’s attack surface against the WinRT API set.
40% reduction in access to devices: Windows supports many device drivers, and their quality is somewhat beyond Microsoft’s control. The tuned sandbox cuts off access to any device that Microsoft Edge does not explicitly need, preventing attackers from using vulnerabilities in device drivers to escape, or from abusing the devices.
While attack surface reduction does not guarantee that an attacker cannot escape the sandbox, it does dramatically reduce the opportunities for attack, much like reducing the number of windows and doors in a fortress. In addition, the enabling of additional exploit mitigations for the brokers that Microsoft Edge is legitimately able to access also increases the difficulty of exploiting vulnerabilities that remain.
Security is a process, not a destination, so we will continue to invest in both RCE and sandbox mitigations for Microsoft Edge. These exploit mitigations combined with the strengthened sandboxing should make Microsoft Edge significantly more work for attackers to exploit, and thus discourage attackers from trying in the first place.
Some of the most important security features in modern web browsers are those that you never actually see as you browse the web. These security features work behind the scenes to protect you from browser-based vulnerabilities that could be abused by hackers to compromise your device or personal data.
In previous blog posts and presentations, we described some of the recent improvements that have been made to Windows 10 and Microsoft Edge in this space. Today we’re kicking off a two-part blog post that describes our vulnerability mitigation strategy and provides a technical deep-dive into some of the major security improvements that are coming to Microsoft Edge in the Creators Update of Windows 10.
Framing our Vulnerability Mitigation Strategy
Before we dive in, it may help to start with an overview of how we approach the problem of web browser vulnerabilities. The Microsoft Edge security team employs a layered, data-driven defense strategy that focuses investments at key points along the kill-chain that attackers follow when exploiting vulnerabilities.
First and foremost in this strategy, we look for ways to eliminate classes of vulnerabilities by reducing attack surface and by finding or mitigating specific patterns of vulnerabilities (such as use after free issues, see MemGC). In this way, we try to counter the classic asymmetry between attackers and defenders, e.g. where attackers only need to find one good security issue whereas defenders need to ensure there are none.
Still, we assume that we won’t be able to eliminate all vulnerabilities, so we look for ways to break the techniques that attackers can use to exploit them. This helps to spoil the recipes that attackers prefer to use when trying to transform a vulnerability into a way of running code on a device. This further counters the asymmetry by removing the underlying ingredients and primitives that enable vulnerabilities to be exploited.
We assume that we won’t be able to break all exploits, so we look for ways to contain damage and prevent persistence on a device if a vulnerability is exploited. We do this by once again applying the two previous tactics but this time directed at the attack surface that is accessible from code running within Microsoft Edge’s browser sandbox. This helps constrain attacker capabilities and further increases the cost of achieving their objective.
Finally, assuming all else fails, we look to limit the window of opportunity for an attacker to exploit a vulnerability by having effective tools and processes in place. On the processes side, we take advantage of the well-oiled security incident response processes in the Microsoft Security Response Center (MSRC). On the tools side, we have technologies like Windows Defender and SmartScreen which can be used to block malicious URLs that attempt to deliver an exploit and Windows Update to rapidly deploy and install security updates.
While we’re continuing to invest in security improvements along all of these fronts, the remainder of this post will focus on investments we’ve made to break techniques that are used to exploit the most common type of security issue in modern browsers: memory safety vulnerabilities. More specifically, the next section will explore the technologies we’ve built to help mitigate arbitrary native code execution.
Browser security is a difficult problem space. Despite the best efforts of all browser vendors, vulnerabilities exist and can potentially be exploited. This is why Microsoft currently offers bug bounties of up to $15,000 USD for vulnerabilities found in Microsoft Edge and up to $200,000 USD for novel mitigation bypasses and defenses as part of our Mitigation Bypass and Defense Bounty. These bounty programs reinforce our commitment to our vulnerability mitigation strategy and help us reward the great work of security researchers around the world.
Mitigating Arbitrary Native Code Execution
Most modern browser exploits attempt to transform a memory safety vulnerability into a method of running arbitrary native code on a target device. This technique is prevalent because it provides the path of least resistance for attackers by enabling them to flexibly and uniformly stage each phase of their attack. For defenders, preventing arbitrary native code execution is desirable because it can substantially limit an attacker’s range of freedom without requiring prior knowledge of a vulnerability. To this end, Microsoft Edge in the Creators Update of Windows 10 leverages Code Integrity Guard (CIG) and Arbitrary Code Guard (ACG) to help break the most universal primitive found in modern web browser exploits: loading malicious code into memory.
Hackers are developers, too
A typical web browser exploit chain consists of three parts:
An exploit for a remote code execution (RCE) vulnerability which is used to get native code running on the target device.
An exploit for elevation of privilege (EOP) vulnerability which is used to increase privileges and escape the sandbox.
A payload that leverages the obtained access to achieve the attacker’s objective (e.g. ransomware, implant, recon, etc).
These parts naturally translate into a modular design for exploits which enables attackers to select different RCE, EOP, and payload combinations based on their target. As a consequence, modern exploits ubiquitously rely on executing arbitrary native code in order to run the 2nd and 3rd stages of their exploit. By breaking this critical link in the chain, we can influence the exploit economics by invalidating the attacker’s software design assumptions and forcing refactoring costs on them.
Preventing the loading of malicious native code
An application can directly load malicious native code into memory by either 1) loading a malicious DLL/EXE from disk or 2) dynamically generating/modifying code in memory. CIG prevents the first method by enabling DLL code signing requirements for Microsoft Edge. This ensures that only properly signed DLLs are allowed to load by a process. ACG then complements this by ensuring that signed code pages are immutable and that new unsigned code pages cannot be created.
CIG: Only allow properly signed images to load
CIG was first enabled for Microsoft Edge starting with the Windows 10 1511 update. In a previous blog post, we explained how a kernel-enforced User Mode Code Integrity (UMCI) policy has been enabled for Microsoft Edge content processes that requires DLLs to be Microsoft, Windows Store, or WHQL-signed. With this policy in place, the kernel will fail attempts to load a DLL that is not properly signed. In practice, exploits do not typically rely on loading a DLL from disk, but it has been used by some exploits and it must be addressed to achieve our objective and to have a comprehensive solution. Since the Windows 10 1511 release, we’ve made additional improvements to help strengthen CIG:
Preventing child process creation (Windows 10 1607): As the UMCI policy is applied per-process, it is also important to prevent an attacker from spawning a new process with a weaker or non-existent UMCI policy. In Windows 10 1607, Microsoft Edge enabled the no child process mitigation policy for content processes which ensures that a child process cannot be created. This policy is currently enforced as a property of the token for a content process which ensures both direct (e.g. calling WinExec) and indirect (e.g. out-of-process COM server) process launches are blocked.
Enabling the CIG policy sooner (Windows 10 Creators Update): The enablement of the UMCI policy has been moved to process creation time rather than during process initialization. This was done to further improve reliability by eliminating a process launch time gap where local injection of improperly signed DLLs into a content process could occur. This was achieved by taking advantage of the UpdateProcThreadAttribute API to specify the code signing policy for the process being launched.
ACG: Code cannot be dynamically generated or modified
While CIG provides strong guarantees that only properly signed DLLs can be loaded from disk, it does not provide any guarantees about the state of image code pages after they are mapped into memory or dynamically generated code pages. This means an attacker can load malicious code by creating new code pages or modifying existing ones even when CIG is enabled. In practice, most modern web browser exploits eventually rely on invoking APIs like VirtualAlloc or VirtualProtect to do just this. Once an attacker has created new code pages, they then copy their native code payload into memory and execute it.
With ACG enabled, the Windows kernel prevents a content process from creating and modifying code pages in memory by enforcing the following policy:
Code pages are immutable. Existing code pages cannot be made writable and therefore always have their intended content. This is enforced with additional checks in the memory manager that prevent code pages from becoming writable or otherwise being modified by the process itself. For example, it is no longer possible to use VirtualProtect to make an image code page become PAGE_EXECUTE_READWRITE.
New, unsigned code pages cannot be created. For example, it is no longer possible to use VirtualAlloc to create a new PAGE_EXECUTE_READWRITE code page.
When combined, the restrictions imposed by ACG and CIG ensure that a process can only directly map signed code pages into memory. Although this is great for security, ACG introduces a serious complication: modern web browsers rely on Just-in-Time (JIT) compilers for best performance. How can we satisfy both needs?
Supporting Just-in-Time (JIT) Compilers
Impact on attackers
Together, CIG and ACG provide strong protection against a fundamental primitive that is ubiquitously used when exploiting web browser vulnerabilities. This means attackers must develop new methods for chaining the stages of their exploits.
In the Windows 10 Creators Update, CIG is enabled by default for Microsoft Edge, except for scenarios where certain incompatible extensions are present (such as IMEs) – in these scenarios, both CIG and ACG are currently disabled by default.
For compatibility reasons, ACG is currently only enforced on 64-bit desktop devices with a primary GPU running a WDDM 2.2 driver (the driver model released with the Windows 10 Anniversary Update), or when software rendering is use. For experimental purposes, software rendering can be forced via Control Panel ->Internet Options -> ”Advanced”. Current Microsoft devices (Surface Book, Surface Pro 4, and Surface Studio) as well as a few other existing desktop systems with GPU drivers known to be compatible with ACG are opted into ACG enforcement. We intend to improve the coverage and accuracy of the ACG GPU opt-in list as we evaluate the telemetry and feedback from customers.
One of the limitations of CIG and ACG is that they don’t prevent an attacker from leveraging valid signed code pages in an unintended way. For Example, this means attackers could still use well-known techniques like return-oriented programming (ROP) to construct a full payload that doesn’t rely on loading malicious code into memory. In order to help keep signed code “on the rails” as it executes, Microsoft Edge takes advantage of Control Flow Guard (CFG) which applies a control-flow integrity policy to indirect calls. In the future, we hope to further mitigate control-flow hijacking such as by taking advantage of Intel’s Control-flow Enforcement Technology (CET) to protect return addresses on the stack.
Finally, it should be noted that the use of CIG and ACG in Edge is not intended to fully prevent privileged code running on the system from injecting unsigned native code into a content process. Rather, these features are intended to prevent the scenario of the content process itself attempting to load malicious native code.
In an upcoming post, we’ll shift gears to focus on some of the major improvements that have been made to strengthen containment and isolation for Microsoft Edge in the Creators Update of Windows 10. These improvements provide the next line of defense in our efforts to help prevent web browser vulnerabilities from being used to compromise your device or personal data.
― Matt Miller, Principal Security Software Engineer, MSRC
We are happy to introduce support for Content Security Policy Level 2 (CSP2) in Microsoft Edge, another step in our ongoing commitment to make Microsoft Edge the safest and most secure browser for our customers. CSP2, when used correctly, is an effective defense-in-depth mechanism against cross site scripting and content injection attacks.
This is available in the Insider Fast ring now starting with EdgeHTML 15.15002, and will ship to stable builds with the Windows 10 Creators Update.
Content Security Policy, supported in all versions of Microsoft Edge, lets web developers lock down the resources that can be used by their web application, helping prevent cross-site scripting attacks that remain a common vulnerability on the web. However, the first version of Content Security Policy was difficult to implement on websites with inline script elements that either pointed to script sources or that contained script directly.
CSP2 makes these scenarios easier by adding support for nonces and hashes for script and style resources. A nonce is a cryptographically strong random value generated on each page load that appears in both the CSP policy and in the script tags in the page. Using nonces can help to minimize maintaining a list of allowed source URL values, while also allowing trusted script declared in script elements to run.
In order to use a nonce in an existing template based web application a developer adds a nonce token for each of the trusted inline scripts:
&lt;script nonce=&quot;NonceToken&quot;&gt;alert(&quot;Allowed since NonceToken is declared&quot;)&lt;/script&gt;
&lt;script nonce=&quot;NonceToken&quot; src=&quot;https://trustedscriptsource.com.script&quot;&gt;&lt;/script&gt;
When the page is dynamically generated on load, the server generates a nonce value, inserts it into the NonceToken in the page and also declares it in the Content Security Policy HTTP header:
This CSP configuration allows script to be downloaded and executed from the page’s own domain, or from https://example.com. If a script source declaration in the page includes the correct nonce value, regardless of the source URL, that script can be downloaded and executed.
Script that does not meet these requirements would not even be downloaded by Microsoft Edge. In addition, any inline script that had the correct nonce value would be allowed to execute, but no other inline script would run.
CSP2 also adds support for the following:
The new directives base-uri, child-src, form-action, frame-ancestors and plugin-types are now supported. See supported CSP directives for more.
Background worker scripts are governed by their own policy, separate from the policy of the document loading them. As with host documents, you can set the CSP for a worker in the response header.
A new event, SecurityPolicyViolationEvent, is now fired upon CSP violations. As well, several new fields have been added to the violation report object including effectiveDirective (the policy that was violated), statusCode (the HTTP response code), sourceFile (the URL of the offending resource), lineNumber, and columnNumber.
CSP2 is an important step for Microsoft Edge to continue to improve the security stance and defense-in-depth capabilities of web application developers, but there’s plenty still to do. Next, we’ll focus on adding support for strict-dynamic from the CSP3 spec to enable developers and site administrators to reduce their reliance on whitelists and tighten their CSP implementations.
Another CSP directive on our radar is upgrade-insecure-requests. This directive is meant to make it even easier for a site administrator to move towards using all secure transports, while avoiding having to make massive updates to URL’s in their web applications.
A more secure web is better for developers, users, and browser vendors alike, and we would love to see more web applications taking advantage of the protections that CSP offers. A good resource for thinking through an implementation is Implementing Content Security Policy. Give it a try and let us know if you run into any issues in Microsoft Edge!
Adobe Flash has been an integral part of the web for decades, enabling rich content and animations in browsers since before HTML5 was introduced. In modern browsers, web standards pioneered by Microsoft, Adobe, Google, Apple, Mozilla, and many others are now enabling sites to exceed those experiences without Flash and with improved performance and security. Starting in the Anniversary Edition of Windows 10, we began to give users more control over Flash by selectively pausing certain Flash content, like ads, that were not central to the page.
In our next release, we will extend this functionality and encourage the transition to HTML5 alternatives by providing additional user control over when Flash content loads. Windows Insiders will be able to try an early implementation of this feature soon in upcoming preview builds. The user experience will evolve as we move towards a stable release in the Windows 10 Creator’s Update next year.
Sites that support HTML5 will default to a clean HTML5 experience. In these cases, Flash will not even be loaded, improving performance, battery life, and security. For sites that still depend on Flash, users will have the opportunity to decide whether they want Flash to load and run, and this preference can be remembered for subsequent visits.
Sample of the user experience when the user clicks on a blocked Flash control.
We are deeply aware that Flash is an integral part of many web experiences today. To ease the transition to HTML5, these changes initially will not affect the most popular sites which rely on Flash today. In the coming months, we will actively monitor Flash consumption in Microsoft Edge and will gradually shorten the list of automatic exceptions. At the end of this process, users will remain in control, and will be able to choose Flash for any site they visit.
This change will provide all users improved performance, greater stability, and stronger security. These changes are similar to updates coming from our friends at Apple, Mozilla, and Google. We look forward to continued work with these partners, and with Adobe, to improve the capabilities and security of the web for all users.
― John Hazen, PM Manager, Microsoft Edge
― Crispin Cowan, Senior Program Manager, Microsoft Edge
The SHA-1 hash algorithm is no longer secure. Weaknesses in SHA-1 could allow an attacker to spoof content, execute phishing attacks, or perform man-in-the-middle attacks when browsing the web. Microsoft, in collaboration with other members of the industry, is working to phase out SHA-1. We have outlined our timeline for SHA-1 deprecation in earlier posts, most recently in April. This post is to clarify some of our most commonly asked questions, and to help you test ahead of time.
Starting on February 14th, 2017, Microsoft Edge and Internet Explorer 11 will prevent sites that are protected with a SHA-1 certificate from loading and will display an invalid certificate warning. Though we strongly discourage it, users will have the option to ignore the error and continue to the website.
This will only impact SHA-1 certificates that chain to a Microsoft Trusted Root CA. Manually-installed enterprise or self-signed SHA-1 certificates will not be impacted, although we recommend for all customers to quickly migrate to SHA-256.
Additional information on Microsoft’s overall SHA-1 deprecation plans can be found on TechNet.
Microsoft Edge will display an invalid certificate warning when browsing to a site protected with a SHA-1 certificate
Frequently asked questions
How can I test if my site will be impacted?
By installing the latest November 2016 Windows Updates, including the November 2016 Preview of Monthly Quality Rollups for Windows 7/Windows 8.1, you can test how your site will be impacted by the February 2017 update. Please note that the Windows 7 and Windows 8.1 updates are currently offered as Optional Updates on Windows Update, and are expected to be promoted to Recommended Updates on December 13th, 2017. You can test by running the following commands from an Administrator Command Prompt:
First, create a logging directory and grant universal access:
icacls %LogDir% /grant *S-1-15-2-1:(OI)(CI)(F)
icacls %LogDir% /grant *S-1-1-0:(OI)(CI)(F)
icacls %LogDir% /grant *S-1-5-12:(OI)(CI)(F)
icacls %LogDir% /setintegritylevel L
Next, enable certificate logging and SHA-1 blocking:
How will other Windows applications and older versions of Internet Explorer be impacted?
Third party Windows applications that use the Windows cryptographic API set and older versions of Internet Explorer will not be impacted by the February 2017 changes by-default.
How will SHA-1 client authentication certificates be impacted?
The February 2017 update will not prevent a client using a SHA-1 signed certificate from being used in client authentication.
What about cross-signed certificates?
Windows will only check if the thumbprint of the root certificate is in the Microsoft Trusted Root Certificate Program. A certificate cross-signed with a Microsoft Trusted Root that chains to an enterprise/self-signed root would not be impacted by the changes planned for February 2017.
― Alec Oot, Senior Program Manager
― Jody Cloutier, Senior Program Manager
We’re determined to make Microsoft Edge the safest and most secure browser. Over the past two years, we have been continuously innovating, and we’re proud of the progress we’ve made. This is reflected by Microsoft Edge having the fewest vulnerabilities of any major browser on Windows since our release last year.
Browser vulnerabilities (as of September 2016) for Microsoft Edge, Chrome, and Firefox (per the National Vulnerability Database) since Microsoft Edge was released.
While no modern browser—or any complex application—is free of vulnerabilities, the majority of the vulnerabilities for Microsoft Edge have been responsibly reported by professional security researchers who work with the Microsoft Security Response Center (MSRC) and the Microsoft Edge team to ensure customers are protected well before any attacker might use these vulnerabilities in the wild. Even better, there is no evidence that any vulnerabilities have been exploited in the wild as zero-day attacks.
However, many businesses worldwide have come under increasing threat of targeted attacks, where attackers are crafting specialized attacks against a particular business, attempting to take control of corporate networks and data. For the most security-conscience businesses, we are introducing a new layer of defense-in-depth protection: Windows Defender Application Guard for Windows 10 Enterprise. Application Guard provides unprecedented protection against targeted threats using Microsoft’s Hyper-V virtualization technology.
Understanding targeted attacks against large Enterprises
The threat landscape has changed significantly in recent years. Today, over 90% of attacks use a hyperlink to initiate the attack to steal credentials, install malware, or exploit vulnerabilities.
This is damaging not only to the business attacked, but also to the thousands, if not millions of users whose accounts and personal data may be stolen. Highly motivated and persistent attackers will often start with a social engineering trick: creating a well-crafted and personal email to known employees of the company. This email, which will often appear to be from a legitimate authority in the company, may ask the employee to click a link to read a supposedly important document. Unfortunately, that link is to a specially crafted malicious web site that may use a previously undisclosed vulnerability to install malware on the user’s machine. Once established on that single computer, the attackers can then steal credentials and start to probe the rest of the network for other vulnerable machines, repeating the process on other computers until they achieve their objective, whether that is stealing data, intellectual property, or disrupting the business.
Breaking the attacker playbook
We’re taking a systematic approach to disrupting these attackers by providing our customers with the tools they need to defend against these vectors of attack. Application Guard is designed to stop attackers from establishing a foothold on the local machine or from expanding out into the rest of the corporate network.
By using our industry leading virtualization technology, potential threats are not only isolated from the network and system, but will be completely removed when the container is closed.
Digging deeper into Application Guard
Application Guard leverages virtualization technology born in the Microsoft Cloud to accomplish this disruption.
When a user browses to a trusted web site, for example an internal accounting system web application, Microsoft Edge operates as it does today. It has access to local storage, can authenticate the user to internal sites with corporate credentials, standard cookies work, the user can save files to the local machine, and in general Windows just works. This mode, outlined in blue in the chart below, is known as the Host version of Windows.
Application Guard isolates untrusted sites in a new instance of Windows at the hardware layer.
However, when an employee browses to a site that is not recognized or trusted by the network administrator, Application Guard steps in to isolate the potential threat. As shown in the mode outlined in red above, Application Guard creates a new instance of Windows at the hardware layer, with an entirely separate copy of the kernel and the minimum Windows Platform Services required to run Microsoft Edge. The underlying hardware enforces that this separate copy of Windows has no access to the user’s normal operating environment.
Application Guard’s enforcement includes completely blocking access to memory, local storage, other installed applications, corporate network endpoints, or any other resources of interest to the attacker. This separate copy of Windows has no access to any credentials, including domain credentials, that may be stored in the permanent credential store.
Most of the time, even untrusted sites are not malicious and perfectly safe to visit, and the user just expects them to work. This isolated environment allows these sites to function essentially as they would if they were running on the host version of Windows. In this case Application Guard does provide the essential features that users would expect to work, even when browsing untrusted sites, such as being able to copy and paste with the Windows clipboard, and being able to print content from those web sites to their work printer. This allows the user to still be productive even while the host is being protected by Application Guard. The enterprise administrator has control over this functionality using Microsoft management tools and policy, and can choose what they are comfortable with based on their own risk assessment.
Defense-in-depth isolation for enterprises
To improve on the security offered by purely software based sandboxes, Microsoft worked with several enterprise and government customers on a hardware based isolation approach to address these concerns. With Application Guard, Microsoft Edge protects your enterprise from advanced attacks that can infiltrate your network and devices via the Internet, creating a safer, worry-free browsing experience for customers.
But what happens when the untrusted site is actually part of an attacker’s malicious plan? Let’s revisit the attack described above. An attacker sends a well-crafted email to an innocent employee of the company enticing them to visit a link on a site under the attacker’s control. The innocent user, not noticing anything suspicious about the mail, clicks on the link to an untrusted location. In order to proactively keep the user and enterprise resources safe, Application Guard coordinates with Microsoft Edge to open that site in a temporary and isolated copy of Windows. In this case, even if the attacker’s code is successful in attempting to exploit the browser, the attacker finds their code running in a clean environment with no interesting data, no access to any user credentials, and no access to other endpoints on the corporate network. The attack is completely disrupted. As soon as the user is done, whether or not they are even aware of the attack having taken place, this temporary container is thrown away, and any malware is discarded along with it. There is no way for the attacker to persist on that local machine, and even a compromised browser instance has no foothold to mount further attacks against the company’s network. After deletion, a fresh new container is created for future browsing sessions.
Web developers and Application Guard
The good news for web developers is that they do not need to do anything different with their site code – Microsoft Edge renders sites in Application Guard fundamentally the same way it does in the host version of Windows. There is no need to detect when Microsoft Edge is running in this mode, nor any need to account for behavior differences. Since this temporary container is destroyed when the user is done, there is no persistence of any cookies or local storage when the user is finished.
We’re committed keeping Enterprise users and data safe and secure
Our mission at Microsoft is to empower every person and every organization on the planet to achieve more. With Windows Defender Application Guard, enterprise users can take advantage of the vast power of Internet sites and services while still protecting corporate and personal data. This capability makes Microsoft Edge the most secure browser for the Enterprise.
― John Hazen, Principal Program Manager, Microsoft Edge
― Chas Jeffries, Principal Program Manager, Application Guard