and*_*00b 16 security android android-binder
Binder在Android中提供的进程间通信是否在中间攻击中受到保护？有没有提供此信息的文档？
hac*_*bod 19
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是否具有权限.
Binder 存在一个已识别的安全漏洞，可能使其容易受到 MITM 攻击：http://crypto.hyperlink.cz/files/xbinder.pdf。引用 TFA 的话：
\n\n\n\n\n攻击者可以管理目标以进一步传递或调用其 \xe2\x80\x9cprotected\xe2\x80\x9d 绑定器（不邀请攻击者直接调用）。我们将此称为跨绑定程序引用伪造 (XBRF)
\n
作者接着说，Android 中有针对这种攻击的防御措施，但是
\n\n\n\n\n在某些情况下，仔细操纵攻击过程准备的交易数据仍然可能导致成功的 XBRF 攻击
\n
人们的印象是，对于精心编写的代码来说，Binder 似乎相对安全，但也存在一些风险。
\n| 归档时间： |
|
| 查看次数： |
4112 次 |
| 最近记录： |