Malwarebytes Anti-Exploit

It does protect your apps if you reset MBAE to its default settings.

 

No MBAE.dll present in AppContainer processes of Chrome



Still no word from MalwareBytes: @ZeroVulnLabs so repeat the question: Does NOT injecting MBAE.dll in AppContainer process of Chrome automatically imply that those Chrome processes are NOT protected?

 

Edge is protected (Appcontainer).

 

Thanks, Chrome's AppContainer not, while Chrome's Medium and Low Integrity Level processes are injected with MBAE.dll, strange? I have asked question at Malware Bytes forum.

 

I started ProcessExplorer (because ProcessHacker isn't displaying AppContainer)
and I can confirm, that no mbae.dll can be seen in AppContainer processes (Google Chrome)
(MBAE version 1.8.1.1195 / Chrome x64 50.0.2661.87)

 

Reader (appcontainer) for my PDF offline.
MBAE64.dll is present in appcontainer process.

Maybe it's a Chrome problem?

 

But why can another security app on my system successfully inject into these AppContainer Processes, and not MBAE.
It's maybe a Chrome problem, or maybe MBAE. I don't know.

 

I would like to try to think of this in a more positive light, maybe this is a good thing for Chrome defences in particular. Although this AppContainer process injection situation recently has got my curiosity with regard to EMET and MBAE. I wish that we had more definite answers at the moment from developers.

 

If we assume that MBAE does not protect Appcontainer Processes, also PPAPI Flash is Appcontainer.
Maybe it is better to restore "Untrusted Level"?

 

@mood, @Sampei Nihira, @WildByDesign I have found some text in project zero blog.

The Chrome developers complain about a Windows 8.1 kernel backward compatibility leak which allows to brake out of the JOB OBJECT limitation (to start other processes).

Scroll down to the text "Exploiting the issue in a Chrome renderer"

So it seems that WildbyDesign's assumption is correct: the text explains that it is very hard to inject DLL into a Chrome renderer process. One of the benefits of AppContainer is that it also removes read access capability of sandboxed processes, as explained in the blog "Demistifying AppContainer" So unless the AppContainer has not got an explicitly assigned capability to access a folder, AppContainer probably also blocks injected DLL's to be read (opened)!

 

In a test with EMET 5.5, Appcontainer Chrome has injected.
if I remember correctly.

It must also check HPA3.

 

Not on my PC (EMET 5.5 Windows 10 32 bits latest Chrome 50)

 

Kees is correct, EMET is only injecting into the 3 chrome.exe processes which are not protected by AppContainer. I can confirm the same behaviour on my 64-bit Windows 10 system as well. So it seems the same, whether it be 32-bit or 64-bit. Although I should note that, while EMET is reporting those AppContainer processes as not protected, I can see with Process Hacker that the EMET SHIM (EMET64.dll) file is injected into those AppContainer processes. But what I don't know is if they are actually protected correctly or if it is simply just EMET not receiving the communication back from the DLL, as in, possibly the AppContainer containment is blocking that communication back to EMET in order to confirm that the process is protected. So there are still some questions that remain, of course. I don't want to take anything away from the MBAE thread here, so anything specific to EMET we can certainly take over to the EMET thread. Although if the questions pertain to EMET, MBAE, and HMPA, then I suppose we definitely need to hear more from the developers since they will understand the inner workings of their software the best.

I suppose the question that I have at the moment is, do we even need EMET/MBAE/HMPA to inject into the AppContainer processes? Are the AppContainer contained processes secure enough that they don't need the added protection? These are some of my lingering questions.

 

I wonder what happens with HPA3?
Anyone can help?
TH.

 

Sorry can't help you out, I tried HPMA 3 beta once and it caused problems, that is why I only used EMET and MBAE.

 

Me too.

Anyone can help?

 

Using process explorer, I noticed hmpalert.dll in every chrome process including those with AppContainer integrity

 

If other security-apps are able to inject their dll, then it could be a problem of MBAE.

 

Maybe it is better to restore "Untrusted Level".

 

Your software certainly performs better.
The best compliments.

 

Depends on how you define better, MBAE has 121 pages on this forum, HPMA has over 380 pages just for reference.

HPMA : 9 fixes in April!
26-4-2016 3.1.9 build 367
Fixed ROP false positive in Microsoft Office.

20-4-2016 3.1.9 build 366
Fixed ROP false positive in Microsoft Office.

18-4-2016 3.1.9 build 365
Fixed ROP false positive in Microsoft Office.

8-4-2016 3.1.9 build 364
Fixed an issue with Application Lockdown mitigation on browsers.

6-4-2016 3.1.9 build 363
Fixed an issue related to trial activation.

4-4-2016 3.1.9 build 362
Fixed compatibility with VirtualBox hardening.
Fixed compatibility with Microsoft Edge 31.14279 (Redstone).
Fixed compatibility with Microsoft OneNote' e-mail function.

 

Alert thread started in May 2012. MBAE thread started in October 2013. Also the Wilders forum is the only thread for HMPA support. Go take a look at MBAE forum at Malwarebytes if you want to compare number of posts

 

right!
Just ignore him...

 

https://forums.malwarebytes.org/topic/182239-enabling-appcontainer-in-chrome/