Tuesday, 27 March 2012

Windows 8 App Container Security Notes - Part 1

Windows 8 is coming and with it Metro and a revised application sand-boxing model. We plan to do a series of posts over the next few months summarising what we discover about AppContainer or App Container (Microsoft seem to flick between the two terms). This introductory post is really a summary of the information we've gleaned from the Internet and SDK into a single coherent resource.

Note: As this is all subject to change prior to release what is true today may not be accurate tomorrow. All of Microsoft's documentation is stamped '[This documentation is preliminary and is subject to change.]'. The same should be said for this post as well.

What is App Container?

"Windows 8 introduces a new security sandbox, called AppContainer, that offers more fine-grained security permissions and which blocks Write and Read Access to most of the system. There’s not a lot of documentation specifically about AppContainer because all Metro-style applications run in AppContainers, so most of the documentation is written from that point of view. For instance, here’s a page that describes the capabilities that a Metro-style application can declare that it needs: http://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx. Under the covers, it’s the AppContainer that helps ensure that an App does not have access to capabilities that it hasn’t declared and been granted by the user."

Distilling this down they've introduced a high-level capability model that translates to a more restricted version of low integrity processes. Going further than before in restricting IPC between processes, file access and event loopback network access.

Example Constraints with the new Capabilities

A Japanese blog in October last year documented the constraints from early Microsoft documentation. These are:

By default, an app can access only its AppData folder (including local, roaming, and temp sub-folders, all of which are deleted when a user uninstalls an app).

To directly access anything else through APIs, such as media libraries or documents, an app must declare that intent in its app manifest or a user must grant access by explicit action. Otherwise the APIs used to access the file system will fail.

Access to devices and sensors, especially webcams, microphones, and geolocation sensors, are also protected. Unless the app declares its intent, which is visible to users within the Store, the app will be denied access to those resources at runtime.

Integrity Levels and App Container

App Container is actually its own integrity level. This can be seen in the screen shot below:

"The other child processes of svchost are the RuntimeBroker which is in charge of accessing privileged data or devices on behalf of regular metro apps and wkspbroker which is the "Remote app and desktop connection runtime broker". To sum up, svchost and wkspbroker.exe are not metro apps but metro support infrastructure."

The Mozilla team also made this observation:

"Another difference is that named kernel objects of an AppContainer process are in a different namespace. For example, in this case the regular 'interactive user' session is session 3 so a regular named object 'Foo' from a traditional desktop application will be "\Sessions\3\BaseNamedObjects\Foo" which is what we see for IE10, while for metro apps it would be:

Identifying an App Container Compatible Binary

So there appear to be two key ways to identify an App Container compatible binary.

The first is through the DLL Characteristics in the PE header (note: Microsoft haven't issued updated PE COFF specifications to include this yet). This characteristic is set via the Microsoft linker using /APPCONTAINER:[NO] (Visual Studio 2011 and above).

How can we verify this? Well if we look inside C:\Program Files (x86)\Windows Kits\8.0\App Certification Kit\AppContainerCheck.dll we see.

The second way to identify App Container applications is through their manifest. The Visual Studio 2011 GUI provides a break down of the capabilities (more on these later) and allows them to be modified. What this translates too is something like:

SIDs and Tokens

Windows is a world of SIDs and Tokens. So it should come as no surprise that both have been used to support the App Container model.

New SID Constants

The second set are the Capability SID Constants. These define if the resulting SID will have the capabilities such as being an Internet Client, Server (or both), access to Pictures, Music, Documents, Shared Certificates or Removable Storage.

App Container Tokens

Microsoft Windows is where the token is king. Some tweaks have occurred to tokens in order to support App Containers.

Network Isolation

Windows 8 introduces the concept of network isolation (.docx). This brings with it a raft of new functions, we wont list them all but the interesting ones in our mind (for attack surface enumeration) are:

Windows Filtering Platform

"Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for creating network filtering applications. The WFP API allows developers to write code that interacts with the packet processing that takes place at several layers in the networking stack of the operating system."

App Container Profiles

These functions are exported by UserEnv.dll (not present in Windows 7). It should be noted that a quick hunt through IDA shows these are just stub functions for CreateAppContainerProfileWorker and DeleteAppContainerProfileWorker in ext-ms-win-profile-userenv-l1-1-0.dll.

Some other interesting enumeration functions, again for attack surface analysis, are (the names are pretty self explanatory):