Is it worth it to sandbox Firefox with ReHIPS?

  • Total voters
    31
D

Deleted member 65228

Firefox is a good and stable browser but in my opinion whether they are "secure" depends on what "secure" means for you. If you're referring to the potential for remote code execution from the web or the alike then yes they are secure as far as I am aware, however if you're referring to the potential of abuse from malicious software which is already installed on a machine (active infection - such as banking malware), then I am afraid to say that they are a weak-link in comparison to Microsoft Edge and Google Chrome. They are weak against password dumping as well AFAIK. Remember that such is only done with an active infection so strive to not end up in that situation in the first place is my advice.

I recently switched from Google Chrome to Firefox mostly because it has improved so much since I last used it, I like their focus on privacy as well. I usually switch between them now and again. Overall they are secure yes IMO.

The Firefox store for extensions appears to be a lot safer than some other browser vendors. With Google Chrome I could find so many fakes in under a short time period but this was not the case with Firefox. I actually found zero rogue extensions for Firefox in an increased time limit... They are much better with this for sure I think

Anyway unless you meant the latter, then I wouldn't sandbox it personally unless I had really bad habits but as @_CyberGhosT_ said, good practises and you'll be good to go. :)
 

shmu26

Level 84
Verified
Trusted
Content Creator
ReHIPS user and beta tester here.
I run Chrome without sandbox, but I enabled alerts for sub-processes. After whitelisting a few command lines and editing them appropriately with wildcards, I don't see prompts for standard browser actions. This is secure enough for me.
I would do the same if I used Firefox, but I am pretty much a Chrome user.
Browser exploits are so extremely rare nowadays, it is just not necessary to go nuts over protecting an already secure browser like Firefox Quantum.
 

shmu26

Level 84
Verified
Trusted
Content Creator
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.
 

steel9

Level 4
Verified
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.
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.
 
D

Deleted member 65228

For the record, Google Chrome already has a sandbox of its own (AppContainer implementation) and Microsoft Edge relies on the Microsoft implementation of AppContainer. This also means that Google Chrome will do things like attempt to force Data Execution Prevention and the such (it actually supports the use of undocumented APIs for this as well if you're on Windows 7) if it isn't already enabled as it should be by default.

Even if you get hit with the rare exploit no one ever see's nowadays for home users especially, the malicious code would be executing within a sandbox container. The code executing under the context of the browser process thanks to the exploitation will be severely limited in what it can do without deploying a second zero-day exploit for privilege escalation, which would be sincerely tricky considering it would have even less rights than a normal standard process due to the sandbox container control.

The browsers are all secure when browsing, and if you're already infected then... of course they can be tampered with. Except the aim is to not be infected in the first place, and security software can be tampered with after a successful infection too, so it isn't that big of a deal in my opinion.

Microsoft Edge, Google Chrome, Firefox, Opera, Vivaldi, Brave, Tor browser (based on Firefox)... they are all great and useful.
 

shmu26

Level 84
Verified
Trusted
Content Creator
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.
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.
 
D

Deleted member 65228

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.
 

shmu26

Level 84
Verified
Trusted
Content Creator
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.
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.
 

steel9

Level 4
Verified
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.
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
 

shmu26

Level 84
Verified
Trusted
Content Creator
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
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.

Truth is, you can "empty the sandbox" also with ReHIPS, but it takes two or three clicks to do it. You delete the isolated environment, and reinstall rules, and you are back to a fresh browser.
 
D

Deleted member 178

Don't mistaken browser's sandbox with full fledged sandboxes, they may have common things but the purposes are totally different and they work differently.

Browser's sandboxes don't sandboxes your downloads, don't prevent mails attachment to be executed, etc...
browser sandboxes just try to isolate malicious scripts or codes to infect the system via the browser in some degree.

So yes it is worth making your browser sandboxed with REHIPS or other sandboxes.
 

Local Host

Level 19
Verified
If it's worth it? It makes a difference if that's what you asking, the real question is do you need it?

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.
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.
 
D

Deleted member 65228

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.
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)

2. Windows likely has a higher market share than Linux and OS X and thus more focus on attacking it over the others. In the early days, people believed OS X was invincible to malware due to how rare it was for people to attack it compared to Windows at the time. Linux is used for Android by Google for a reason so that is all I will say on the matter... In my opinion Windows is not more secure than Linux or OS X in a normal environment but that neither means the others can be attacked
 

shmu26

Level 84
Verified
Trusted
Content Creator
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.
Yeah, I was a little vague, and I certainly did not mean to strengthen the misconception you mentioned.
This is the point I was trying to make: our modern browsers are theoretically vulnerable, as evidenced by the need to issue security patches for them. But in practice, they are quite secure.
The upshot is like this: there is a valid reason to sandbox a browser -- it protects you even from those zero-day exploits that are usually patched before they become an actual threat. But sandboxing the browser is an extra, not a necessity, IMHO.
 

DeepWeb

Level 25
Verified
But why? When was the last time you had malware on your computer? :)
Just keep Windows and Firefox up to date and run your OS with a standard user account. I think sandboxing a browser is a bit too much and might likely break components and user experience.
 

Glashouse

Level 4
Verified
If you use a Sandbox it is not going to raise your security level by default.
It depends on your habits.
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!
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...
 
D

Deleted member 178

If you use a Sandbox it is not going to raise your security level by default.
It depends on your habits. .
I disagree, a sandbox raise the level by default, users bad habits lowered it...

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!
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.
It is why i like ReHIPS, you can't recover the file directly.

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..
Again we have to differentiate things.
You can't compare a voluntary download (aka "cool my soft has an update, i download the new installer") with a Drive-By Download which is totally involuntary.
Against a D-By Download, an isolated browser is safer than an non-isolated one.

Sandboxes were made to isolate any apps and program because they can be a vector for an attack due to their potential and latent vulnerabilities.

As if you say seatbelts in a car doesn't raise the security of the passenger because the passengers may not use them...
Tools are made to be used in a certain way, if the users decide otherwise (either by ignorance or laziness), that is their fault, not the tool fault.