Android Binder 安全

Question

Android 中 Binder 提供的进程间通信是否可以防止中间人攻击？是否有任何文档提供此信息？

Answer 1

Binder 使用基于能力的安全模型。每个活页夹对象代表一个能力；将该对象交给另一个进程授予该进程对该功能的访问权限。从这个角度来看，您可以通过不将重要的活页夹对象交给中间人来防止中间人攻击。如果一个进程没有得到一个活页夹对象，它就不能以任何方式访问它。

关于论文中讨论的“跨绑定(bind)引用伪造”问题，如果我理解他们所谈论的具体场景，我认为他们关于用户空间的附录比我同意的要弱一些。他们犯了一个错误，我认为查看为 ServiceManager 编写的特殊 C 代码。正式地，我将 C++ 用户空间代码(特别是由 Parcel 组成)视为 Binder 架构的一部分。当您调用 readBinder() 和相关方法时，此代码特别确保处理此类欺骗尝试。

我不同意内核不能完全确保数据完整性是一个缺陷的说法。我能想到的唯一方法是为活页夹交易定义一个标准的类型化数据结构，以便它可以读取和验证包裹的内容。在我看来，这在内核中投入了太多知识，并没有真正的好处。不管你在那里放了多少，用户空间都需要对传入的交易进行某种验证，以确保它符合预期。今天，这是在验证 Parcel 上的原始数据读取操作(readBinder()、readString16()、readInt() 等)被写入以避免攻击的级别上完成的。向内核推送更多验证仍然需要在用户空间验证数据类型是否正确，现在您实际上已经将一些攻击机会(由于此代码中的错误)从用户空间转移到内核。

关于 binder 安全性的最后一件事是，重要的是要意识到在平台级别有另一个重要的安全模型在 binder 基础架构之上实现。这是基于权限/uid 的系统，服务可以在其中检查传入调用的​​ uid，以根据允许的权限验证它们。

此安全模型还有另一个必须处理的欺骗漏洞。一个典型的场景是应用程序接收 Activity 管理器服务的 IBinder(因为每个人都可以得到它)。 Activity Manager Service 的 API 深深地基于检查传入调用的 uid 以确定允许的内容——例如，如果调用 bindService()，它将检查该 uid 是否有权绑定(bind)到给定的服务。恶意应用程序可能会尝试通过将 Activity 管理器 IBinder 交给另一个系统服务来玩游戏，例如作为 IWindow 交给窗口管理器。如果它知道第二个系统服务将进行的事务，它可以进行设置，以便进行它认为是 resizeWindow() 的调用，但当它进入 Activity 时实际上最终变成对 bindService() 的调用manager(如果这两个调用映射到相同的事务 ID)。

这个漏洞的存在是因为活页夹系统没有以任何方式输入，“方法”调用只是使用整数事务代码和数据缓冲区发送的事务。

为了防止这种情况发生，aidl 生成的用户空间类型化接口(interface)总是在其事务缓冲区的开头放置他们打算调用的接口(interface)的名称，并且事务的接收代码检查缓冲区前面的接口(interface)名称以确保它匹配自己的交互。这样，当 Activity 管理器看到它有一个接口(interface)是窗口的传入调用时，上面场景中的欺骗者将被捕获。

无论如何，对于 Android 开发人员的大多数实际使用，基于 uid 的安全性与核心绑定(bind)器功能模型一样相关。在某些情况下，您将通过限制哪些进程访问活页夹来加强安全性。一个例子是如何有一个 IBinder 代表每个 Activity ，只有系统进程和运行 Activity 的进程共享。

在其他情况下，IBinder 对象将与任何感兴趣的进程共享，但在基于 uid 的调用点强制执行安全性。如果您使用 aidl 来提供此类接口(interface)的标准实现，则可以根据要应用于 uid 的含义来完成此类安全性的自己实现。例如，您可以使用标准工具将权限与 uid 相关联，并询问包管理器传入的 uid 是否具有权限。