Advice Request Windows AppContainer Isolation - what it does?

Please provide comments and solutions that are helpful to the author of this topic.

F

ForgottenSeer 72227

It basically isolates those programs from the OS to help prevent the OS from being compromised from un-patched vulnerabilities. I believe Edge does/can make use of it as well. Chrome AFAIK takes advantage of it and the new sandbox for WD is based off it as well, so I think it's not solely tied to store apps. AFAIK it's not configurable, but someone with more knowledge can confirm or deny this. I believe that MS is the only one that can make changes to how it functions/works. I think it's up to the developer of a program to take advantage of it. Users cannot add any program to it manually AFAIK.
 

oldschool

Level 81
Verified
Top Poster
Well-known
Mar 29, 2018
7,044
I believe you are correct @Raiden. Yes, Edge also has its own container, and this is the main reason it is secure. Aside from the lack of user market share, which = it is probably not as big a target. Both good reasons to use it, if you can stand the privacy issues and the lack of extensions - still, after all this time. Especially well suited for PDF viewing, security -wise. I for one like it, and use it to compartmentalize my browser habits. I hope they retain the basic look and feel when they move to Blink engine.
 

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
It basically isolates those programs from the OS to help prevent the OS from being compromised from un-patched vulnerabilities. I believe Edge does/can make use of it as well. Chrome AFAIK takes advantage of it and the new sandbox for WD is based off it as well, so I think it's not solely tied to store apps. AFAIK it's not configurable, but someone with more knowledge can confirm or deny this. I believe that MS is the only one that can make changes to how it functions/works. I think it's up to the developer of a program to take advantage of it. Users cannot add any program to it manually AFAIK.

My understanding is the same, at dev time sandbox parameters can be determined, I haven’t seen anything that indicates the existence of runtime configuration but maybe it exists and but it’s hard to find documentation for it ?).

What is the isolation though, does it mean that the sandboxed program is protected from injections ? Does it protect other processes from the sandboxed program ?

I think it’s not about 0day Protection but about mitigation, the exploited program will be more contained (that’s the case eg for Docker containerisation in Linux )

Eg in Linux each sandbox sees its own kernel namespace, it’s cant even see processes/threads on the host OS exist and for filesystem it can only see what has to explicitly be mounted at load time. I don’t have the same level of understanding with respect to what AppContainer does.
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
AppContainer sandbox is based on isolation, but not on virtualization. It is intended to isolate the applications via: Credential Isolation, Device Isolation, File Isolation, Network Isolation, Process Isolation, Window Isolation:
AppContainer Isolation - Windows applications
WindowsInternals – Pavel's Blog
The standard desktop applications cannot run in AppContainer, but can be adapted to do it.

Application in AppContainer can create child AppContainers to run processes with different capabilities.
https://i.blackhat.com/eu-18/Thu-De...wser-Security-From-People-Who-Owned-It-wp.pdf
Capabilities define what is allowed to do by the application, outside of AppContainer sandbox. If the application requires to do something with higher (than Low) privileges, then it has to run a Broker.

AppContainer capabilities can be configured partially by external tools like:
M2Team/Privexec
There is a thread about it:
Privexec - Run the program with the specified permission level
 
Last edited:

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
AppContainer sandbox is based on isolation, but not on virtualization. It is intended to isolate the applications via: Credential Isolation, Device Isolation, File Isolation, Network Isolation, Process Isolation, Window Isolation:
AppContainer Isolation - Windows applications
WindowsInternals – Pavel's Blog
The standard desktop applications cannot run in AppContainer, but can be adapted to do it.

Application in AppContainer can create child AppContainers to run processes with different capabilities.
https://i.blackhat.com/eu-18/Thu-De...wser-Security-From-People-Who-Owned-It-wp.pdf
Capabilities define what is allowed to do by the application, outside of AppContainer sandbox. If the application requires to do something with higher (than Low) privileges, then it has to run a Broker.

AppContainer capabilities can be configured partially by external tools like:
M2Team/Privexec
There is a thread about it:
Privexec - Run the program with the specified permission level

Thanks Andy - just to clarify that other containerisation technologies eg Docker does not require virtualization either when the host and guest OS are the same, eg you don’t need virtualization to run a Linux guest from a Linux host. But of course if host is Windows and the Guest Linux, then there’s no other way but to use virtualization.

If host OS is the same as guest OS, just kernel namespaces are used
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
Thanks Andy - just to clarify that other containerisation technologies eg Docker does not require virtualization either when the host and guest OS are the same, eg you don’t need virtualization to run a Linux guest from a Linux host. But of course if host is Windows and the Guest Linux, then there’s no other way but to use virtualization.

If host OS is the same as guest OS, just kernel namespaces are used
Other sandbox solutions (Sandboxie, Comodo Sandbox, etc.) use isolation + virtualization for the extended protection. If the application is running in AppContainer then some changes are done in the real system (saving files, Registry modifications), they are not virtualized. The lack of virtualization makes also the AppContainer more vulnerable to malware attacks.

