# 腾讯反病毒实验室：深度解析AppContainer工作机制

Author: 乌云历史资料库 (@wooyun_archive)
Published: 2015-03-05T07:54:00Z
Canonical: https://wepostx.com/topics/734

> 乌云历史资料归档
>
> **原始作者：** 腾讯电脑管家
> **原始编号：** superkieran-wooyundrops:490
> **原始发布时间：** 2015-03-05 15:54
> **声明：内容仅用于技术研究和个人使用，版权归 wooyun.org。**

---

# 0x00 前言

Win8开始，Windows引入了新的进程隔离机制AppContainer，MetroAPP以及开启EPM的IE Tab进程都运行在AppContainer隔离环境，在最新的Win10Pre(9926)上，仍然如此。腾讯反病毒实验室对AppContainer的工作机制做一深入解读。

# 0x01 AppContainer带来的变化

Vista以前的系统，如XP，用安全描述符（简称SD，下同）里的DACL（discretionary access control list）来控制用户和用户组的访问权限。
Vista以后，增加了Integrity Mechanism，在SD的SACL(system access control list)里增加一个mandatory label的ACE，扩展了Windows安全体系。默认的控制策略是No-Write-Up，允许较低完整性级别的进程读访问较高完整性级别的对象；禁止较低完整性级别的进程写访问较高完整性级别的对象。
Win8引入了AppContainer隔离机制，提供了更细粒度的权限控制，能够阻止对未授权对象的读写访问。
以Win10PreX64(9926)开启EPM的IE Tab进程为例，看看有哪些变化。
从Process Explorer里可以看到，IE Tab进程的完整性级别不再是Low，而是变成了AppContainer：

![原文图片](/media/2016/06/cfeef861c46485849629ab45a243abe9)
 图1
在进程属性的Security标签可以看到，增加了标志为AppContainer以及Capability的SID：

![原文图片](/media/2016/06/1ef7f600fa02374007b5d91cf544c7d9)
 图2
一个AppContainer进程可以访问的对象，在SD的DACL里增加了额外的ACE。以IE Tab进程的进程对象为例：

![原文图片](/media/2016/06/7fe174a43a11033184a66d04658b9783)
 图3

# 0x02 如何使用AppContainer隔离机制

这里我们不讨论MetroAPP，主要看看DesktopAPP如何使用AppContainer隔离机制。
仍然以Win10PreX64(9926)开启EPM的IE Tab进程为例：在IE选项里开启EPM,下断点nt!NtCreateLowBoxToken，然后新建IE Tab，命中断点，截取最上面的几层调用栈：

![原文图片](/media/2016/06/19c485cc77580f0d173da1dd4b7199e7)
 图4
可见，通过CreateProcess这个API就可以创建出AppContainer进程。
看看CreateAppContainerProcessStrW的逻辑片段，把PackageSID String(图2里标记为AppContainer的SID)和CapabilitySID(图2里标记为Capability的SID) string转为SID后，传给了CreateAppContainerProcessW：

![原文图片](/media/2016/06/fdd07bc7115e816dad03b361ab3e1390)
 图5
看看CreateAppContainerProcessW的逻辑片段，把传入的CapabilitySIDs和PackageSID加入到ProcThreadAttributes，然后通过STARTUPINFOEX结构把ProcThreadAttributes传给了CreateProcessW。

![原文图片](/media/2016/06/6415f5ff3690b260e1a19c1bbd79e754)
 图6

![原文图片](/media/2016/06/ff0ccd150b44a5d28888cf815a498733)
 图7

![原文图片](/media/2016/06/9be31b039e8bf2b0c0c4d265bb5319f8)
 图8
搞清楚IE Tab进程的创建逻辑，我们就可以创建自己的AppContainer进程了。
直接复用IE的PackageSID和CapabilitySIDs来创建AppContainer进程。如果需要定义自己的PackageSID，可以参考MSDN上的CreateAppContainerProfile等API，这里就不讨论了。
成功的创建出了具有AppContainer隔离机制的记事本进程。32位和64位进程都可以。可以自由组合Capability，这里我选择了IE Tab 6个Capability里的3个。

![原文图片](/media/2016/06/bd4f3e720239466a3240a0b20680aa49)

![原文图片](/media/2016/06/e2b28c7290563cab8c07535b457f6935)

如果程序在设计时没有考虑使用AppContainer隔离机制，依赖没有授权给AppContainer的系统资源，比如系统根目录，用户根目录等，使用AppContainer隔离机制启动程序会失败。

# 0x03 AppContainer的访问权限控制

为描述方便，AppContainer进程的AccessToken我们简称为LowBoxToken（下同）。
下面是一个LowBoxToken的部分信息，可以看到TokenFlags的掩码位0x4000是置位的，这表示该Token是一个LowBoxToken。我们还可以看到PackageSid、Capabilities等信息（图2里标志为AppContainer和Capability的SID）。

![原文图片](/media/2016/06/5a69a0859d60b42797df7d9da0de3cf6)
 图11

# 0x04 DACL

