Binder在 Android 中提供的进程间通信是否在中间攻击中受到保护？是否有提供此信息的文档？
答案 0 :(得分：18)
Binder使用基于功能的安全模型。每个绑定对象代表一种能力;将该对象移交给另一个进程授予该进程对该功能的访问权限。从这个角度来看，你可以通过不将重要的活页夹对象交给中间人来防止人在中间攻击。如果一个进程没有获得一个binder对象，它就无法以任何方式访问它。
关于论文中讨论的“交叉绑定参考伪造”问题，如果我了解他们所讨论的具体情况，我认为他们关于用户空间的附录比我同意的要弱一些。他们犯了错误我想到了为ServiceManager编写的特殊C代码。在形式上，我会将C ++用户空间代码（特别是Parcel）视为Binder体系结构的一部分。这段代码特别确保在调用readBinder（）和相关方法时处理欺骗行为。
我不同意这样的说法：内核并不能完全确保数据的完整性。我能想象的唯一方法是为活页夹事务定义标准类型的数据结构，以便它可以读取和验证包裹的内容。在我看来，这给内核带来了太多的知识，并没有真正的好处。无论您放在那里多少，用户空间都需要对传入的交易进行某种验证，以确保其符合预期。今天，这是在验证Parcel（readBinder（），readString16（），readInt（）等）上的原始数据读取操作被写入以避免攻击的水平上完成的。对内核进行更多验证仍然需要在用户空间中验证数据类型是否正确，现在您实际上已经将一些攻击机会（由于此代码中的错误）从用户空间移动到内核。
关于绑定器安全性的最后一点是，重要的是要意识到在平台级别上还有另一个重要的安全模型在绑定器基础结构之上实现。这是基于权限/ uid的系统，其中服务可以检查传入呼叫的uid以根据其允许的权限验证它们。
此安全模型还有另一个必须处理的欺骗漏洞。典型的场景是应用程序接收活动管理器服务的IBinder（因为每个人都可以获得）。活动管理器服务的API基于检查传入调用的uid以确定允许的内容 - 例如，如果调用bindService（），它将检查该uid是否有权绑定到给予服务。恶意应用程序可以通过将活动管理器IBinder交给另一个系统服务来尝试在这里玩游戏，例如作为IWindow交给窗口管理器。如果它知道第二个系统服务将进行的事务，它可以进行设置，以便它进行一个它认为是调用resizeWindow（）的调用，但实际上当它放入活动时最终变成对bindService（）的调用manager（如果这两个调用映射到相同的事务ID）。
此漏洞的存在是因为未以任何方式键入活页夹系统，“方法”调用只是使用整数事务代码和数据缓冲区发送的事务。
为了防止这种情况，aidl生成的用户空间类型接口始终在其事务缓冲区的开头放置他们打算调用的接口的名称，并且事务的接收代码检查前面的接口名称缓冲区，以确保它匹配自己的interace。这样，当活动管理器发现它的接口是用于窗口的来电时，将捕获上述场景中的欺骗者。
无论如何，对于Android开发人员的大多数实际应用，基于uid的安全性与核心绑定器功能模型一样重要。在某些情况下，您将通过限制哪些进程可以访问绑定器来强制实施安全性。这方面的一个例子是如何有一个IBinder代表每个活动，只有系统进程和运行活动的进程共享。
在其他情况下，IBinder对象将与任何感兴趣的进程共享，但在基于uid的调用点强制执行安全性。如果您使用aidl来提供此类接口的标准实现，则可以根据要应用于uid的含义来完成您自己的安全性实现。例如，您可以使用标准工具将权限与uid相关联，并询问包管理器是否有传入的uid具有权限。
答案 1 :(得分：2)
Binder有一个明确的安全漏洞，可能会使其容易受到MITM攻击：http://crypto.hyperlink.cz/files/xbinder.pdf。引用TFA：
攻击者可以管理目标以进一步传递或调用其“受保护”的绑定程序（不会邀请攻击者直接调用）。我们将其称为交叉绑定参考伪造（XBRF）
作者继续说Android中有防御这种攻击，但那
在某些情况下，对攻击过程准备的事务数据进行仔细操作仍可能导致XBRF成功利用
人们的印象是Binder似乎对于精心编写的代码相对安全，但存在一些风险。