geelaw
2025 年 12 月 4 日
Windows 的安全模型里，可执行程序没有身份，最细的权限粒度基本上就是“用户”（会话、窗口站点、桌面基本上和用户这一套是正交的），如果用户 A （人）用用户 B （ Windows 权限控制模型的对象）的身份运行程序 C ，那么 C 可以访问所有用户 B 的信息。
可执行程序没有身份，所以不存在加密方式，使仅某个可执行程序可以解密。所谓 app-bound encryption 只是让恶意软件需要绕路（实际上解密的进程是以用户 SYSTEM 的身份运行的，并检查请求解密的进程是 Chrome ），并不能从权限模型上禁止恶意软件。绕过方法很简单：用户 B 当然是有权限调试用户 B 的进程的，因此恶意软件以用户 B 的身份启动后，只需要调试用户 B 的 Chrome 即可注入任意代码，包括“解密之后发送出去”这种代码，此时 SYSTEM 身份的进程会认为请求解密的程序是 Chrome ，所以会同意。
实际上，要给用户 B 身份的非 app container 的应用程序注入代码非常简单，因为 shell 是可扩展的，只要注册一个 shell 扩展，那么在用户使用“打开”“保存”这类对话框的时候就很可能会加载此扩展。
预防针提示：Windows 8 引入的 app container 只能确保 container D 不能干扰 container D 之外的东西，不能确保用户 B 不能干扰它的 containers 。