DACL的遍历是在SepNormalAccessCheck/SepMaximumAccessCheck里进行的。这里我们以SepNormalAccessCheck为例，来看一看如何处理AppContianer相关的ACE。
一般来说，在遍历DACL时，如果满足以下3个条件中的任意一个，检查停止。
有一个access-denied ACE明确拒绝了请求访问权限中的任意一个；
有一个或者多个access-allowed ACEs明确给予了所有的请求访问权限；
已经检查完了所有的ACE，但是仍然至少有一个请求访问权限没有被明确给予，这种情况下，访问被拒绝。
从Windows Server 2003开始，DACL里ACE的顺序为：

```text
Explicit ACE:Access Denied Explicit ACE:Access Allowed Inherited ACE:Access Denied Inherited ACE:Access Allowed
```
这个遍历规则和顺序保证了明确拒绝优先于明确允许；明确指定的访问控制优先于继承的访问控制。
以下的内容基于Win10PreX86( 9926)。

# 0x05 ACCESS_ALLOWED_ACE_TYPE

在遍历类型为ACCESS_ALLOWED_ACE_TYPE的ACE时，如果ACE的SID前缀为SePackagePrefixSid(S-1-15-2)或者SeCapabilityPrefixSid(S-1-15-3)，则跳转到处理AppContainer访问权限控制的逻辑：

![原文图片](/media/2016/06/f671210e6d89f22562c319b444e223ac)
 图12
如果ACE的SID前缀为SePackagePrefixSid(S-1-15-2)，会先看这个SID是否为ALL APPLICATION PACKAGES，这是一个Well known SID

![原文图片](/media/2016/06/81566a6d11ca6d08c3a58fc43b793761)
 图13
如果是这个SID，认为匹配成功，不需要再精确比较SID了；否则和Token的PackageSID做精确匹配：

![原文图片](/media/2016/06/962602ea13fba9aba17d944104fe02ee)
 图14
如果ACE的SID前缀为SeCapabilityPrefixSid(S-1-15-3)，会尝试匹配Token的Capabilities：

![原文图片](/media/2016/06/5878b5392c6ec573d57da1f2c6e61589)
 图15
PackageSID或者Capabilities匹配成功后，会通过a13记录获取到的权限以及还剩下未获取到的权限。a13是上层调用传进来的结构指针，上一层函数会根据这个结构的值，判断AppContainer进程是否获取到了请求的访问权限。
看看上一层函数SepAccessCheck的逻辑片段，var_AccessLowbox就是图14/15里的a13。如果PackageSID或者CapabilitieSID给予的权限不能完全覆盖用户请求的权限（var_Remaining != 0），则访问失败：

![原文图片](/media/2016/06/d7df0f9407971431fe30f922b03bd749)
 图16
另外，对于No DACL的情况，也有额外的处理逻辑。AppContainer进程访问No DACL的对象时，是无法获得访问权限的：

![原文图片](/media/2016/06/853d41ff2961e8075e00307fd87dcdc9)
 图17
所以在Win8及以上系统中，我们如果想要创建一个所有进程（包括开启EPM的IE Tab ）都能访问的对象，对于该对象的SD，除了在SACL里指定为低完整性级别外，还要考虑在DACL中显示的给予everyone以及ALL APPLICATIONS PACKAGE对应的访问权限控制。

# 0x06 ACCESS_DENIED_ACE_TYPE

在遍历类型为ACCESS_DENIED_ACE_TYPE的ACE时，处理逻辑里并没有区分ACE的SID是否为PackageSID或者CapabilitiesSID。而是简单使用SepSidInTokenSidHash函数在Token的SidHash/RestrictedSidHash里匹配。如果是PackageSID或者CapabilitiesSID，匹配会失败，因此该ACE描述的拒绝访问权限控制不会生效：

![原文图片](/media/2016/06/421e8c50d93a58a59987842dc1df1c85)
 图18
做一个实验验证上面的结论，首先我们用AppContainer隔离机制启动一个记事本，复用IE EPM的PackageSID以及部分Capabilities：

![原文图片](/media/2016/06/6528a772961b24da33141eb77a82566b)
 图19
把C:\Users{当前用户}\AppData\Local\Packages\windows_ie_ac_001\AC\Temp\test\1.txt设置为下面的权限控制：

![原文图片](/media/2016/06/eeca8aaed954f4c7ee644d917fdd8705)
 图20

![原文图片](/media/2016/06/32ba8352e426b9c2f19f490e5f71387c)
 图21
ACE[0]Mask为0x001F01FF，包含要请求的权限0x00100080 虽然ACE[0]明确的拒绝了 S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394 (图19里标志为AppContainer的SID)，记事本仍然能成功打开1.txt(ACE[1](http://drops.wooyun.org/wp-content/uploads/2015/03/image001.png)明确给予了ALL APPLICATION PACKAGES 0x001F01FF的访问权限)。

# 0x07 结束语

AppContainer提供了更细粒度的隔离机制，不仅能用于MetroAPP和 IE EPM，当应用程序需要访问未知第三方内容时，也可以考虑使用AppContainer隔离机制，把对系统的潜在影响降到最低。

## Replies