In some way the AppContainer is not a "true" sandbox, such as the Windows sandbox which will be introduced in the forthcoming Windows compilation. This new sandbox will adopt isolation + virtualization, when using the host system resources (no need to install the second OS).
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
does AppContainer then block both injections to the AppContainer’d process and injections coming from the process due to credentials isolation and process isolation ?
Mostly the second kind. You have to use Exploit Protection to protect Applications in AppContainer against the injections from outside..
 

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
Mostly the second kind. You have to use Exploit Protection to protect Applications in AppContainer against the injections from outside..

In general yes but Eg for DLL injections in specific, I’m not sure how it works in Windows but I’d expect a process that runs with credentials no other process has, to block dll injections (other than load time dll injections) from processes with the same privileges due to credentials - is this not the case ?
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
In general yes but Eg for DLL injections in specific, I’m not sure how it works in Windows but I’d expect a process that runs with credentials no other process has, to block dll injections (other than load time dll injections) from processes with the same privileges due to credentials - is this not the case ?
Sorry my friend, I completely do not understand your post.:(
I am afraid that AppContainer has little or nothing to do with credentials. For simplicity, let's do everything on default Admin account. The processes with Low, Medium and High integrity levels can run on the same account. AppContainer uses Low integrity level + some additional read/write restrictions.
 
Last edited:

Windows_Security

Level 24
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Mar 13, 2016
1,298
Higher level Integrity rights objects can manipulate lower integrity level objects. Objects of same level also have access to each others resources,, so only with MemProtect like programs it would be possible to protect AppContainer programs against DLL-injection (because AppCointainer is the lowest Integrity Level).

My Guess is that this is the reason Microsoft uses a RunTimeBroker for Edge. This RunTimeBroker might protect Edge (in future?) against its environment against some attack vectors.
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
Higher level Integrity rights objects can manipulate lower integrity level objects. Objects of same level also have access to each others resources,, so only with MemProtect like programs it would be possible to protect AppContainer programs against DLL-injection (because AppCointainer is the lowest Integrity Level).

My Guess is that this is the reason Microsoft uses a RunTimeBroker for Edge. This RunTimeBroker might protect Edge (in future?) against its environment against some attack vectors.
RunTime Broker is generally used by most Applications in AppContainer to perform the operations which require the privileges higher than AppContainer (reading and writing user files, accessing the clipboard, accessing services, etc.). RunTime Broker in Edge runs with medium integrity level, so it cannot be used to protect Edge. It can, for example, create child AppContainers in Edge. The Brokers can be exploited for privilege escalation.
Microsoft Edge uses Module Code Integrity enforcement via the kernel (CIG). That prevents injection of DLLs, except Microsoft-signed, or WHQL-signed.
 
Last edited:

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
Sorry my friend, I completely do not understand your post.:(
I am afraid that AppContainer has little or nothing to do with credentials. For simplicity, let's do everything on default Admin account. The processes with Low, Medium and High integrity levels can run on the same account. AppContainer uses Low integrity level + some additional read/write restrictions.

What I want to say is that for dll injections in specific, if the AppContainer runs under different credentials a standard user account should not be able to inject as I) the SUA is not the owner of the process II) it’s not a privileged account - is this not the case and injections to the process can only be protected using Exploit Guard ?
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
What I want to say is that for dll injections in specific, if the AppContainer runs under different credentials a standard user account should not be able to inject as I) the SUA is not the owner of the process II) it’s not a privileged account - is this not the case and injections to the process can only be protected using Exploit Guard ?
If you start the application in AppContainer from SUA with user name 'NOTABOT' then the application runs on this SUA. Every standard user process running on this account (user 'NOTABOT') can inject DLL to this application. See for example:
Francesco149/uwpinject
 

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
If you start the application in AppContainer from SUA with user name 'NOTABOT' then the application runs on this SUA. Every standard user process running on this account (user 'NOTABOT') can inject DLL to this application. See for example:
Francesco149/uwpinject

Then agreed, nothing in AppContainer can prevent dll injection to the App then - I thought AppContainer run apps under different credentials ( with same privilege level but different nonetheless)

Exploit Guard it is then
 
F

ForgottenSeer 89360

From what @Andy Ful is explaining about the not-true sandbox, this looks same like McAfee dynamic application containment - the process of putting an executable in a clone of your OS and hardware is called virtualisation. The process of executing in real environment, but with “borders around it” is called containment.
You have certain pre-defined limitations (at least in McAfee DAC) but there are ways around them.
Additional technologies are needed to make sure that contained apps are completely disarmed, and not just slightly limited.

This is not be mistaken neither with a true sandbox, nor with cloud containers, where you have real hardware with several virtual boxes and every virtual box runs several containers.

Hope that makes it a bit easier to understand.
 
Last edited by a moderator:

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top