Chrome sandboxed

Discussion in 'sandboxing & virtualization' started by Overkill, Jun 25, 2015.

  1. bjm_

    bjm_ Registered Member

    Joined:
    May 22, 2009
    Posts:
    4,453
    Location:
    .
  2. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,064
    Location:
    Canada
    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?
     
  3. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    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.
     
  4. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    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
     
  5. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Totally forgot about that update (I thought it was included in 5.16 final). Updating to beta will surely solve the problem.
     
  6. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,064
    Location:
    Canada
    After updating to beta v5.17.6, the problem is resolved :thumb: Thank you everyone for your help!
     
    Last edited: Apr 7, 2017
  7. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    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. :p
     
    Last edited: Apr 8, 2017
  8. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    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
     
  9. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    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.
     
  10. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    The driver makes sure all (system, other programs, registry, etc) changes stay in the sandbox.

    Bo
     
  11. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    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.
     
  12. guest

    guest Guest

    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.
     
  13. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    Two very solid points, indeed. :thumb:
     
  14. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    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.
     
  15. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    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...
     
  16. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    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
     
  17. Trooper

    Trooper Registered Member

    Joined:
    Jan 26, 2005
    Posts:
    5,507
    Very cool!
     
  18. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    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

     
  19. guest

    guest Guest

    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) :)
     
  20. Beyonder

    Beyonder Registered Member

    Joined:
    Aug 26, 2011
    Posts:
    545
    Does this mean Malwarebytes Anti-Exploit will stop working with Chrome in the next update?
     
  21. guest

    guest Guest

    Mitigations (Process Hacker - properties - chrome.exe)
    Chrome v61 (browser process):
    chrome_v61.png
    Chrome v62beta (browser process):
    chrome_v62beta_new_mitigation.png
    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:
    chrome_v62beta_nvidia_untrusted.png
    = 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)
     
  22. Mr.X

    Mr.X Registered Member

    Joined:
    Aug 10, 2013
    Posts:
    4,795
    Location:
    .
    Thanks mate.
     
  23. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    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.
     
  24. Trooper

    Trooper Registered Member

    Joined:
    Jan 26, 2005
    Posts:
    5,507
    Can't wait for this!
     
  25. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    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.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.