It will also reach Google Chrome's Canary branch soon as well. Follow here: http://omahaproxy.appspot.com/ When the "branch_base_position" reaches higher than the revision number listed in the commit. There are some Chromium builds (higher revision numbers) that contain that commit here as well: https://storage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/ But while the flags is there, I can't seem to get it working quite yet. So there may be another patch incoming in the next day or so likely.
Regarding AppContainer sandboxing for the GPU process, it appears that they are targeting Chrome stable branch version 66 release with some various testing beforehand. This is great news! Source: https://chromium-review.googlesourc...sage-da72adea4206e692a336832fd08cc1b82d115192 Also, this explains why the flag is there but the actually AppContainer creation functionality has been temporarily removed for the GPU process at the moment because it conflicted with the embedded team's usage. I assume from this that the functionality is not available to us (on master branch) but technically is still there under-the-hood for James Forshaw to still continue running tests of his own before making public.
Having been an IE user for many years I recently installed Chrome as my default browser (on Windows 7). How can I tell if Chrome's sandbox is enabled? I would also appreciate learning what other options/settings are available to harden Chrome's security.
When running Chrome, it is always running within a highly tightened security sandbox. So you are already running Chrome sandboxed on Windows 7. However, there are a few very important things to point out. The Chrome security team takes full advantage of newer security that is available only on newer Windows operating systems. For example, the AppContainer sandbox is only available on Windows 8 and above, further with AppContainer being even stronger on the latest Windows 10 operating systems. (Keep in mind, you still have Chrome running in sandbox on Windows 7, just no AppContainer.) Further, there is a plethora of high level process mitigation security in which you will notice that more and more are available with each Windows operating system release. Even with each Windows 10 major release, you will see newer process mitigation techniques. And the Chrome security team takes advantage of what is available on each operating system. Here is a good link which describes process mitigation availability with each Windows release. Link: https://chromium.googlesource.com/c...design/sandbox.md#Process-mitigation-policies There are still ways to make Chrome more secure on Windows 7 though. For example, I would start by enabling Strict Site Isolation which I believe should be available on Windows 7 by enabling the flag (chrome://flags/#enable-site-per-process). You can read more about Site Isolation here (https://support.google.com/chrome/answer/7623121?hl=en) which, within that article, has a link to the main Site Isolation documentation.
If I remember right, Strict Site Isolation will significantly increase Chrome RAM usage. Just something to be aware of, that's all. It's well worth it, as long as you have enough RAM.
@WildByDesign, thank you! - In what ways is the AppContainer sandbox different from the Chrome sandbox running on Win7?
That is explained in the very link WildByDesign posted, it saids in AppContainer renderer process can't access network. Although Chrome sandbox is very strong even without AppContainer, it's an additional protection. Chrome sandbox is already strong enough unless you can be targeted by well-resourced attacker, but you may want to block unsandboxed plugin access through settings>contents settings. I also completely block camera, microphone, notification, etc. as I don't use them, but I can still whitelist use of them site-by-site basis if I ever need. If you want to go even further - I wrote tips here, tho it is more for geeks. Maybe adding --enable-strict-powerful-feature-restrictions to shortcut or registry (as well as already mentioned --site-per-process) and disabling some obvious APIs from flags won't cause much problem as long as you just browse web pages in 'classic' style.
Restrict javascript to selected domains (whitelist): chrome://settings/content/javascript Select "Blocked" for javascript then Allow selected, for example [*.]com [*.]ca [*.]net [*.]gov ...add others when required
As always, the Chrome security team is hard at work adding more operating system level mitigations based on the OS version that is capable. [Windows Sandbox] Enable some mitigations. Link: https://chromium-review.googlesource.com/c/chromium/src/ /940528 Image Load, as we know, consists of two different mitigations. Hence the asterisk at the end. Now this is early in the dev stage so I don't know yet what their target release of Chrome they are aiming for. In another bug report I read that they had to wait until Microsoft released the next SDK and then they can target a release. Penny MacNeil and James Forshaw are fantastic devs to follow regarding OS mitigations and AppContainer and general sandboxing as well. Somewhat OT: By the way, WDEG does not show the Prefer System32 mitigation for per-process mitigations within the GUI for some reason. I assume this is a bug similar to how some of the wording in WDEG is misleading and wrong "Don't use High Entropy" for example, that actually means the opposite. Anyway, Prefer System 32 can be set manually in the registry for anyone who is familiar with my RS3 Mitigations spreadsheet but it is easy to make mistake editing REG_BINARY entries in the registry.
All of those mitigations that I mentioned in the previous post are confirmed working now in Canary (66.x/67.x on revisions higher than #540634). Initial bug reports were the developers laying the groundwork for these mitigations within the sandbox. This most recent bug report was the developers flipping the switch essentially to enable these mitigations. So these likely wont hit stable branch until version 66. Link: https://bugs.chromium.org/p/chromium/issues/detail?id=808526#c7 On a side note, anyone that has a special interest in Process Mitigations in general on Windows 10 (and integrity levels), the Chrome security developers have a source code file which seems to have better definition of individual process mitigations than Microsoft's own documentation. So I figured I would share that for anyone who is interested. Link: https://chromium.googlesource.com/c...5589e12ee28c/sandbox/win/src/security_level.h
I've read that in the last few weeks, about 3 high risk bugs were found in Chrome. So I assume this means that remote code execution was possible, and perhaps even a sandbox escape! So this would mean that if Chrome was not running under protection by SBIE, you might have had a problem, assuming AV and AE could not have blocked the malware. https://twitter.com/NedWilliamson/status/989890917816414208
Another interesting upcoming development for Chrome on Windows sandbox. [Network Process Windows Sandbox] Tracking ticket for Network Service sandboxing on Win. Link: https://bugs.chromium.org/p/chromium/issues/detail?id=841001 This commit just came in about an hour ago so there is very little detail about this at the moment.
Has anyone experienced any issues with the GPU process AppContainer? It seems to be working well here on both version 66 and 67. I had forgotten about this for a while and was just playing around with Process Hacker and Process Explorer and realized the GPU process was running within AppContainer on 66 and 67 builds that I have running on my system. These AppContainer chrome.exe processes combined with Site Isolation seems to have Chrome/Chromium ahead of the browser pack as far as security and isolation go. Particularly of importance is the separation of data with Site Isolation being significant these days with regard to Spectre-type attacks. Edge and Firefox have no answer to that as of yet, or at least nothing that can compare to Site Isolation.
By the way, if anyone wants a super useful Windows token related tool (and other sandboxing tools), have a look at Google's James Forshaw's sandbox-attacksurface-analysis-tools. Link: https://github.com/google/sandbox-attacksurface-analysis-tools/releases Most of the included tools are command line tools. However, of note, the included TokenViewer.exe binary is a GUI tool and the visibility into processes, threads and particularly token related details is phenomenal. Highly recommended. EDIT: By the way, this of course can be used with any process, not just Chrome/Chromium.
Thanks for sharing. Wow! The TokenViewer tool should really be renamed to "TheUltimateWindowsTokenTool" as it does way, way much more than 'view' tokens. One thing, the contents of the "Threads" tab is empty on my Win 8.1 system. Is it that same for you on Win 10?
Not running SBIE right now but when I was I had a small issue with Chrome. Running W7X64. Removed permissions (or set to deny) the SWReporter folder in Chrome in C:\Users\*\AppData\Local\Google\Chrome\User Data so the software reporter tool would never run or be updated. Chrome must think the software_reporter_tool.exe is messed up and tries to update it but can't put it in the correct folder due to the permissions of the folder. Sandboxie is willing to help with the update and eventually starts SandboxieBITS.exe. When it does I see a little revolving circle cursor (ie. busy) for a few seconds. It retries this every once in awhile and I found that cursor change to be distracting and no way to disable it. If I recall, I got SBIE error if I renamed SandboxieBITS.exe.
@noway, when you run Chrome under Sandboxie and you get Sandboxie messages regarding SandboxieBITS.exe, your best bet to solve the messages or issues is to run Chrome in a sandbox without Drop rights and/or without using Start/Run/Internet restrictions. In some systems thats just the way it is. Bo
You're welcome. I agree 100%, super powerful and it's current name doesn't reflect that too well. Threads tab is blank on mine for Windows 10 as well.
