Windows build-in Sandbox

I am definitely the farthest thing from an expert, but wanted to comment on this part. You are right in that the Chrome security team seems to implement these. The Chrome security team seem to follow closely with new mitigations that Microsoft adds to their latest operating systems and I think that is incredibly important for Chrome to take advantage of what is available within the OS. From a security perspective, I believe that this is the reason why Chrome stands out in comparison to other browsers. They've got some top notch developers and the Chromium design principals and security guidelines are clear and concise.

One thing to note is that some of these newer mitigations can also be added to other processes now with EMET 5.5 as well. Particularly, blocking the loading of remote fonts can be quite important for Firefox and such which might not include those mitigations.

Although this thread has not picked up too much steam, I just wanted to thank you for sharing all of these different bits of information within this thread because in my mind it holds much value and is very interesting to follow.

 

Thanks, it also serves as a thread to find information back.

 

Ditto.

@Windows_Security
Thank you so much for your knowledge and good will to share it.

 

FWIW, this feature is also available for Firefox if you use uBlock Origin while Chrome's webRequest API doesn't support that feature. I guess that switch mentioned above doesn't work on a per-site basis.

 

@summerheat Thx, for Firefox users it is best to use Sandboxie and a scriptblocker (like Noscript or uBlock), but as the title says, this is the thread for Windows Build-in sandbox (e.g. using AppContainer in Edge and Chrome).

 

I know, I was only referring to this specific feature.

 

NoScript can also block web fonts (Options -> Embeddings -> Forbid @font-face).

 

I had no idea the Chrome Devs were working on that site isolation, looks awesome.

 

Yes, but uB0 does it on a per-site basis, hence it's more flexible.

 

In NoScript, you can block FONTS globally and at the same time, have the option to allow them temporarily in a particular site.




Read the last paragraph under "Beyond Javascript:.......content". It tells how to set it up to permanently allow FONTS from any site.
https://noscript.net/features#contentblocking

Blocking FONTS is done by default by NoScript, I never had any reason or need to allow FONTS from any site. The setting works fine as it comes by default but NoScript gives you the options to do with FONTS whats best for you.

Bo

 

Thanks, I had forgotten about that.

 

Guys, please stop polluting this thread with Noscript and Sandboxie stuff which is only necessary because Firefox does not has a sandbox.

 

May I ask which process did you mark as "protected process"? Was it the Exploit Test Tool (ETT) itself, or did you test it on another process?

 

@Rasheed187
Chrome is not allowed manipulate other processes. So Chrome can be exploited, but it can't break out. As the picture shows calc.exe can be started

 

I'm sorry but this is confusing. The goal of this test, is to see if security tools can block the execution of calc.exe, nothing more and nothing less. So you should either prevent the Exploit Test Tool or Chrome from launching other apps, and then you should pass the test.

There is no need to protect Chrome from manipulation, or to prevent Chrome from manipulating other processes. Simply block process execution with either Bouncer or MemProtect and you will pass the test. You seem to be way too fascinated or caught up with this "protected process" feature, while it's not needed to pass this test, that's my whole point.

 

Let me explain why I am fascinated about protected processes feature of Windows and the ability of Memprotect to use it.

C(++) does provide memory integrity. So I can declare a table with say 10 rows and when I want to move something to the 11th row no memory overflow exception will occur. No exploit protection program can prevent a hacker misusing a bug like the over simplified table example.

The core of the problem is that C(++) compilers don't enforce boundery protection to memory operations. It is for compilers to solve this problem within the language and for the OS to solve this on process level. By denying certain memory capabilities/operations to protected processes Memprotect allows to sandbox/contain processes from each other.

Hope this helps

 

Nice read on Windows 10 new Sandbox feature http://www.howtogeek.com/250041/how-to-convert-a-windows-desktop-app-to-a-universal-windows-app/ Microsoft tool monitors file/process/registry access and creates a tailored made sandbox when converting Desktop programs to Tiles/Store Apps.

 

I currently have google chrome on my linux system and from what i understand it is more secure than the windows version.

 

Thanks for this. This is really quite exciting and more interesting than most users might assume. I'm going to play around with this right now.

 

Yes, it's a cool feature I agree. But the thing that I'm trying to explain is that when it comes to blocking the end-goal of exploits which is to run malware, you don't need a tool like MemProtect. Bouncer or any other anti-exe like ERP and VS, should already do the job. If malware can't run, it can also not perform stuff like reading and writing to memory of other processes.

So that's why I never understood why you used the ETT in order to proof that it can block exploits via the "protected process" feature. Normally speaking, if you make Chrome (or other browser) a protected process, the ETT won't be able to simulate the exploit, so of course it will fail. If you make the ETT a protected process, then calc.exe should be able to run. Perhaps you can test this one more time.

 

You seem to forget that your browser runs scripts, your pdf reader runs scripts, office documents can contain macro's even an image has code running in its metadata (link) and images can be used to run code (link), so when your anti executable has whitelisted those rich content applications the embedded scripted code will run.

Also you focus only on malware which runs from disk, google on fileless malware (link). On top of that malware can use the credentials of whitelisted processes through process hollowing for example (link).

I won't for two reasons

1. You seem to think that anti-exploit programs stop the cause of the exploit, which is impossible because some programming languages do not enforces memory boundery protection (see post 41 in this thread). So first proof to me that any anti-exploit program, blocks memory exceptions, at (or after) the instruction in which the boundery violation occurs (that is why Microsoft calls it exploit mitigation and not exploit prevention or protection, example of detection evasion)
   
   
2. We started this discussion because I wondered how you knew that MemProtect did not protect at all against exploits without having used or tested this program. So I would suggest you test it yourself.

 

I'm not following you. Are you talking about the use of wscript.exe and powershell.exe by exploits? Most anti-executables blacklist these type of processes. But what has this got to do with the way exploits work? You're over-complicating things. Anti-exe tools simply block the payload/malware from running, it doesn't matter if the exploited tool has the ability to run scripts.

No, you seem to think that MemProtect works the same as HMPA, that's my issue. HMPA and MBAE both try to stop shellcode from running, they block the exploit in stage 1 instead of stage 2, these means they can stop in-memory exploits which you seem to be so worried about.

Again, the "protected process" feature is NOT meant to block exploits, or better said the goal of exploits, which is to run malware. Because MemProtect passes the ETT, you automatically assume that I'm wrong.

MemProtect probably either blocks the execution of calc.exe, or blocks access to the memory of calc.exe. But it DOES not mitigate memory corruption techniques like specialized anti-exploit. So please stop saying that MemProtect is better in stopping exploits.

 

In case people still don't get it, I'm talking about this stuff, HMPA is using similar techniques in order to block exploit-attacks as soon as possible. The "protected process" feature will not do anything to mitigate the exploitation techniques, so that's why I'm baffled by certain comments made by Windows_Security, about "MemProtect being a good alternative to HMPA".

https://www.paloaltonetworks.com/do...admin-guide/traps-overview/exploit-prevention
https://www.paloaltonetworks.com/do...e/exploit-prevention/exploit-prevention-rules

 

It is a post-exploitation infection chain breaker. Whether you need earlier stage protection is up for debate. It is a theoretical what is possible / what is probable debate. However, once properly set up, MemProtect will cause A LOT LESS issues than HMP.Alert.

 

The point of this thread is not to compare Memprotect with any other anti-exploit tools or anti-executable. The point of this thread is to show how one can utilize native security features (sometimes through the use of programs that utilize these features) to harden one's security setup against exploitation.