原文作者:Z Jiang, Y Zhang, J Xu, Q Wen, Z Wang
原文标题:PDiff: Semantic-based Patch Presence Testing for Downstream Kernels
原文链接:https://secsys.fudan.edu.cn/_upload/article/files/69/06/2b05ab0d4f8bba54fd410b031ae8/7024cbe1-82e7-4308-876a-4c8973eb809a.pdf
原文来源:CCS 2020
笔记作者:[email protected]
笔记小编:[email protected]
首先需要了解的背景是,开源内核通常会被一些下游厂商应用在数十亿的设备上,但这些下游厂商经常遗漏或推迟其主流版本中的补丁发布,更糟糕的是有些厂商甚至不公开补丁的发布进展,这就导致了其设备的安全性不能够得到及时的保障,危害其用户的安全。所以对于那些常常受到安全威胁的群体来说,打补丁的情况至关重要,这就要求我们对下游厂商所发布的设备的内核中补丁的存在性进行测试。
现有的检测方式主要是通过代码签名匹配来判断目标内核中是否有补丁,但这对于实际情况来说是远远不足的。这主要是因为下游厂商通常是客制化的代码风格,这通常会改变主流版本的补丁代码以适配其自身的代码情况,使得校验失败。作者提出了PDiff,首先生成与目标补丁相关的语义摘要,然后基于这个语义摘要,PDiff会将目标内核与采用补丁前后的主流版本进行比较(选择更接近的参考版本来确定补丁的状态)。
而补丁存在性测试的主要挑战来自于主流版本和下游内核之间的代码层差异,详细来说:
以上这两种情况是十分普遍存在的,而且会在很大程度上影响补丁存在性的测试,仍然是很难处理好的点。
PDiff设计的基本原理是,目标内核和它的参考版本不论在代码层面如何改变,它们应该具有类似的语义,具体的工作流程如下图所示,简单来说分为:
本文主要深入研究了下游厂商设备中内核补丁的存在性测试方法,它主要克服了补丁存在性检测的两个关键挑战:第三方代码定制和非标准Building配置。读者在读完这篇paper后主要有两个问题:一是对于受影响代码块起始部分的判定,如果说该函数存在着父子函数关系时,应该如何取舍,究竟是扩大锚块呢还是精确缩小呢?二是选择的前后两个主流版本的问题,如何在没有对下游内核中补丁存在性做出判断依据前,精准定位到前后最近的两个主流版本?这其中的资源消耗,数据集体量又是如何?
安全学术圈招募队友-ing, 有兴趣加入学术圈的请联系secdr#qq.com