I'm running Sandboxie v5.16, 64 bit under Win7, and Chrome browser process is still running after I shut it down, when I run it sandboxed. un-sandboxed it shuts down as expected. Has anyone else experienced this problem?
I've had similar problems with 5.17.x version at some time but it got away now. Maybe you can try to run it unsandboxed, update all extensions and components (chrome://components), restart it few times unsandbox and see if it helps.
Hi wat0114, try Minimalist suggestions, afterward set chrome.exe as Leader program. Doing this is supposed to solve lingering issues like what you are experiencing with Chrome. Sometimes it works, sometimes it doesn't. The one time I did set up a lingering program as Leader, it did work for me getting rid of the lingering completely. But you are experiencing it with Chrome and Chrome does things that other programs don't do. So, I think updating the browser and extensions, running the browser unsandboxed afterward so the update gets applied is a good idea. Also make sure to delete the sandbox before running Chrome after the new update is applied. Not doing this can cause issues sometimes. If you are using the same sandbox to run Chrome and other programs, this might cause glitches, creating a separate dedicated sandbox for Chrome helps solving this problem when this is the cause. You should also upgrade to the latest Sandboxie beta, perhaps thats all you really need to do. One of the changes in Beta 5.17.1 fixed a Chrome 56 lingering child process issue. Read changes for 5.17.1 in the link below. There you can also get the installer for the latest beta. http://forums.sandboxie.com/phpBB3/viewtopic.php?f=60&t=23888#p125732 Bo
Totally forgot about that update (I thought it was included in 5.16 final). Updating to beta will surely solve the problem.
While Curt does make valid points for the advantages Sandboxie has, it is not to be construed as a definitive argument without considering the possible drawbacks. This has been discussed previously in the earlier pages of this thread. Preventing data exfiltration or sandboxing malware is NOT the job or target purpose of a browser sandbox. Therefore, while the statement is true, it is insulting to someone's intellect. Imagine an AV proponent implied that AVs are somehow better by stating Sandboxie doesn't detect malware when it's downright obvious that it is not within it's scope of protection. I'm pretty sure Sandboxie fans here would say such an argument is absurd. I hope we can at the very least agree on this one. If one wants to download and run executable files, Sandboxie can still be employed as a precaution against being infected by malware, without having to sandbox the browser itself. Having a kernel mode driver does not necessarily make it a better security model compared to user-mode hooking done by browser. The browser developers decided "not to reinvent the wheel and let the operating system apply it's security to the object it controls." On Windows 8 and above, Chrome uses AppContainer which is implemented at the kernel level. Why? A kernel mode driver "may have bugs which may allow the bypass of the sandbox restrictions". Not to forget, injecting dlls may "create new attack vectors which may cause malfunction or create backdoors to other processes or to the file system itself." Once again, this is not intended as bashing. It all depends on which view point one subscribe to. A "first-party" security proponent would feel better off with not messing around with the browser whereas a "third-party" security proponent would feel differently. P.S. I was one of those who insisted on people not to give up on Sandboxie when Invincea acquired Sandboxie. Just a reminder to Bo and Rasheed.
Not all drive-by malware require user interaction to infect. And Chrome, same as other browsers, is not immune to this type of malware. Until then, that alone makes it a good reason to sandbox Chrome with Sandboxie (or as you mean, mess around with the browser by running it under Sandboxies supervision). Just my opinion. Bo
I have already said it in a couple of other threads, but to me it doesn't matter who is sandboxing the browser, either the browser itself or some third party tool, but I love virtualization. So that is reason enough the use SBIE. Also, when malware is capable of bypassing the Chrome sandbox, then it still needs to bypass SBIE, I believe that's what the SBIE developers mean. The driver basically acts like a HIPS on top.
The funny thing is, in all of those hacking contests, you never see them trying to bypass browser sandbox + security tool running on top, it would probably cost too much time. On the other hand, in theory it might sometimes also make hacking more easy, because third party tools might introduce holes. But then we are talking about targeted attacks.
Everything made by humans are imperfect so potentially bypassable one day; what reduce the chances are the resource and time needed for the bypass which may not worth the attempt. That is the principle of armored doors in houses; they are not made to totally prevent the intrusion, they are made to delay it to give time to the police to arrive on site.
The thing is, most of the time attackers don't actually know what defense is running on the system. First they would need to get remote code execution and after that a kernel exploit to elevate privileges. The first would be prevented by AE, so this stays the most important. And even if you can get high privileges and bypass AE, you are still trapped in the sandbox. So I still don't think that running security tools on top of a browser like Chrome is a true security risk.
Yes, for me it's all about assessing which is more likely to happen. IMO, SBIE user base is too small to be attractive to attackers. Chrome user base OTOH...
Full AppContainer support coming for Chrome. No idea of an ETA right now though since we don't have the Google credentials to see the design documentation. At the moment, most Chrome child processes are already sandboxed with AppContainers. There is still traditional sandboxing for the rest. But it seems that Google security devs are going to go full AppContainer. This is great stuff. Link: https://bugs.chromium.org/p/chromium/issues/detail?id=760977
Another solid process mitigation coming to the Chrome sandbox in Chrome 62. I was just testing this one out with chrlauncher to verify and it is working appropriately. This blocks the injection of DLLs and therefore does not allow loading any modules that are not signed by Microsoft. This is enforced once chrome.exe is started and has loaded it's necessary Google signed modules, then after that only MS modules only. Pretty solid mitigation in all of my previous testing with this same mitigation on other binaries as well. [Windows Sandbox] Enable new process mitigations Link: https://bugs.chromium.org/p/chromium/issues/detail?id=750886
Good mitigation. So MBAE or HMP.A or other security applications which rely on injecting its DLL must make sure to inject it at process startup - "Any third-party modules must be loaded at process startup." Else it is too late and it is blocked (post-startup)
Mitigations (Process Hacker - properties - chrome.exe) Chrome v61 (browser process): Chrome v62beta (browser process): The new mitigation can be seen in the second screenshot The GPU-process of Chrome v62 has also this mitigation and untrusted dll's of Nvidia can be seen: = this "confirms" that it is a post-startup mitigation. As long as the dll is loaded at process startup, it can be injected. With this in mind, security applications should still be able to protect Google Chrome (if the security application is injecting its dll at process startup)
The next step in the Full AppContainer Chrome Support (https://bugs.chromium.org/p/chromium/issues/detail?id=760977) is adding AppContainer sandbox to the GPU process (https://bugs.chromium.org/p/chromium/issues/detail?id=807249) and Installer. I wish that we had access to the AppContainer Design Documentation for Chrome but unfortunately it is private during initial development stages. By the end of all stages, we will have a fully AppContainer-sandboxed Chrome for all chrome.exe processes. Chrome sandbox wizard James Forshaw has been adding this bit by bit.
James Forshaw has, as expected, AppContainer'd the GPU process. Bug Tracker comment: https://bugs.chromium.org/p/chromium/issues/detail?id=807249#c5 The new flag is: --enable-gpu-appcontainer * available on refs/heads/master@{#536690} and newer revisions Now I was hoping to add a fancy screenshot here showing the GPU process running in an AppContainer sandbox, however, I could not get it to work correctly. On master Chromium builds (revision 536690 and newer), the new Enable GPU AppContainer flag is shown as expected. But I cannot confirm via Process Hacker or Process Explorer that it is running in AppContainer yet for that process. So I am not sure yet what the problem is.
