分布式云系统中权限缺失漏洞检测

2145本作品采用知识共享署名国际4.0许可协议进行许可。分布式云系统中权限检查缺失漏洞检测杰卢lujie@ict. AC. CN中科院计算所Haofeng Lilihaofeng19b@ict. AC. 中科院计算所中国科学院大学陈留liuchen17z@ict. AC. 中国科学院计算研究所中国科学院科技大学科学，中国摘要LianLiLianli@ict. AC. CN中科院计算所中国科学院大学坤成chengkun12@huawei. 华为技术有限公司有限公司，中国1介绍Missing-P-ermission-C heck（MPC）漏洞是一种不对特权操作执行权限检查的漏洞。MPC漏洞普遍存在，可能会导致严重的安全影响。本文提出了在分布式云系统中检测MPC故障的第一个工具 我们对95个真实世界的MPC漏洞进行了深入研究，我们的研究结果激发了一个名为MPEG4的新工具。该工具引入了一个组合的日志静态分析，以自动识别特权操作，通过推断环变量代表用户拥有的数据和关键的系统状态，其访问需要受到保护。我们已经评估了6个流行的分布式系统的MPPENDIX。该工具报告了44个新漏洞，其中43个已被确认并标记为严重漏洞。此外，有一个bug特别危险，开发人员要求不公开。CCS概念• 安全和隐私→分布式系统安全。关键词缺少权限检查漏洞;分布式系统ACM参考格式：卢杰，李浩峰，刘晨，李连，程坤。2022.分布式云系统中权限检查缺失漏洞的检测。在2022年ACM SIGSAC计算机和通信安全会议（CCS '22）的会议记录中，2022年11月7日至11日，美国加利福尼亚州洛杉矶。ACM，纽约州纽约市，美国，14页。https://doi.org/10.1145/3548606.3560589作者：lianli@ict.ac.cn[2]此外，还与TianQi Soft Inc.中国CCS©2022版权归所有者/作者所有。ACM ISBN978-1-4503-9450-5/22/11。https://doi.org/10.1145/3548606.3560589分布式云系统面临着巨大的安全挑战。托管在云平台上的大量有价值的数据自然会引起攻击者的注意。虽然已经引入了各种安全机制来保护云系统，但存在广泛存在的漏洞，这些漏洞可能会被利用，导致许多云漏洞[1，30，34，52，58]。在分布式云系统中的所有类型的漏洞中，访问控制漏洞是最普遍和最麻烦的漏洞之一[11，23，33，55]。分布式云系统由多个组件组成，其中每个组件提供一组可远程访问的API，用于与用户或系统中的其他组件进行通信通常，开发人员忘记在这些API中引入适当的权限检查，导致容易利用Missing-Permission-Check（MPC）漏洞。正如[4]中所研究的，不安全的接口和API占云安全漏洞总数的42%此外，我们对分布式云系统中152个真实访问控制漏洞的研究表明，其中62.5%是公共API中的MPC漏洞。 这些漏洞是许多云漏洞的直接原因[1，13，17，30，31，34，47- 49，57，58，61 ]，例如酒店预订管理系统Autocorcler中数十万预订预订的数据泄漏[47]。图1给出了分布式文件系统HDFS [12]的MPC漏洞示例。函数deleteBlockPool是一个远程可调用的API（通过远程过程调用，即，RPC）。正如其名称所暗示的那样，API将删除关键系统数据（第7行），并且应该仅由管理员访问。然而，在原始实现中存在MPC漏洞，攻击者可以远程调用API来利用此漏洞删除任意系统数据，从而对系统造成严重损害。要修复此漏洞，开发人员只需在第2行引入权限检查，确保API仅可由管理员访问。CCSJie Lu，Haofeng Li，Chen Liu，Lian Li，KunCheng21461publicvoiddeleteBlockPool（BlockPoolId blockPoolId，↩→publicboolean unique（）{1.2分布式系统现有的方法，虽然很适合其目标系统，2+checkSuperuserList（remoteUser）;//权限↩→检查项目，可能不适用于分布式系统。为了了解分布式系统中的MPC漏洞，我们进行了一个实证研究。3英里。info（“delete block pool {} by user{}”，↩→public int maximum（）;研究了10个广泛使用的分布式系统中的152个真实世界的访问控制漏洞在152个漏洞中，4、如果（）blockPoolManager。public void run（）{5throw new IOException（“...“）;（六）7这个数据deleteBlockPool（blockPoolId，force）;↩→ //特权操作8}9（62.5%）是MPC漏洞。据我们所知，这是第一次深入研究针对分布式系统中的访问控制漏洞我们的一些调查结果总结如下。1. 分布式系统中的不同组件通常实现不同的权限检查机制。因此publicbooleancompute（String strategy）{11if（！remoteUser. 等于（this）。superUser））{12throw newSystemControlException（）;13}14}图1：HDFS中的MPC漏洞（CVE-2014-0229）。1.1现有努力MPC漏洞通过查找从程序入口（主函数入口或可公开访问的API入口）到特权操作（无需权限检查）的程序路径来检测有两个步骤，如下所示。1. 识别权限检查和特权操作。2. 检查特权操作是否受到沿所有程序路径的权限检查的保护。对 于 图 1 中 的 示 例 ， 第 7 行 （ 对 方 法 数 据 的 调 用 。deleteBlockPool（））是特权操作，并且漏洞出现在从第1行（公共可访问API的入口）到第7行的特权操作的程序路径上 。 在 修 复 中 ， 在 第 2 行 引 入 了 权 限 检 查（checkSuperuserlogge（）），以保护第7行的特权操作。有几种方法可以检测操作系统[56，65]和Web应用程序[19，54]中的 在这些方法中，手动指定权限检查。 由于它们的目标系统通常在一个模块中实现权限检查API（例如，Linux中的LSM [62]），手动工作量微不足道。 给定一组手动指定的权限检查，这些方法自动挖掘特权操作的基础上的假设，特权操作必须已被保护的大多数程序路径上的权限检查。因此，其调用点经常被权限检查保护的方法被认为是特权函数，其调用点是特权操作。接下来，在识别每个任务检查和特权操作之后，可以应用经典的过程间鲁棒性分析[26，40，51]来找到那些具有未保护的特权操作的易受攻击的程序路径。这种一致性检查方法[21]对于那些部分受保护的特权操作工作良好，即，特权函数，其调用点仅在程序路径的子集上被保护。需要大量的人工工作来检查和规范分布式系统中的所有许可检查方法。此外，32.6%的权限检查是通过直接测试条件语句中的用户变量 图1中的第11行）。 不清楚如何指定这些条件语句。 如果不能正确识别权限检查，就不能精确挖掘特权操作，从而使现有方法无效。此外，大部分（60%）MPC漏洞是由程序中任何地方都没有保护的特权操作触发的。因此，现有的采矿方法无法识别这些作业。2. 在分布式系统中，权限检查和特权操作通常位于不同的组件中。因此，理解和精确分析组件间的交互是至关重要的，这是分析分布式系统中的一个众所周知的现有的静态分析不理解这种通信机制（通过RPC、消息事件或Web套接字实现），导致不完整的调用图和不精确的分析结果。此外，将静态分析扩展到整个系统（例如，一起分析分布式系统的所有组件），给定系统的所有不同组件的大的组合程序大小上述发现强调了现有方法不适用于分布式系统，并且我们需要新的技术来解决上述挑战，并有效地检测分布式系统中的MPC兼容性。1.3解决方案和贡献我们提出了一种新的方法来检测分布系统中的MPC漏洞。 我们的方法自动识别分布式系统中的权限检查和特权操作，推断环变量代表用户拥有的数据和关键的系统状态。对用户拥有的数据和关键系统状态的访问是特权操作，因为这些访问可能损坏用户数据和系统状态，或泄漏不敏感的信息。为了有效地检测MPC漏洞，我们将其表示为一个经典的过程间有限子集优化问题（IFDS）。为了提高效率，而不是直接将IFDS应用于整个系统，我们总结了组件间的通信，并分别将IFDS应用于每个组件我们的方法是基于以下两个观察。分布式云系统中权限检查缺失漏洞检测CCS2147分布式系统中的权限检查是通过检查代表用户的变量来执行的，或者直接在连接语句中（例如，图1中的第11行 ） ， 或 者 包 装 为 API （ 例 如 ， 图 1 中 的checkSuperuserlogge（））。对用户拥有的数据和关键系统状态的访问是特权操作，需要通过权限检查。直觉上，对用户拥有的数据的访问需要通过测试访问用户来检查，以避免未经授权的访问。此外，只有超级用户可以写入关键系统状态。因此，我们通过输入代表用户拥有的数据和关键系统状态的变量来自动识别特权操作。这些变量分别称为用户相关变量和系统相关变量。关键问题是：如何自动找到与用户相关和与系统相关的变量我们的研究表明，大多数与用户相关的变量（90%）都打印在日志语句中。因此，我们将日志分析与静态分析相结合，以推断与用户相关的变量。具体来说，给定所有用户名的集合，我们检查运行时日志以发现打印与用户同名的变量。随后进行基于类型的静态分析，以发现程序中更多的用户表示变量。通过相关性分析发现表示用户拥有的数据的变量，该相关性分析检查与用户变量打印在同一日志实例中的那些变量。另一方面，通过分析作为异常或错误条件检查的实例字段（例如， if（this.field）abort（）;）.这些变量被认为是临界状态变量，因为它们的值指示异常错误条件。我们实现了我们的方法在一个新的工具，名为MPEG4和6流行的分布式系统上进行评估。该工具正确地发现了这些系统中的数百个特权操作和权限检查，并报告了44个以前从未发现过到目前为止，已经修复了20个报告的错误，23个错误已经由原始开发人员确认 所有确认的错误都被标记为可能容易被利用的关键错误。此外，有一个bug是特别危险的，最初的开发者要求不公开它该工具还报告了7个误报，误报率为13.7%。本文的贡献归纳如下：首次对分布式系统中的95个MPC漏洞进行了深入研究。 我们的研究揭示了分布式系统中MPC漏洞的新检测技术。我们提出了一种新的基于日志的分析，以检测MPC的脆弱性在分布式系统中。我们的方法自动发现权限检查和特权操作在高精度，通过推断变量代表用户拥有的数据和关键系统状态。我们开发了第一个用于分布式系统的MPC漏洞检测工具该工具成功地报告了6个实际分布式系统，误报率为13.7%。在本文的其余部分，第二节详细研究了95个真实的MPC可验证性 我们在第3节中说明我们的方法，并在第4节中评估它。第5节回顾了相关工作，第6节总结了本文。表1：正在研究的分布式系统。系统类型校验机制Bug数量HDFS[12]分布式文件系统M1、M3、M48[20]第二十话数据处理框架M1、M31YARN[59]资源管理系统M1、M313HBase[60]键值数据库M1、M435[29]第二十九话协调处M11Kafka[35]数据处理框架M1、M40Mesos[27]资源管理系统M1、M425MongoDB[16]文档数据库M1和M21Kubernetes[10]资源管理系统M1、M2、M3、M43操作enStack[50]云计算平台M1、M38总--952特性研究我们在表1中研究了10个广泛使用的分布式系统。这些系统提供不同的服务（第2列），并使用不同的语言编写，包括Java，C++，Go，Scala和Python。 我们的研究结果在https：//github上公开。com/lujiefsi/MP3.2.1漏洞收集我们在表1中的10个系统中编译了一组152个访问控制漏洞（包括95个MPC漏洞）。对于每个漏洞，我们收集其描述，修复补丁和开发人员的相关讨论。从CVE（常见漏洞和暴露）可扩展性数据库中收集了49个漏洞[5]。 我们检查了2012年10个系统中所有报告的368个CVE，并过滤出49个访问控制漏洞。其余103个漏洞来自所研究系统的问题跟踪系统。我们使用以下关键字查询每个问题跟踪系统：“访问控制“、“授权“、“安全检查“、“权限检查“、“特权检查“、“仅限管理员“和“仅限“。基于关键字的搜索共返回3，058个问题。我们手动检查每个问题，并获得103个真正可利用的访问控制漏洞。在152个访问控制漏洞中，95个（62.5%）是MPC漏洞，通过引入额外的每个任务检查来修复除了Kafka，我们研究的所有系统都存在MPC漏洞。Kafka通过API钩子透明地授权外部请求，有效地防止了此类缺陷。其余57个访问控制漏洞是由错误的每任务检查实现引起的（例如，检查错误的用户、错误的访问控制策略等）。如何检测这些访问控制漏洞值得单独研究。2.2警告正在研究的95个漏洞，虽然广泛，但决不是完整的，有些结果可能无法推广。为了减少这种威胁，我们选择了广泛的10个流行的分布式系统。这些系统包括分布式文件系统、协调服务、资源管理系统、键值数据库、面向文档的数据库、数据处理系统和云·····CCSJie Lu，Haofeng Li，Chen Liu，Lian Li，KunCheng2148○○○○○○○○○○○publicStringgetAp（String getAp）{2Set Application> result=newHashSet Application>（）;3因为（应用程序：这个。应用程序）{四级以上如果（！附录getUser（）. equals（remoteUser））{//ad-hoc↩→权限检查5+继续;6+}7结果add（app）;//特权操作8}9返回结果;10}图3：一个临时权限检查示例（YARN-8455）。图2：四种不同的权限检查机制。计算平台，涵盖云计算中的大多数关键要素 这10个系统是用不同的语言（C/C++、Java、Scala、Go和Python）编写的，并且通常实现不同的权限检查机制。由于工作性质复杂，涉及大量人力，可能存在主观性 为了减少这种威胁，每个漏洞都由本文的至少两名作者进行检查和交叉验证，如以前的工作[7，22]。2.3结果我们研究每个MPC漏洞，以了解其权限检查机制，触发特权操作，并参与组件。 所有漏洞都通过在远程访问API中引入权限检查来修复，从而暴露错误。2.3.1权限检查机制。 图2描述了分布式系统中的4种每任务检查机制，它们在如何调用权限检查API方面彼此不同。M1. 这是在同一个节点上执行外部请求和权限检查的传统机制M4.该机制采用集中式节点对用户请求进行授权和调度：1用户请求由授权节点处理，2如果允许，授权节点将请求转发给服务器节点，3服务器节点处理请求并返回给授权节点，○4.授权号码是对用户的回复。如表1（第3列）所示，每个研究的系统采用一种或多种机制，经典机制M1在所有研究的系统中均得到实现M2在远程节点上执行权限检查，而其他3种机制通过直接API调用在本地检查权限。尽管在不同的机制中被不同地调用，但所有权限检查API都以 类 似 的 方 式 实 现 权 限 检 查 例 如 ， 在 图 1 的 示 例 中 ，APIcheckSuperuserlogge（）只是测试访问用户是否是超级用户（第11行）。请注意，尽管M3实现了基于令牌的授权，但它仍然会检查访问用户和输入令牌。在许多情况下，权限检查是通过直接测试条件语句中的用户变量来完成的，而不是调用其包装API。在所有95个MPC漏洞中，32.6%（31个）通过临时权限检查修复。例如，在图3中，漏洞（YARN-8455）通过直接测试访问用户（第127 - 129行）来修复。请注意，目前还不清楚如何手动指定这些临时权限检查。调查结果1：有四种不同的机制，○1用户向服务器发送请求，○2服务器不同方式的权限检查API所有API均为IM-节点在返回请求结果之前调用相应的权限检查APIM2. 在该机制中，在单独的节点上执行许可检查：1用户向服务器节点发送请求，2服务器节点向授权节点发送许可检查查询（经由RPC或web套接字），3服务器节点从授权节点接收响应（接受或拒绝），4如果许可被授予，则服务器节点响应请求并返回结果。M3. 这是基于令牌的授权：1用户向认证节点请求令牌，2返回具有认证和授权信息的令牌，3用户将请求与授权令牌一起发送到服务器节点。4.服务器节点在响应请求之前检查令牌和用户的许可。通过简单地测试条件语句中的用户变量来执行元素权限检查。在许多情况下，特权操作由这个简单的条件测试直接作为临时权限检查来保护：95个研究的MPC漏洞中有31个通过引入临时权限检查来修复。2.3.2的操作。在所有95个MPC漏洞中，其中84个访问用户拥有的数据（即，用户相关的变量）而不进行权限检查。例如，图1和图3中的两个漏洞分别通过对用户拥有的数据块PoolId和app的无保护访问来表现。用户拥有的数据可以由用户直接创建，或者可以从其他用户拥有的数据中传递导出。 分布式系统通常划分大的数据块（例如，由用户创建的数据）分成小块。那些小分布式云系统中权限检查缺失漏洞检测CCS2149publicString remoteUser（String remoteUser）{//RPC方法2+checkSuperuserList（remoteUser）;//权限↩→检查3//只能调用一次。4、如果（）shutdownInProgress）{5throw newIOException（“已在↩→中求进工作总“）;（六）7这个returntrue;//privileged↩→操作八......（9）图5：修改系统相关变量的漏洞（HDFS-CVE-2014-0229）。1/* 错误：以下方法可能会损坏群集。*/publicbooleancompute（String s）{3+ getCodeprocessorHost（）。preClose（request. return（）;↩→ //权限检查图4：所有10个研究系统的通过组合的日志静态分析自动推断结构为了清楚起见，没有给出许多与用户相关的类型。数据段由系统管理并且通常对常规用户不可见，即，只有系统管理员才能访问它们以进行系统维护。例如，在HBase中，Table对象由普通用户创建，可以划分为小区域（Region类型的对象）。 Table和Region都是与用户相关的类型，分别由常规用户和系统用户管理。需要检查对两种类型（区域和表）变量的访问。图4显示了10个研究系统的用户相关类型的层次结构每个正方形代表一个与用户相关的类型，边代表这些类型的数据之间的关系例如，在HBase中，表空间对象由用户直接创建，而表对象可以由用户直接创建，或者从表空间对象派生。我们发现，对于80/84（95.2%）漏洞，错误触发变量与无保护访问打印在日志中。 作为示例，在图1中，第3行记录用户拥有的数据块PoolId以及访问用户remoteUser。另一个有趣的发现是，超过一半的无保护变量（50/84）不是由用户直接创建的。这些派生的变量很容易被开发人员忽略，而且往往没有得到适当的保护，从而导致MPC漏洞。其余11个漏洞在不检查权限的情况下修改关键系统状态。如图5所示，实例字段shutdownInProgress表示节点是否正在关闭的状态。如果是，则该节点上的所有操作（例如，写入数据）将被阻止。 此变量只能由管理员修改。但是，公共APIshutdownDatanode（）忘记检查访问用户，导致MPC漏洞。请注意，现场关闭InPogress作为错误条件进行测试4String name = request. return（）;5HRegion region = thisrsServices。return（name）;6CloseRegional.crh=new↩→close（region）;7这个executorService. return（rh）;8}9//CloseRegion扩展EventNode10publicvoidprocess（）throwsIOExceptiopnri{vilegedoperation十一尺。intfindDuplicate（）;1213}14//权限检查publicvoidpreClose（String user）抛出IOException {十六...17if（！user. 等于（this）。所有者））{18throw newSystemControlException（）;19}二十...21}图6：涉及多个组件（HBASE-7331）。如果测试失败，则会导致异常（第4 - 6行）。事实上，10/11未受保护的系统相关变量被测试为错误条件。发现2：在95个MPC漏洞中，有84个漏洞对用户相关变量进行了未经授权的访问，其中80/84的用户相关变量被打印在日志中。其余的11个可测量性修改关键系统相关变量，其中10个系统相关变量用作误差条件。2.3.3组件交互。 有28个漏洞直接涉及多个组件，这意味着特权操作或其修复权限检查是在不同的组件上远程执行的。图6给出了一个示例（bug和图1中的bug被分组在一起并分配给一个CVE）。APIcloseRegion（）是一个RPC函数，它试图使区域离线，并且应该是管理员可以访问的这个onlineRegions. return（）;CCSJie Lu，Haofeng Li，Chen Liu，Lian Li，KunCheng2150图7：MPBecker概述。只. 这里缺少权限检查表明任何用户都可以删除HBase中的任意区域，对系统造成巨大损害。有趣的是，即使开发人员评论说这种方法会损坏集群，他们仍然忘记检查其权限。在本例中，特权操作是远程执行API closeRegion（）将请求包装为CloseMetaDataEvent（第6行）并在第7行提交。然后将事件分派到其对应的处理程序，即，process（），其中调用第12行的特权操作从系统中删除区域。因此，第7行的事件发送调用最终由其对应的事件处理程序处理 为了保留这样的语义，我们需要将事件发送调用链接到其对应的处理程序，如[43]所示。请注意，虽然只有28/95漏洞直接涉及多个组件，但组件之间的交互在所有研究的系统中都很普遍。其中一些交互可能包含权限检查或特权操作。如果不考虑这些远程权限检查和特权操作，则会出现误报和漏报因此，它是至关重要的，以精确地分析组件间的通信检测MPC漏洞在分布式系统中。发现3：28/95（29.5%）漏洞直接涉及多个组件。3 MPCHECKER图7从高层次上概述了MPERFORMANCE该工具包括3个步骤。首先，我们通过分析所研究系统的运行时日志来自动推断用户和系统相关的变量，以与其字节码（目前该工具只能分析Java程序）。接下来，从推断变量的集合中识别权限检查和特权操作。在最后一步中，如果可以从公共接口访问那些未受权限检查保护的特权操作，则将其报告为MPC漏洞。MPEG4需要手动指定用户名、公共接口和组件间通信模式。图8给出了HBase的简化规范。需要用户名来推断与用户相关的变量。给定接口（即，BlockingInterface）定义系统的入口点，1规范2用户：3user1：hadoop，hbase：hadoop，yarn：hadoop4接口：BlockingInterface5RPC：6客户端：BlockingStub7服务器：MasterRpcServices8事件：9context：null10客户端：ExecutorServer。提交（$1）11服务器：$1. process（）图8：HBase的简化规范示例由用户远程调用在[45，65]中，实现指定接口方法的公共方法通信模式（RPC、消息事件和Web套接字）被指定为客户端/服务器对，分别表示请求发送客户端和请求处理程序我们通过提供一个客户端类及其相应的服务器类来指定RPC（第5 - 7行），因为RPC是通过一个客户端类和一个实现相同接口的相应服务器类来实现的。消息事件和Web套接字是通过提供上下文敏感的客户端站点及其处理程序来定义的。上下文表示调用上下文，例如包含函数和case条件。空上下文表明处理程序在任何调用上下文下都解析为相同的目标我们使用Meta变量$1来表示客户端请求的实际参数类型，该类型用于解析客户端的相应处理程序（第8 - 11行）。让 我 们 看 看 图 6 中 的 例 子 。 第 7 行 对 方 法this.executorService.submit（crh）的调用是一个事件客户端。由于参数crh的类型为CloseRegions.process，因此事件处理程序被解析为CloseRegions.process（）。3.1推断用户和系统相关变量正如发现2所指出的，大多数与用户相关的变量都打印在日志中，而与系统相关的变量通常作为错误条件进行测试因此，我们检查运行时日志，并结合基于类型的静态分析来发现与用户相关的变量。作为错误条件检查的实例字段被视为系统相关变量。或者，我们可以采用一种纯静态的方法，静态地检查每个日志记录语句。但是，它需要用户手动指定所有用户表示变量，这是劳动密集型的，容易出错。3.1.1用户相关变量。 首先，我们需要弄清楚哪个变量代表用户。这是通过对数分析实现的[63]。 日志分析为每个日志记录语句构造一个正则表达式模式，其中字符串文字保存在表达式中，记录的变量抽象为“.*“的。然后将此模式与运行时日志进行匹配，以从匹配的日志实例中提取日志变量的具体运行时值具有与给定用户名相同值的变量是用户表示变量。我们使用图9和图10中的简单示例（摘自HBase）来说明日志分析是如何工作的，图9显示了3个日志语句及其运行时日志实例分布式云系统中权限检查缺失漏洞检测CCS2151⟨⟩1美元。info（user+“created table“+ table）;2//".*“已创建表“。*“3英里。info（“创建的区域“+区域）;4//创建区域“.*“5英里。info（“初始化分配过程：table=”+table1↩→ +“，region=”+region“）;2. 如果变量的类型与用户相关变量的类型匹配，则该变量是用户相关变量。类型������与if匹配������1）������是与相同或继承自的对象类型������，2）如果它是具有与匹配的一个元素类型������的集合，或者3）如果它具有与匹配的类型的索引字段������。我们的日志分析有效地发现用户相关的变量，6//初始化赋值过程：table=“.*“，区域=+↩→“。“日志实例。但是，某些与用户相关的变量可能未被记录，或者它们的日志记录语句可能尚未执行。图9：HBase的简化日志语句及其日志1user1创建了表'table1'2user1创建了表'table2'3创建区域“区域1”4创建区域“区域2”5初始化分配↩→过程：table='table1'，region='region1'因此，我们执行一个简单的基于类型的分析，如上面的规则所总结的，以找到程序中所有其他与用户相关的变量前两种情况的类型匹配规则是可以自我解释的。第三种情况是处理字段用于唯一索引其包含对象时的常见做法例如，在HBase中，字段region用作RegionInfo的索引。因此，RegionInfo也被视为与用户相关的类型。基于类型的分析仅适用于具有对象类型的用户相关变量我们使用简单的基于类型的分析来代替经典的指针分析，因为与用户相关的变量是6初始化分配↩→过程：table='table1'，region='region2'对于分布式系统的通常类型良好、精确和可靠的指针分析[41，42]仍然是一个开放的研究课题。对于原始类型的变量，我们遵循它们的use-def链，图10：HBase的简化运行时日志实例在图10中给出。 我们研究的系统使用常见的日志库，如SLF4J[3]和Log4j[2]，提供的日志接口包括致命，错误，警告，信息，调试和跟踪。对于每个日志语句，我们提取一个日志模式表示的正则表达式。在图9中，每个语句提取的日志模式在注释中突出显示。日志中打印的变量被抽象为“.*“，并且它们的运行时值可以从匹配的日志实例中获得（如[63]中所示）。为保留它们传播到的变量集具体来说，我们检查一个连续类型变量的def-use链，以发现它被分配/存储的那些变量/字段。这个过程迭代地应用于那些新发现的变量，直到一个固定点。因此，发现从用户相关变量传递分配的所有变量（字段）。3.1.2系统相关变量。 我们发现系统相关的变量的基础上，他们经常被测试为错误的条件。因此，我们首先找到那些错误指示程序点中止正常执行。实例，日志模式“.*“已创建表“。*“火柴使用日志实例“user1 created table结果，日志变量user和table的运行时值分别被提取为“user1”和“'table1'”。 变量user表示名为“user1“的用户。RUle 1. 如果一个变量与一个用户变量或另一个用户相关变量打印在同一个日志实例中，则该变量是用户相关变量。上述规则用于从日志中发现与用户相关的变量出于审计或诊断的目的，系统通常在用户访问其数据时或用户数据被进一步分区或移动时记录事件因此，如果这些变量与用户变量一起出现在同一个日志实例中，则很自然地将它们视为与用户相关的变量。这些变量通常表示由用户直接创建的数据只有其所有者才能访问这些数据类似地，在同一个日志实例中的变量与另一个用户相关的变量表明它是从另一个用户相关的变量派生的。在图10的示例中，variabletable和user出现在同一个日志实例中（第1行和第2行）。因此，table是一个与用户相关的变 量. 注 意， 变 量 表具 有多 个运 行时值（即， “'table1'”和“'table2'”），这表明用户可以在运行时创建多个表。变量区域打印在与表相同的日志实例中（第5行和第6行），并被视为从表派生的用户相关变量。1如果（这个）停止）{2英里。error（“节点已停止”）;③回归;（四）我们考虑以下两种类型的错误指示程序点：1）抛出异常的语句（例如，图5中的第5行），以及2）紧接在故障级别日志记录语句之后的公共API的返回语句（例如，error（）），就像上面的代码片段一样给定一个错误指示点，我们检查它直接控制依赖的条件语句。如果条件状态检查实例字段，则将该字段视为系统相关变量。直觉上，系统状态通常存储在实例字段中。条件语句还可以测试输入条件（例如，参数或函数返回值），这些检查的变量不计为系统相关变量。3.2确定权限检查和授权操作3.2.1权限检查。如发现1所述，权限检查是通过直接测试用户变量或调用封装这些用户测试的API来因此，所有测试用户变量的条件语句都是权限检查。许可检查CCSJie Lu，Haofeng Li，Chen Liu，Lian Li，KunCheng2152∨？API通过函数总结来识别：如果存在权限检查后支配其条目，则方法是权限检查API。例如，图1中的checkSuperuserlogge（）和图6中的preClose（）被概括为权限检查API。有时，API仅在启用授权服务时执行权限检查，如下面的代码片段所示。publicvoidonDestinyNode（String s）{2RouterPermissionList pc= getPermissionList（）;3if（pc！= 空值）{4件。return（user）;（五）（六 ）当未启用安全配置时，授权对象pc为空，跳过第4行的检查在不考虑这种情况下，我们将报告许多MPC漏洞，这些漏洞只有在禁用安全配置时才能触发。开发人员认为这种配置是故意的，并经常将其归类为误报。为了解决这种情况，我们采用了与[65]类似的策略：当权限检查调用由其接收对象上的空检查保护时，我们标记空检查（即，示例中的第3行）作为包装器许可检查。3.2.2的操作。 对用户或系统相关变量的访问被归类为特权操作。 更具体地说，那些写入用户或系统相关变量或泄漏用户相关变量的操作是特权操作。直觉上，他们建议危险的操作，可能会破坏用户数据或整个系统，或者可能会泄露敏感信息。写操作是对用户或系统相关变量的putField指令（Java字节码）。如果变量是一个集合，则调用API修改集合（通过删除或添加元素，例如，插入和移除）被手动标记为写操作。与用户相关的变量可能包含所有者私有的敏感信息。因此，如果语句从公共API返回用户相关变量，或者如果它将用户相关变量写入IO，则该语句是特权操作。由于这种操作可能会向公众泄露敏感信息，因此被标记为泄漏操作。 我们乐观地假设int或bool类型的变量不包含敏感数据，并过滤掉int或bool类型变量的泄漏点。3.3检测MPC漏洞如果存在从程序条目（公共API的条目）到特权操作的程序路径，则MPC漏洞会表现出来。我们将MPC漏洞的检测公式化为一个经典的IFDS（过程间、有限、分布、子集）低概率问题，在分析复杂的通信机制实现（其中大量使用了反射等动态特性）的艰巨任务中，我们依赖于用户规范（图8）来解析客户端请求的目标。然后，请求可以被视为对其处理程序的直接调用。 因此，系统的不同组件可以连接在一起，并且可以以标准方式分析系统。然而，它往往是不切实际的分析一个分布式系统作为一个整体，鉴于其所有组件的大型组合程序大小。因此，我们不是将所有组件链接在一起，而是应用函数summary来总结请求是由权限检查API还是特权操作处理的。如果请求的相应处理程序中存在未保护的特权操作，则该请求被视为特权操作否则，如果存在后支配处理程序入口的权限检查，则它是权限检查。以图6为例。第7行的事件发送客户端（this.executorService.submit（））被概括为特权操作，因为在其处理程序（CloseRegion-Projective.process（））中存在未保护的特权操作（第12行）。通过这种优化，我们可以单独分析每个组件，从而显著减少程序大小并提高效率。3.3.2数 据 流 分 析 。 IFDS （ inter-procedural ， finite ，distribute，subset）算法，Reps et al. [51]解决了大量的过程间数据流问题作为广义图可达性问题。该算法在所谓的分解图上操作在程序的过程间调用图（ICFG）中的每个程序点处，为分析域中的每个数据流事实向分解图引入节点边封装了数据流分析中传递函数的语义。一个数据流事实在程序点保持，如果存在一个可实现的路径，从程序入口到它的代表节点的扩展图。 对于上下文敏感性，从函数返回需要与其调用站点匹配，以使路径可实现。对于MPC漏洞检测，数据流值为真或假，表示点是否未被保护，即，是否存在从程序入口到不检查权限的点的路径。方程1-3给出了数据流函数。 分析沿着程序的ICFG向前传播数据流值。在公共接口的入口处，该值被初始化为true，并且仅通过权限检查将其设置为false在程序点，当多个路径收敛时，沿着不同路径的数据流如果在特权操作中分析结果为真，则将报告MPC漏洞。���������������������=������������(1)lem [51]，它有效地计算特权操作是否由权限检查保护。未受保护的特权操作表明存在从条目到���������=���∈���������������.������������中国（2）没有权限检查的特权操作。3.3.1部门间通信。的关键挑战之一���用户权限检查���否则的话（三）分析分布式系统的关键在于如何有效地处理组件间的通信[9]。组件通过RPC、消息事件或Web套接字相互避免3.3.3举个例子 让我们看看图11中的例子。 API move是一个公共API，可以远程调用它来将给定区域移动到目标节点。如果给定了目标节点，.����