I'm up to page 12 and I feel like jumping off of the nearest bridge. I don't know what's worse; the bu****it bickering between keyboard warriors to see who can flex their e-muscles the most (and the overuse of IMO/IMHO but typing to the contrary) or the lack of comprehension when reading/replying to previous posts... just to turn around pages later and rip out comments like "oh, I don't use SBIE but..." or "oh, I don't use Chrome, but..." *laughs* I am having flashbacks to the AppGuard thread; read through xxx pages just to come out with 10 pages of intelligent information. EDIT: I want my day back.
I don't even know why you bothered to "up" this thread. I thought the first pages weren't that bad, it spun out of control after the 12th page.
so chrome have disclosed a windows vulnerability which is mitigated by win32 lockdown mode. However they decided to stop using it on windows 8.1 even tho it is supported for a unknown reason, anyone know why? https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/7UvooanQogg
If I understand correctly from reading through bug reports for hours last night, the win32-lockdown is supported on Windows 8.1 Update 3 and Windows 10. However, the Chromium team only enabled it by default (and removed flag) specifically for the Chromium renderer process on Windows 10. They seem to have run into some issues on Windows 8.1 Update 3 that made them decide to exclude the win32k lockdown for renderer by default. There still remains, of course, the win32 lockdown flag for PPAPI plugin processes.
thanks for looking into it, is appreciated. I had enabled it just incase it still works, and from your reply it suggests it still will work for PPAPI stuff but not for rendering processes.
@chrcol You're welcome. Yes, that is my assumption. However, it is always good to check to be absolutely certain of what is going on behind the scenes. I would highly suggest that you run Process Hacker and check chrome.exe renderer process (or multiple renderer processes; --type=renderer), bring up the Properties dialog for those processes, on General tab check Mitigation policies, click on Details and see if there is one for "Win32k system calls disabled" and you will know for certain. You can also use that to determine for PPAPI processes, etc.
Here is another feature that used to be win 8.1 working but mysteriously has become windows 10 only, hardware accelerated VPx playback. https://bugs.chromium.org/p/chromium/issues/detail?id=616318 Note the bug is locked down so not viewable. Its as if google decided to market windows 10. Can see here as recent as april this year, they were successfully using it on both windows 7 and 8.1. https://bugs.chromium.org/p/chromiu...atus Owner Summary OS Modified&groupby=&sort=
@Minimalist Fantastic article with nice details. Thank you for sharing. James Forshaw has done some incredible work with regard to Chromium sandboxing and, in particular, this Win32k work is crucial these days.
So it seems that the latest Google Project Zero blog post that Minimalist just posted answers your question as to why win32k-lockdown ended up being excluded from Windows 8.x for the time being. The Google developers stated that it was unstable code from AV software which was being forcefully injected into chrome.exe processes and that AV code was trying to do API calls through chrome.exe process via Win32k subsystem which in fact is what Google devs were specifically filtering. That is what caused instability on those systems and, as I understand it, was quite random and flaky. It seems that they will revisit this win32k-lockdown policy on Windows 8.x systems in the future as Microsoft updates the win32k policy code in Windows 10 systems, in hopes that AV polishes up their code accordingly, and the hope is that updated code in time will jive better with conform better with Windows 8.x systems with regard to win32k-lockdown in Chrome. So they will revisit it at another time. At least that is my understanding of the situation regarding win32k-lockdown on Windows 8.x systems after reading that article. Fantastic article, for sure. It's always great to see Google staying ahead of the game by implementing built-in OS hardening/mitigation mechanisms as early as possible. I would imagine that they will implement Return Flow Guard (as companion to Control Flow Guard) in future as well.
No need for Sandboxie, okay I might be overdoing it 1 = UAC deny elevation of unsigned executables (basic user container) 2 = About://flags #enable-appcontainer 3 = Chromium (Chrome release) with Control Flow Guard compiled by HenryPP 4 = Registry AppCompatFlags/Layers/~RunAsInvoker (only use with UAC setting block elevation of unsigned) 5 = MemProtect protected processes engagement (a pity it does not show)
So the chrome dev published info whilst allowing it to leave unfixed on win8.1 they need to revisit it now, not some time in the future.
Kees, that is a rock solid setup for Chromium and absolutely nothing slowing it down there from a performance perspective either. Multiple layers of protection mechanisms as well. I like it! One thing that I am entirely unfamiliar with is number 4 (Registry AppCompatFlags/Layers/~RunAsInvoker). I see that you suggest that you must combine that with number 1 (UAC deny elevation). So I respect that and will follow your advice on that. But one question that I do have is what exactly does number 4 do? I mean, I see that it adds the status under Virtualized column, but just not sure how it works exactly from a security perspective. If you have a moment, could you please explain that briefly or even link to a site which describes it well? Thank you. Regarding MemProtect and not showing Protection status, I also agree that it would be nice to see. However, the way in which it is intercepted entirely within the kernel makes that not possible. One thing that I tried recently was making chrome.exe a protected process and did not give Process Explorer access to it (therefore blocking memory access) and it was interesting to note that Process Explorer was unable to determine whether or not chrome.exe had ASLR protections or even Control Flow Guard mitigations. As a matter of fact, it did not show any of the 6-8 mitigations that the chrome.exe process often has, with the exception of showing the DEP status due to being system-wide, I suppose. But I thought that was quite interesting. I'm working on a solid MemProtect config right now for protecting Chromium, Adobe Reader and Microsoft Office (plus a few others such as KeePass) and will hopefully be able to share the new config over in the MemProtect thread within the next day or so. On a side note, according to Justin Schuh (Chrome security dev), there are more exciting mitigations coming to Chromium. But unfortunately a lot things are hampered and on hold due to the way that AV uses dirty tricks to inject code, etc. Link: https://twitter.com/justinschuh/status/803951374199205888
Dave, When Vista came out, M$ made it clear that UAC file and registry virtualisation was only a temporarely compatibility fix for 32 bits applications. At the same time they started to run IE and other core processes virtualized. So like UAC is not a security feature, it seems to be used by M$ as security through obscurity. When you combine it with UAC validate admin code signatures (blocking unsigned processes or processes with invalid signatures to elevate), the latter precedes, so you never run unsigned programs like Chromium with elevated rights. It is more of a smoke curtain than a security tweak to make things complicated for malware and reduce the chance of succesfull and predictable exploitation of bugs/vulnabilities (UAC validate admin code signatures = reducing attack surface, while virtualisation = redirecting in case UAC might be bypassed, than malware is faced with another kernel driver enforcing virtualisation). Just set a program to run as Admin through rightclick. Start regedit search for RUNASADMIN, then create a simular registry entry for Chrmium and give it the value ~RUNASINVOKER (and remove the admin rights from your example program). I know your are working on your master piece of isolation, but I use a simpler container approach, caging vulnarable processes in stead of completely isolating them, with Chromium, Flash and Office (link). Regards Kees
Microsoft silently fixes kernel bug that led to Chrome sandbox bypass https://threatpost.com/microsoft-silently-fixes-kernel-bug-that-led-to-chrome-sandbox-bypass
seems its not fixed in windows 7 and 8.1, I wish the reporters writing these stories stop pretending only windows 10 is relevant. Someone needs to rat microsoft out for not patching security vulns in operating systems that are not EOL.
MS didn't classify it as security vulnerability so I don't expect them to fix it in previous versions of OS.
Thanks @WildByDesign for mentioning Return Flow Guard, I also completely missed Wilders Thread about it (link), the Tencent link to the article of the OP is a nice read P.S. I enabled the RFG registry setting
I thought that too. I like what he wrote about user hooks (which a couple of members of this forum constantly post that it applies to Sandboxie when it doesn't). The power behind SBIE is the SBIE driver (usually ignored, brush off by SBIE bashers). Bo
