Raiden

Level 9
Content Creator
Verified
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 23
Verified
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 8
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

Level 38
Content Creator
Trusted
Verified
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-Dec-6/eu-18-Ding-Cutting-Edge-Microsoft-Browser-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 8
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-Dec-6/eu-18-Ding-Cutting-Edge-Microsoft-Browser-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

Level 38
Content Creator
Trusted
Verified
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:

notabot

Level 8
does AppContainer then block both injections to the AppContainer’d process and injections coming from the process due to credentials isolation and process isolation ?
 

Andy Ful

Level 38
Content Creator
Trusted
Verified
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 8
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

Level 38
Content Creator
Trusted
Verified
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 21
Content Creator
Trusted
Verified
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

Level 38
Content Creator
Trusted
Verified
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 8
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

Level 38
Content Creator
Trusted
Verified
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 8
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
 

Similar Threads

Similar Threads