Live data from Hacker News

Strengthening the Microsoft Edge Sandbox

blogs.windows.com

51–58 of 58 posts

Re: Strengthening the Microsoft Edge Sandbox

#51

I didn't see this mentioned in the blog posts but I believe Edge also has win32k filtering[1] to reduce the kernel attack surface as well (added in the AU). This is different from the win32k lockdown that Chrome uses which completely blocks all win32k syscalls but instead allows a whitelist(?) for acceptable syscalls to help reduce the attack surface (I'm not actually sure how it works). It seems the signature is che…

So, the thing we call "win32k lockdown" on Chrome is just a term for the various things we had to do to enable ProcessSystemCallDisablePolicy on our sandboxed renderer processes (the processes that handle Web content). ProcessSystemCallDisablePolicy is a very big hammer, because enabling it prior to process launch means the kernel blocks all GDI and NTUser calls, such that the process can't interact with the UI or graphics subsystems. Chrome can do this because our UI and graphics acceleration layer is split into our unsandboxed browser process and the more weakly sandboxed GPU process.

The difference with Edge and IE is that they run their UI and graphics stack in their content processes, which are an analog to Chrome's renderer processes. However, any UI on Windows requires win32k kernel support, so they can't disable it like Chrome does. Instead, Edge uses its win32k filter to limit the attack surface to only the calls that they need. So, where Chrome's architecture allowed us to make an aggressive cut, Microsoft is instead working to iteratively shut off the same attack surface in Edge.

And yes, the win32k whitelist is currently restricted to EdgeHTML processes by the kernel and signature enforcement. I know this because we currently sandbox our GPU process at about the same level as an IE content process, and we wanted to use the win32k whitelist get the same improvements as Edge. Unfortunately, Microsoft is still working on the capability, and is not ready to expose it to third-parties yet (but has given signs they may be willing to do so in the future).

Source: I lead engineering on Chrome security and am the original architect of Chrome's win32k lockdown.

Re: Strengthening the Microsoft Edge Sandbox

#52
post #11

It's nice that they're investing in this. I just wish Edge didn't suck. I have tried using it as my primary browser and it's just not there. It crashes, trying to move tabs around is a pain, sometimes it just isn't performant.

Press Ctl-T and start typing an address. Whoops! We only saw you type the last half of that address.... I hate this so much.

Same goes for the file menu in Windows Explorer.

Re: Strengthening the Microsoft Edge Sandbox

#53
post #11

It's nice that they're investing in this. I just wish Edge didn't suck. I have tried using it as my primary browser and it's just not there. It crashes, trying to move tabs around is a pain, sometimes it just isn't performant.

It opens web pages very fast, there's that. But, alas, everything else just feels sluggish. In my crazy high-end system, it takes a second for the menu to show up after right clicking the address bar. What I want is IE's rendering speed with Chrome's UI and Firefox's extensibility (the good old system, not the new one).

> What I want is IE's rendering speed with Chrome's UI and Firefox's extensibility (the good old system, not the new one).

I'll also take Opera's built in vpn, iridium's privacy measures, vivaldi's dev tools, and blisk's mobile preview feature.

Re: Strengthening the Microsoft Edge Sandbox

#54

Edge was the most hacked browser [1] (5 times) in pwn2own 2017 contest. In contrast chrome faced only one unsuccessful hacking attempt. This blog post looks more like a damage control measure. [1] http://www.tomshardware.com/news/pwn2own-2017-microsoft-edge...

> chrome faced only one unsuccessful hacking attempt

One UNsuccessful attempt? Does that mean only one attempt on chrome was made?

Re: Strengthening the Microsoft Edge Sandbox

#55

Edge was the most hacked browser [1] (5 times) in pwn2own 2017 contest. In contrast chrome faced only one unsuccessful hacking attempt. This blog post looks more like a damage control measure. [1] http://www.tomshardware.com/news/pwn2own-2017-microsoft-edge...

> chrome faced only one unsuccessful hacking attempt One UNsuccessful attempt? Does that mean only one attempt on chrome was made?

The team that was trying to hack chrome, could not do it in allocated time.

https://www.zerodayinitiative.com/blog/2017/3/15/the-results...

Re: Strengthening the Microsoft Edge Sandbox

#56
post #50
post #38

Earlier quoted context omitted.

As Chakra is part of Edge, then Edge is not fully closed source.

Edge is closed source. You have no way of verifying the build of Chakra used is the same as the open source version. Well it might be possible to reproduce a build of Chakra to do a binary comparison but i am not aware of anyone doing it.

There's nothing stopping you from compiling https://github.com/Microsoft/ChakraCore and checking if Chakra.dll matches that which is distributed with Edge.

Re: Strengthening the Microsoft Edge Sandbox

#57
post #56
post #50

Earlier quoted context omitted.

Edge is closed source. You have no way of verifying the build of Chakra used is the same as the open source version. Well it might be possible to reproduce a build of Chakra to do a binary comparison but i am not aware of anyone doing it.

There's nothing stopping you from compiling https://github.com/Microsoft/ChakraCore and checking if Chakra.dll matches that which is distributed with Edge.

AFICT you cannot build a like-for-like chakra.dll from ChakraCore due to https://github.com/Microsoft/ChakraCore#using-chakracore

The chakra.dll that comes as part of Windows/Edge includes the additional parts not included with ChakraCore (at least that is how it reads to me).

Re: Strengthening the Microsoft Edge Sandbox

#58

Earlier quoted context omitted.

Sure, it does sound interesting. Now what about all EMET mitigations that Microsoft is deprecating by saying Windows 10 is "secure enough" as is?

Most of them are just built into Windows now and are accessible through both the registry[1] and at runtime[2][3]. The latter requires recompiling with source code changes but the former can be applied to any application. The EMET mitigations which are no longer supported have either been depreciated because of better ones (control flow guard) or are not terribly effective (EAF/EAF+, use of debug registers). [1] http…

I get your point, but most does not mean all, and hardening is all about adding layers. https://insights.sei.cmu.edu/cert/2016/11/windows-10-cannot-... is a complete review of the mitigations we are loosing.
Post reply on HN