- Jun 23, 2017
- 183
Is it worth it to sandbox Firefox with ReHIPS (or another sandbox), or does Firefox have good enough security? Would sandboxing Firefox with 3rd party software actually provide any benefit regarding security?
True, but Firefox Quantum doesn't work properly in Sandboxie, I think you had to lower the security settings of Firefox to be able to run it in Sandboxie which I do not want to do.If you disable cloud syncing of settings in your browser, and you use Sandboxie, you won't have to worry about all that adware and popups and browser redirects and other junk that so often mucks up the browser when you aren't being careful. You just empty sandbox, and you're good.
But if you sync your settings, it might come back to haunt you.
Thanks. Didn't know that. But did you check what's cooking on the Sandboxie forum? Maybe they have a fix, or a workaround, or they are issuing a beta that solves the problem. That's life with Sandboxie. Things break, and they fix it.True, but Firefox Quantum doesn't work properly in Sandboxie, I think you had to lower the security settings of Firefox to be able to run it in Sandboxie which I do not want to do.
And after all these protections, Chrome and Edge and others are regularly issuing patches for vulnerabilities that are regularly being discovered. Fortunately for us users, these vulnerabilities seem to get patched before they are exploited in the wild.I've just checked the mitigations enforced for Microsoft Edge.
1. Data Execution Prevention (DEP) (Permanent)
2. Address Space Layout Randomisation (ASLR) (High Entropy & Force Relocation)
3. Dynamic Code Prohibition (DCP)
4. Strict Handle Checks (SHC)
5. Control Flow Guard (CFG)
6. Signatures restricted (regarding modules which can be loaded)
I made up a few of the short-names because 'Strict handle checks' isn't really the title to be referred to as SHC but I find it easier and like to refer to it this way so hopefully no one minds. The above are all policies which have been officially supported by Microsoft since Windows 8, however Windows 10's new Exploit Protection settings allow you to configure various policies to be enforced on target software (with the exception that some such as Control Flow Guard will not work correctly unless the Portable Executable was compiled to support it - which makes perfect sense and there isn't really a way around this due to how it all works).
The Dynamic Code Prohibition (DCP) policy is there to prevent the PAGE_EXECUTE_READWRITE access protection for newly allocated memory (handled dynamically), it'd return the NTSTATUS error code STATUS_DYNAMIC_CODE_BLOCKED.
All in all, these mitigations help prevent successful attacks even in the case of a malware infection targeting the browser software which is active in-memory. The signature restriction policy which is enforced would force an attacker to rely on reflective DLL loading (aka. manual mapping) which is a lot trickier to do than standard DLL injection methods - lowering the attack vectors and also limiting who can attack the software.
Firefox uses the following mitigations.
1. Data Execution Prevention (DEP) (Permanent)
2. Address Space Layout Randomisation (ASLR) (High Entropy)
3. Strict Handle Checks (SHC)
4. Extension Points Disabled (EPD - another made up synonym by me)
Not as much as Microsoft Edge but those mitigations are still beneficial. The browser is still secure regardless and personally I'd use Firefox over Microsoft Edge due to it being more convenient for me.
Chrome uses the following mitigations.
1. Data Execution Prevention (DEP) (Permanent)
2. Address Space Layout Randomisation (ASLR) (High Entropy)
3. Strict Handle Checks (SHC)
4. Win32k System Calls Disabled
4. Extension Points Disabled (EPD)
5. Control Flow Guard (CFG)
6. Signatures restricted (regarding modules which can be loaded)
7. Non-System Fonts Disabled
8. Images restriction (Remote & Mandatory)
For anyone wondering, Win32k system calls being disabled prevents exploitation attempts using APIs exported by a module called WIN32U.DLL. As a memory refresher, there's a code injection technique which works by abusing Extra Window Memory (EWM) to force shell-code execution (ROP chain exploitation -> also abused by PowerLoader from Carberp banking malware) and this is achieved in the end via NtUserSetWindowLong (WIN32U) which is internally called by SetWindowLong (USER32). Another example would be a new vulnerability which was posted online around 2 weeks ago which can force BSOD the system without administrator rights (therefore without SeShutdownPrivilege for NtRaiseHardError -> Petya, NotPetya both use this) via NtUserDefSetText by lying about the ASCII/UNICODE encoding flag and passing a buffer of the opposite claimed for it to have been.
Google Chrome relies on the #6 policy mitigation to prevent code injection into its processes. While this is effective at common techniques, you don't actually need to rely on reflective DLL loading to bypass it. Google don't verify the loaded modules at run-time, they enforce the policy at run-time instead and assume there are no rogue modules loaded prior to enabling it.
The more mitigation policies doesn't necessarily mean higher protection, either of the browsers are perfectly fine in my opinion. Other browsers like Opera and Brave are also exceptionally good and I like them a lot.
You can sandbox the browser with software like ReHIPS or Sandboxie or use it as-is, as long as it works for you then shouldn't be an issue.
The solution on the forums seemed to be to lower the Firefox sandbox level, which I do not want to do as it reduces the security if I understand it correctlyThanks. Didn't know that. But did you check what's cooking on the Sandboxie forum? Maybe they have a fix, or a workaround, or they are issuing a beta that solves the problem. That's life with Sandboxie. Things break, and they fix it.
Thanks for the info. I am sure they are working hard on a fix -- Sandboxie users tend to be Firefox users, and I am sure no one is very happy about lowering the security.The solution on the forums seemed to be to lower the Firefox sandbox level, which I do not want to do as it reduces the security if I understand it correctly
Common misconception to believe a Software is not secure due to having security patches regularity, the fact it's constantly attacked and brings to light exploits, only makes it more secure with each and every security patch. Windows is far more secure than Linux and OSX, but people believe otherwise due to that mindset.And after all these protections, Chrome and Edge and others are regularly issuing patches for vulnerabilities that are regularly being discovered. Fortunately for us users, these vulnerabilities seem to get patched before they are exploited in the wild.
1. I don't think I've seen a common misconception surrounding 'software is not secure due to having security patches' -> more the opposite although the opposite is the opposite of a misconception in my opinion and for good reason (security patch -> solves a vulnerability -> it could introduce a new one but that isn't always the case)Common misconception to believe a Software is not secure due to having security patches regularity, the fact it's constantly attacked and brings to light exploits, only makes it more secure with each and every security patch. Windows is far more secure than Linux and OSX, but people believe otherwise due to that mindset.
Yeah, I was a little vague, and I certainly did not mean to strengthen the misconception you mentioned.If it's worth it? It makes a difference if that's what you asking, the real question is do you need it?
Common misconception to believe a Software is not secure due to having security patches regularity, the fact it's constantly attacked and brings to light exploits, only makes it more secure with each and every security patch. Windows is far more secure than Linux and OSX, but people believe otherwise due to that mindset.
I disagree, a sandbox raise the level by default, users bad habits lowered it...If you use a Sandbox it is not going to raise your security level by default.
It depends on your habits. .
That is not how Sandboxie is supposed to be used. You shouldn't recover any files unless you are sure it is clean. This convenience feature defeats the whole purpose of Sandboxie imo.Example: If you download a file in a sandboxed browser (most of the time you download something for a purpose, so you will run / view the file after the download is done), use the quick recovery feature (in Sandboxie) and run the file --> you are not protected!
Again we have to differentiate things.It is always a question of the use case. What are you trying to protect and might this protection become obsolete because of your habits..