- Jun 8, 2016
- 171
completely optional. based on the security programs you use, it wouldn't be mandatory. some people like to use it for an extra layer of defense.
Do I still need a Sandboxing Utility ?
- Thread starter AMD1
- Start date
Please provide comments and solutions that are helpful to the author of this topic.
- Nov 19, 2014
- 2,344
It's like lastpass binary component. If you want it you need to install it in the same browser isolated environment. Issue starts if you use roboform in many different browsers and you also need roboform in them.
- Apr 1, 2017
- 1,760
@Sunshine-boy
My estimation is that #1 would be more secure (generally speaking) because Google use a lot of process mitigation policies with their sandbox container and all of those combined should in theory make it more difficult for an attacker to compromise the browser process for local native code execution on the host environment via RCE. When you add on features like Site Isolation, it gets even better because features like that will be beneficial against Spectre exploitation attacks taking place on the web (Spectre requires code execution within the target process, and since JavaScript is loaded by the browser process and given the features JavaScript supports, it can be done via JavaScript... however Site Isolation causes a new process per tab with the sandbox container enabled).
Even if you're using Sandboxie, let's say that Spectre exploitation was deployed through JavaScript, but you couldn't use the Site Isolation feature DESIGNED to help prevent such attacks because Sandboxie breaks the Chrome sandbox container. Despite running in the sandbox, there should still be data to be exposed by Spectre back to the attackers regarding the browser session for other tabs you currently have (or did have previously during the session) in the memory of the Chrome processes to be ex-filtrated. If Sandboxie doesn't break the Site Isolation feature, then you can ignore this part.
The reason I think #1 with the process policies is better than #2 is because it will be theoretically easier to compromise Google Chrome (e.g. web-based exploitation) without the sandbox container enabled, and as far as I know, it isn't compatible with Sandboxie which means you'd have to miss out on those Google Chrome additional security features.
If an attacker is capable of exploiting Google Chrome for native code execution on the host environment, they should in theory be skilled enough to bypass at-least some of the Sandboxie restrictions. Sandboxie injects a module into the "sandboxed" process and then patches the memory of a ridiculous amount of routines from the Win32 and Native API subsystems (e.g. KERNELBASE, NTDLL) however it also has a kernel-mode device driver for filtering process (handle creation and duplication as well as for threads), registry and file-system operations. There's a lot they will have to rely on user-mode hooks for though which they won't be able to filter from kernel-mode via callbacks... And I recon that generally speaking, someone clever enough to exploit Google Chrome for native code execution on the host environment will be familiar with API hooking techniques and how to surpass them.
I think a better alternate would be Comodo Sandbox, which utilises Intel VT-x/AMD SVM for virtualization with the hyper-visor. This type of isolation is hardware assisted via virtualization technology embedded into the CPU (e.g. Intel VT-x, AMD SVM). It's a lot more secure than kernel-mode callbacks, user-mode patching and user account isolation (which from my previous findings, Sandboxie seemed to rely on).
Personally, I'd go for #1 based on your given choices.
My estimation is that #1 would be more secure (generally speaking) because Google use a lot of process mitigation policies with their sandbox container and all of those combined should in theory make it more difficult for an attacker to compromise the browser process for local native code execution on the host environment via RCE. When you add on features like Site Isolation, it gets even better because features like that will be beneficial against Spectre exploitation attacks taking place on the web (Spectre requires code execution within the target process, and since JavaScript is loaded by the browser process and given the features JavaScript supports, it can be done via JavaScript... however Site Isolation causes a new process per tab with the sandbox container enabled).
Even if you're using Sandboxie, let's say that Spectre exploitation was deployed through JavaScript, but you couldn't use the Site Isolation feature DESIGNED to help prevent such attacks because Sandboxie breaks the Chrome sandbox container. Despite running in the sandbox, there should still be data to be exposed by Spectre back to the attackers regarding the browser session for other tabs you currently have (or did have previously during the session) in the memory of the Chrome processes to be ex-filtrated. If Sandboxie doesn't break the Site Isolation feature, then you can ignore this part.
The reason I think #1 with the process policies is better than #2 is because it will be theoretically easier to compromise Google Chrome (e.g. web-based exploitation) without the sandbox container enabled, and as far as I know, it isn't compatible with Sandboxie which means you'd have to miss out on those Google Chrome additional security features.
If an attacker is capable of exploiting Google Chrome for native code execution on the host environment, they should in theory be skilled enough to bypass at-least some of the Sandboxie restrictions. Sandboxie injects a module into the "sandboxed" process and then patches the memory of a ridiculous amount of routines from the Win32 and Native API subsystems (e.g. KERNELBASE, NTDLL) however it also has a kernel-mode device driver for filtering process (handle creation and duplication as well as for threads), registry and file-system operations. There's a lot they will have to rely on user-mode hooks for though which they won't be able to filter from kernel-mode via callbacks... And I recon that generally speaking, someone clever enough to exploit Google Chrome for native code execution on the host environment will be familiar with API hooking techniques and how to surpass them.
I think a better alternate would be Comodo Sandbox, which utilises Intel VT-x/AMD SVM for virtualization with the hyper-visor. This type of isolation is hardware assisted via virtualization technology embedded into the CPU (e.g. Intel VT-x, AMD SVM). It's a lot more secure than kernel-mode callbacks, user-mode patching and user account isolation (which from my previous findings, Sandboxie seemed to rely on).
Personally, I'd go for #1 based on your given choices.
- Apr 1, 2017
- 1,760
very well explained.Thanks for the advice.
You're more than welcome.
Never hold back from learning more. Truth is there is no 100% limit, you can keep learning more and more... As @BoraMurdar would put it, "knowledge is power".
I probably learnt a lot just by replying to you and I won't even know it yet.
Honesty and modesty by a young man with enough knowledge to run circles around most
Keep that up my friend, it does my heart a lot of good to see other generations transform into respectful men.
- Dec 12, 2013
- 541
@AMD1
"Do I still need a Sandboxing Utility ?"
Yes...I think always when it's wise and reasonable.
Look at this artickle on Bromium page
Isolate Downloads and Executables So Threats Can’t Escape
"Do I still need a Sandboxing Utility ?"
Yes...I think always when it's wise and reasonable.
Look at this artickle on Bromium page
Isolate Downloads and Executables So Threats Can’t Escape
- Oct 22, 2016
- 409
@Opcode WOW! Your explanations are always very useful and even if complex, you make them easy to understand for everyone. Thank you very much. There is a lot to learn from you!
- Jul 1, 2017
- 1,396
I wish I could sandbox Office but anything I try breaks something or makes things far less convenient.
- Jul 3, 2015
- 8,153
+1
A different way to keep Office apps out of trouble (if you really need MS Office for professional reasons or whatever) is with the Excubits apps, Memprotect and Pumpernickel. I use the demo version of both. It takes some time and practice, because you need to write your own rules, but once you do, it is good protection.
The protection will be more effective if you can concentrate the files you actively edit with Office apps into one or two folders, and store most of your docs somewhere else. This is so you can block write permissions to most of your docs, and only expose a small number of active docs to that particular risk.
An easy tweak that goes a long way is to block outbound firewall connection for Word and Excel. NVT SysHardener makes that tweak for you by default, in Windows Firewall. If you use a 3rd party firewall, you will have to tweak it yourself.
Similar threads
