{ "id": "1d4e9ee7-25a4-471f-aa05-c3cc2357ba36", "created_at": "2026-04-06T00:21:06.567562Z", "updated_at": "2026-04-10T13:12:11.05345Z", "deleted_at": null, "sha1_hash": "300465f1872fe9186caf11e07c1e6eaa740d9342", "title": "Strengthening the Microsoft Edge Sandbox", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 198653, "plain_text": "Strengthening the Microsoft Edge Sandbox\r\nBy Microsoft Edge Blog\r\nPublished: 2017-03-23 · Archived: 2026-04-05 18:25:51 UTC\r\nIn a recent post, we outlined the layered strategy that the Microsoft Edge security team employs to protect you\r\nfrom vulnerabilities that could be used to compromise your device or personal data. In particular, we showed how\r\nMicrosoft Edge is leveraging technologies like Code Integrity Guard (CIG) and Arbitrary Code Guard (ACG) to\r\nbreak some of the techniques that hackers rely on when exploiting vulnerabilities to obtain Remote Code\r\nExecution (RCE). This is where the attacker seeks to escape from web code (JS and HTML) in the browser to run\r\nnative CPU code of the attacker’s choosing. This lets the attacker violate all of the browser’s rules for the web,\r\nsuch as same-origin policy, and so it is important to web users that we try as hard as possible to block RCE\r\nattacks.\r\nHowever, despite our best efforts, sometimes attackers get RCE anyway. In this post, we’ll explore some of the\r\nsignificant improvements we’ve made in the Windows 10 Creators Update to strengthen our next line of defense:\r\nthe Microsoft Edge sandbox.\r\nThe history of the Microsoft Edge sandbox\r\nBecause RCE can happen, and in the past, often did, browser vendors have sought to sandbox the browser to\r\ndefend the rest of the user’s PC from attack. In 2007, IE7 introduced Protected Mode, the first web browser\r\nsandbox. Windows 8 added app container to the OS, primarily to support the new Windows Store app model and\r\nsupport the confidence promise that apps are safe to use. IE10 and IE11 leveraged app container to create EPM\r\n(Enhanced Protected Mode) a stronger browser sandbox. However, the EPM sandbox restrictions were\r\nincompatible with older ActiveX controls that predated app container, and so EPM was provided as a security\r\nenhancing option.\r\nMicrosoft Edge does not support ActiveX, so it is able to run entirely inside app container sandboxes at all times.\r\nSince the beginning, Microsoft Edge has used several app containers. At first there was a parent app container for\r\nthe Manager, which created a small number of additional app containers to host content from the internet separate\r\nfrom intranet content. The Windows 10 Anniversary Update moved Flash into its own, separate AC. Today the\r\nMicrosoft Edge app container model looks like this:\r\nhttps://blogs.windows.com/msedgedev/2017/03/23/strengthening-microsoft-edge-sandbox/\r\nPage 1 of 5\n\nThe Manager provides browser features such as the URL bar, the back button, tabs, and your favorites list. The\r\nother app containers are:\r\nInternet AC: hosts content from Internet sites.\r\nIntranet AC: hosts content from Intranet sites. For enterprise users, that is enterprise web sites. For\r\nconsumers, that is “web sites” that are control interfaces for devices on your home network, such as your\r\nWi-Fi router, or IoT devices. Separating this RAC from the Internet e.g. protects your home Wi-Fi router\r\nfrom Internet attackers.\r\nExtensions AC: hosts the new extensions for Microsoft Edge.\r\nFlash AC: hosts the Adobe Flash player, to isolate it from the main content processes.\r\nService UI AC: hosts special web pages, such as about:flags, and the default home page.\r\nThe Internet AC is where the action is. Its job is to host web pages from anywhere, including the JS code provided\r\nby that web page, images, and multimedia. Hosting web pages is extremely complex, due to the richness of the\r\nmodern web; this is the platform of the Internet, and developers need to be able to create any application and run it\r\nin this environment. Because it is complex, and hosts web pages from anywhere, this is where web security\r\nattacks begin. A malicious web site presents content intended to exploit bugs in the content hosting system, to take\r\nover control of the content process.\r\nIf an attacker gains control of an Internet AC process, they need to find some way to achieve their goals. If their\r\ngoals involve compromising the user’s device or personal data stored on the device, then they’ll need to contend\r\nwith escaping from the sandbox first.\r\nReducing the attack surface of the Microsoft Edge sandbox\r\nOne of the most effective ways to eliminate vulnerabilities in complex applications is to minimize the amount of\r\ncode that an attacker can try to find vulnerabilities in. This is often referred to as attack surface reduction and it is\r\na key tactic in our overall strategy security. To this end, Microsoft Edge in the Creators Update of Windows 10 has\r\nsignificantly reduced the attack surface of the sandbox by configuring the app container to further reduce its\r\nprivilege.\r\nTo understand how we tuned the Microsoft Edge AC, it is first necessary to know how app container itself works.\r\nAn app container process is deny-by-default for any secured object unless the object security descriptor has an\r\nallow access control entry (ACE) that would permit the app container to have access. There are three kinds of\r\nSIDs that can be used in such ACEs:\r\nhttps://blogs.windows.com/msedgedev/2017/03/23/strengthening-microsoft-edge-sandbox/\r\nPage 2 of 5\n\nCapabilities: if a Capability SID based allow ACE is in the security descriptor, and the requesting AC has\r\nthat Capability SID in its token, then it gets access. E.g. Webcam-related devices are accessible to\r\nprocesses that have the WEBCAM Capability SID such as Microsoft Edge.\r\nAppID SIDs: if a specific AppID SID based allow ACE is in the security descriptor, and the requesting AC\r\nis that specific AppID, then it gets access. The main use for this is per-app storage, which uses the AppID\r\nof that app in the security descriptor, ensuring that its storage is private to that app.\r\n“ALL APPLICATION PACKAGES” (“AC” SID): this is the AC wild card, allowing all app containers to\r\naccess the resource. The “AC” SID exists so that Windows can provide an app platform that is useful to\r\ndevelopers, allowing rich UWPs in the Windows Store. For instance, most of the WinRT API surface is\r\nopen to the “AC” SID, so that all UWP apps can access the WinRT APIs.\r\nThe Microsoft Edge AC has been made different in only one way: the “AC” SID is not sufficient to let a\r\nrequesting process access a resource. To get access, the AC must either have a matching Capability SID, or be\r\nprecisely one of the named AppIDs in the security descriptor.\r\nThus the AC loses access to the entire WinRT API set, and every other resource that app containers normally can\r\naccess. That’s great for security, with the slight problem that it would break everything about the browser, turning\r\nit into a highly secure brick.\r\nMicrosoft Edge “Tuned” AC\r\nhttps://blogs.windows.com/msedgedev/2017/03/23/strengthening-microsoft-edge-sandbox/\r\nPage 3 of 5\n\n“Normal” app container\r\nSo to make Microsoft Edge work again, we used specific Capabilities to light up specific areas of functionality.\r\nFor instance, we created a Capability that enables COM to work. We similarly added other new capabilities,\r\ngranting access to specific resources, until Microsoft Edge worked again. Then we added some telemetry to detect\r\naccess control failures for the content process and shared it to users in the Windows Insider Program (WIP) to\r\nensure that we had granted access to all resources needed for all scenarios.\r\nWhat we just did here was to create a tuned sandbox for the Microsoft Edge content process, with a much tighter\r\nfit to the functional needs of the software than a normal app container provides. That is a lot of work, which is\r\nwhy this is not how the UWP platform works. But because web browsers are among some of the most threatened\r\nsoftware there is, it is worth it in this case.\r\nWe repeated this work of hand-tuning a sandbox for the Flash AC, because it also is subject to a lot of attacks.\r\nPlacing Flash in a tighter sandbox complements our work in this release to make Flash be click-to-run.\r\nMaking it more difficult to exploit sandbox escape vulnerabilities\r\nThe main threats in a sandbox are the broker interfaces that provide access to resources according to a defined\r\npolicy. So why have brokers at all? Brokers exist to grant access according to policy, e.g. the File broker allows a\r\nwebsite to say “upload a file by browsing your files” and the user gets to pick the file to be uploaded, without\r\ngiving the web site access to all of the user’s files.\r\nBrokers are a threat to sandboxes because brokers are code (and therefore can have bugs) and because the brokers\r\nrun outside the sandbox. If an attacker can hack a broker and run code in the broker, then the attacker can escape,\r\nsimilar to an inmate mugging a prison guard and then putting on the guard’s uniform to escape.\r\nThe tightened Microsoft Edge content process sandbox cuts off access to many brokers (reduced attack surface)\r\nbut leaves the needed brokers accessible (residual threat). An attacker might try to exploit bugs in the accessible\r\nbrokers to elevate privileges and execute arbitrary native code in the broker, and thus escape. To mitigate this\r\nhttps://blogs.windows.com/msedgedev/2017/03/23/strengthening-microsoft-edge-sandbox/\r\nPage 4 of 5\n\nthreat, we have applied many of the same exploit mitigation technologies to the brokers that provide service to\r\nMicrosoft Edge.\r\nMicrosoft Edge also has some surprising brokers, because the exploit mitigation work forced several components\r\nto move out-of-process (OOP), including the Chakra JIT code generator and the Flash runtime process. These\r\ncomponents had to move out of process because they necessarily do code generation (JIT) and that is not\r\ncompatible with the ACG mitigation applied to the content process. Thus, these components function as the “JS\r\ncode generator” broker and the “Run Flash bytecode” broker.\r\nThey can be viewed as brokers precisely because they have permission to do something that the content process is\r\nnot permitted to do for itself. They are also a threat, because an attacker that can gain control of OOP JIT or the\r\nFlash sandbox could e.g. create executable code and use that for further exploitation, bypassing ACG. Because\r\nthey are a threat, we have also have put these processes into tuned, less privileged app containers, again with a\r\ncustom-crafted container profile built from capabilities.\r\nImpact to attackers\r\nMaking the Microsoft Edge content process run in this tighter sandbox reduces the sandbox attack surface, but by\r\nhow much? As it turns out, the reduction is quite significant:\r\n100% reduction access to MUTEXes: allow a process to lock up a resource, causing hangs.\r\n90% reduction in access to WinRT and DCOM APIs: this is the large win here, dramatically reducing\r\nMicrosoft Edge’s attack surface against the WinRT API set.\r\n70% reduction access to events and symlinks: symlinks are especially interesting, because they are often\r\nused in creative bait \u0026 switch attacks to escape sandboxes.\r\n40% reduction in access to devices: Windows supports many device drivers, and their quality is somewhat\r\nbeyond Microsoft’s control. The tuned sandbox cuts off access to any device that Microsoft Edge does not\r\nexplicitly need, preventing attackers from using vulnerabilities in device drivers to escape, or from abusing\r\nthe devices.\r\nWhile attack surface reduction does not guarantee that an attacker cannot escape the sandbox, it does dramatically\r\nreduce the opportunities for attack, much like reducing the number of windows and doors in a fortress. In addition,\r\nthe enabling of additional exploit mitigations for the brokers that Microsoft Edge is legitimately able to access\r\nalso increases the difficulty of exploiting vulnerabilities that remain.\r\nConclusion\r\nSecurity is a process, not a destination, so we will continue to invest in both RCE and sandbox mitigations for\r\nMicrosoft Edge. These exploit mitigations combined with the strengthened sandboxing should make Microsoft\r\nEdge significantly more work for attackers to exploit, and thus discourage attackers from trying in the first place.\r\n― Crispin Cowan, Senior Program Manager, Microsoft Edge\r\nSource: https://blogs.windows.com/msedgedev/2017/03/23/strengthening-microsoft-edge-sandbox/\r\nhttps://blogs.windows.com/msedgedev/2017/03/23/strengthening-microsoft-edge-sandbox/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://blogs.windows.com/msedgedev/2017/03/23/strengthening-microsoft-edge-sandbox/" ], "report_names": [ "strengthening-microsoft-edge-sandbox" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434866, "ts_updated_at": 1775826731, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/300465f1872fe9186caf11e07c1e6eaa740d9342.pdf", "text": "https://archive.orkl.eu/300465f1872fe9186caf11e07c1e6eaa740d9342.txt", "img": "https://archive.orkl.eu/300465f1872fe9186caf11e07c1e6eaa740d9342.jpg" } }