JavaScript引擎差分模糊：JIT-Picker技术的软件故障检测

351本作品采用知识共享署名国际4.0许可协议进行许可。J IT-P I c KI ng：JavaScript引擎的差分模糊卢卡斯·伯恩哈德德国波鸿鲁尔大学lukas.rub.deTobias Scharnowski德国rub.de波鸿鲁尔大学tobias.scharnowski@www.example.comMoritz Schloegel德国波鸿鲁尔大学moritz.rub.de摘要蒂姆·布拉兹特科tim. rub.de托尔斯滕·霍尔茨CISPA德国亥姆霍兹信息安全中心holz@cispa.deACM参考格式：现代JavaScript引擎为网站甚至Web上的完整应用程序提供动力，这是由对日益快速和敏捷的用户体验的需求所驱动的。这些引擎使用几个复杂的和潜在的易错机制，以优化其性能。不出所料，不可避免的复杂性导致了巨大的攻击面和各种类型的软件漏洞。在防御者方面，模糊测试已被证明是发现不同类型的内存安全违规的宝贵工具。虽然很难以自动化的方式测试解释器和JIT编译器，但最近提出的基于语法或特定于目标的中间表示的输入生成方法有助于发现许多软件错误。然而，JIT引擎中的优化过程中产生的微妙的逻辑错误和错误计算继续逃避最先进的测试方法。 虽然这些缺陷乍一看似乎不起眼，但在实践中往往仍然可以利用。在本文中，我们提出了一种新的技术，有效地发现这类微妙的错误在模糊。其关键思想是利用JavaScript引擎的解释器和其相应的JIT编译器之间的紧密耦合作为特定于域的通用错误预言，这反过来又产生了一个高度敏感的故障检测机制。 我们已经设计并实现了一个原型的方法，在一个工具，称为J IT-P I cker。 在实证评估中，我们表明，我们的方法使我们能够检测到微妙的软件故障，以前的工作错过了。我们总共发现了32个不为公众所知的bug，并获得了10美元的奖励。000个漏洞奖金，作为对我们在JIT引擎安全方面所做贡献的奖励CCS概念• 安全和隐私→浏览器安全。关键词Fuzzing，软件安全，差分测试，JIT引擎，浏览器CCS©2022版权归所有者/作者所有。ACM ISBN978-1-4503-9450-5/22/11。https://doi.org/10.1145/3548606.3560624Lukas Bernhard ， Tobias Scharnowski ， Moritz Schloegel ， TimBlazytko，and Thorsten Holz. 2022年。JIT-PI ckI ng：JavaScript引擎的差分模糊在2022年ACM SIGSAC计算机和通信安全会议（CCS'22）的会议记录中，2022年11月7日至11日，美国加利福尼亚州洛杉矶 。 ACM ， 纽 约 州 纽 约 市 ， 美 国 ， 14 页 。https://doi.org/10.1145/3548606.35606241引言JavaScript是Web上的主要编程语言，其中绝大多数网站使用JavaScript代码来实现诸如内容加载、动画、表单验证、数据记录或类似功能的任务。一般来说，Web浏览器包括在客户端执行相应代码的JavaScript引擎 近年来，服务器端JavaScript也通过Node.js等框架受到了很多关注，这些框架可以在客户端和服务器端代码之间实现更简单的数据共享。事实上，Node.js的包管理器npm是世界上最大的包注册表JavaScript语言本身提供一流的函数，是动态类型的，单线程的，并提供基于原型的面向对象。在实践中，三种不同的JavaScript引擎被广泛使用：首先，Google其次，Mozilla基金会维护着SpiderMonkey，它被用于各种 Mozilla 项 目 ， 最 著 名 的 是 Firefox 浏 览 器 。 最 后 ，JavaScriptCore（JSC）是一个为WebKit实现提供JavaScript引擎的框架，WebKit实现通常用于苹果生态系统中的macOS和iOS上的Safari浏览器作为浏览器战争的一部分，在浏览器使用份额的主导地位的竞争，这些引擎发挥了重要作用，因为更快，更快的用户体验是推动这场竞争的主要因素。一个关键的见解是，解释型代码通常比本机代码慢-JavaScript作为一种解释型语言，尤其受到这个缺点的影响。因此，开发人员选择在JavaScript引擎中部署即时（JIT）编译器来编译频繁执行的代码路径，然后以更高的速度执行它们。虽然概念上很简单，但JIT引擎在发出本机代码之前使用了复杂的分析和优化过程作为推动不断提高性能的结果，这些发动机实施方案针对速度和性能进行了大量优化。352CCS效率;许多新颖的技术[49，51]已经专门开发出来，以快速有效的方式执行代码现代的JavaScript引擎是高度复杂的软件，例如.例如，在一个实施例中， Google v8引擎由大约230万行代码组成，其中大部分（大约100万行）都是由一个简单的代码组成。 160万LoC）是在内存不安全的编程语言C ++中实 现的[55]。鉴于这些工具的巨大实际重要性及其广泛的实际部署，它们是一个有吸引力的攻击目标 在撰写本文时，漏洞代理（如Zerodium）为常见浏览器的远程代码执行漏洞支付了超过20万美元[66]，而JavaScript引擎在不情愿地提供稳定的漏洞利用原语流方面发挥了关键作用。在实践中，攻击者对浏览器中执行的JavaScript代码具有细粒度的控制-他们可以扭曲每个细节，甚至滥用由细微错误引起的最小的不一致。更具体地说，攻击者可以从一个（或多个）导致内存损坏的不一致性中精心制作完整的漏洞，即使不一致性本身不是内存损坏漏洞，也不会导致内存安全违规和由此产生的崩溃。为了修复攻击，最近的研究集中在测试JavaScript引擎潜在安全漏洞的技术上，尤其是模糊测试（简称fuzzing）发挥了特别重要的作用[19，21，23，30，45，47，60]。 所有提出的模糊方法都有一个共同点，即它们都是针对JavaScript引擎的输入生成进行高度优化的。例如， 他们试图生成多样的JavaScript代码以到达尽可能多的不同代码位置。 基于最大化代码覆盖率的典型反馈回路对于其他类型的软件也非常成功[14，36，48]。因此，已检测到许多不同类型的漏洞。然而，现有的技术依赖于相当一般的缺陷检测预言机来检测软件故障，例如，例如，在一个实施例中，消毒器[52]或其他方法来检测内存安全漏洞。不幸的是，这在实践中是一个粗粒度的度量：许多错误不会使程序执行崩溃或破坏内存安全。JIT引擎的复杂性和优化特性通常只会导致很小的不一致性或轻微的错误结果，这是由于当前错误检测系统遗漏了逻辑错误。这导致了一个有点矛盾的情况：目前的模糊技术已经能够在JavaScript引擎中运行逻辑错误，但他们缺乏识别他们已经发现了一些有趣的东西的技术（e.例如，在一个实施例中，执行代码中的不一致性更具体地说，当前的方法实现了极好的代码覆盖率，但是所执行的错误的实际症状对于非特定于域的错误预言机来说太微妙而无法检测到。为了克服这一挑战，最近的工作提出了对JavaScript引擎使用差异测试[32，38，39]。 其基本思想是在实现相同功能的多个程序中执行给定的输入，并检查其行为中可观察到的差异。如果发现差异，则可能发生了逻辑错误。然而，这些最近的作品比较不同的JavaScript引擎对彼此，特别是，他们不针对JIT编译本身。因此，现有的方法不能发现在JIT优化过程中引入的细微变化，这是实践中漏洞的主要来源。此外，相互测试不同的引擎需要大量的跨引擎规范化工作：JavaScript是一种不断发展的语言，并且不能摆脱 实 现 定 义 的 行 为 （ 例 如 ： 例 如 ， 在 一 个 实 施 例 中 ， 调 用array.sort（）不引起元素的总顺序的比较器函数导致以引擎特定的方式对数组进行排序因此，会出现许多误报，每一个都需要潜在地耗时的手动分析。另一个缺点是不同的引擎支持不同的特性;因此，只能测试交集（导致代码和特性覆盖率降低）。在本文中，我们提出了设计和实现的JIT- PI cker，一种方法，有效地发现不一致所造成的误导JIT优化使用差分模糊。我们的目标是检测表现为计算错误的逻辑错误，因为这样的软件故障很难（如果不是不可能的话）用当前最先进的方法找到。基本思想是通过执行两次JavaScript代码来测试JavaScript引擎：一次启用JIT编译器，一次不启用JIT编译器，即：例如， 完全依靠翻译。行为的比较使得特定于域的和通用的错误预言器能够检测到甚至超出先前工作中考虑的内存安全违规的细微错误症状。 虽然高层次的想法很简单，但其正确和有效的实现具有挑战性，原因有几个：（1）我们必须确保确定性的引擎行为，以防止误报，(2) 我们需要实现对状态的无副作用观察（我们已经实现了我们的方法的原型，JIT-PIcker，基于FUZZIIII[19]。我们构建了对执行模型的扩展，将有效的探测机制纳入生成的输入中，并对所有三个主要的JavaScript引擎进行检测以支持我们的方法（例如，例如，在一个实施例中，通过抑制语言内置程序的非确定性行为或内存不足 我们的评估结果表明，J IT-P Icker可以有效地检测已经经过彻底测试的JavaScript引擎中的新错误：我们在测试的引擎中总共发现了32个以前未知的错误，并将我们的发现披露给受影响的供应商;在撰写本文时，这些问题中的大多数已经被修补。对检测到的故障的分析表明，它们并不表现为分段故障或消毒程序违规条件，因此无法使用最先进的方法检测这些漏洞Mozilla以10美元的bug赏金来奖励我们对JIT安全性的贡献。000，并计划在内部部署J IT-P I cker来测试他们的引擎。捐款. 总之，我们做出了以下贡献：(1) 我们提出了一种新的方法来有效的差分测试，把一个JavaScript引擎对自己：我们仔细注入状态探针比较运行时行为的JavaScript解释器与它自己的JIT编译器，使我们能够发现软件错误引入误导优化通行证。(2) 我们展示了如何使用这种方法作为具有前所未有的灵敏度的错误预言机：它在执行过程中提醒模糊器即使是很小的不一致，使我们能够识别微妙的，但可能具有高影响力的错误，最先进的预言机是盲目的。 我们发现，所识别的故障可能在受害者的浏览器中具有很高的安全影响。(3) 我们实现了一个完整的原型所提出的方法在一个工具，称为J IT-P I cker和评估它的三个主要的JavaScript引擎。在一次实证评估中，我们发现了32个bug。更仔细的分析表明，我们发现的大多数错误JiT-Picking：JavaScript引擎的差分模糊化CCS353functionf（a）{2returna+ a;（3）45for（leti= 0; i<100000; i++）{6//用于数字加法的7f（1.0）;8}9//用不同的类型调用f会导致a10//由于不匹配的类型而11f（“abc”）;清单1：JavaScript JIT编译的示例用例寿命超过一年 我们以协调的方式向各个供应商披露了已识别的错误，大多数错误已经修复。为了促进对这个主题的研究，我们在www.example.com上发布了 源 代 码 和 所 有 研 究 工 件 https://github.com/RUB-SysSec/JIT-Picker。2保障JavaScript（JS）JIT引擎的安全是出了名的困难[8，16，31，43]。尽管在文献[19]中提出了各种技术，21，30，45，47，60]，JS引擎中软件故障的有效识别仍然是一个具有挑战性的问题。在下文中，我们首先讨论JIT编译代码的挑战然后，我们提出了一个概述，目前的技术来发现错误，并讨论其在实践中的局限性。2.1JavaScript JIT编译考虑到JS引擎的性能对于用户在网上冲浪时的体验至关重要，JS代码被语句解释的时代已经过去很久了。许多类型的性能改进被实现，今天例如，特别是经常执行，并将这些函数即时（JIT）编译为本地机器指令。事实上，JS代码是动态类型的，这使得它很难正确优化考虑清单1中显示的示例代码。函数f（）中的语句a + a（第2行）根据操作数的类型有不同的语义：数字的数字加法，字符串的连接，等等。因此，JS引擎的解释器收集运行时类型信息，这反过来又是针对频繁使用的类型优化函数的基础在这个例子中，观察到a在第7行的for循环中为大量函数调用保存Number类型的值。因此，在JIT编译阶段，编译器推测这些类型将保持不变，并发出本机代码来快速执行数字加法。这样的推测性优化实现了针对每个数据类型专门优化的高效代码。然而，JS的动态类型化意味着关于观察类型的假设可能在将来失效在我们的示例中，这是由于在第11行使用字符串参数调用f（）因此，JIT编译器必须发出额外的类型检查，以在运行时验证其优化假设的适用性。 失败的验证会导致救助（i. 例如，从编译代码转换回解释器），其中所观察的类型信息被更新并被考虑用于潜在的重新编译。任何不会导致紧急状态的运行时验证都会消耗宝贵的CPU周期，而不会实际推进程序的执行。因此，JS引擎试图删除不必要的检查，e. 例如，在一个实施例中， 这些假设可以证明在任何情况下都成立。 例如，由于对许多内置Math函数的调用返回Number类型的值，因此代码优化通道可能会发出本机算术指令，而无需进一步的类型检查。此外，JIT编译器利用传统的编译器优化技术（例如，例如，在一个实施例中，混叠分析、范围分析、死码消除、循环不变码运动等）来删除更多的运行时检查。 因此，JIT编译比解释代码产生了实质性的性能改进，并被当前浏览器中的所有JS引擎使用。2.2模糊化JavaScript引擎鉴于JIT编译器的复杂性，它们会导致JS引擎中的大量错误[8，16，31]。 为了找到这些bug，我们可以使用传统的bug查找技术，例如静态或动态测试。特别是模糊化在过去几年中受到了学术界和工业界的广泛关注[2，4，19，23，47，65]。从本质上讲，模糊框架以自动化的方式生成数十亿个（随机）测试用例，并将它们用作测试程序的输入，期望引起不同的行为。理想情况下，这样一个随机化的测试用例会触发JIT引擎优化过程中不可预见的边缘用例，从而识别新的bug。然而，通过传统的测试方法模糊JS引擎在实践中证明是无效的：JS代码是高度结构化的，并且，为了进行有意义的JS执行，所提供的JS代码需要高度的语法和语义正确性。因此，常见的字节级模糊器，如AFL [65]及其许多变体（例如，例如，在一个实施例中，[3，6，14]）无法生成有效的JS测试用例或有效地改变现有的测试用例。因此，开发了通用的基于语法的模糊器来帮助提高JS输入生成的质量[23，60]。在此之后，已经提出了特定的输入生成技术，以语法感知和语义感知格式表示有效的JS代码，例如。例如，在一个实施例中，在中间表示[9，19]或抽象语法树（AST）[2，47]中。这些表示允许模糊器产生高质量的测试用例，从而实现高度的代码覆盖。因此，这些技术已被证明是有效的，在实践中发现复杂的软件故障。为了检测产生的输入是否触发了bug，模糊器观察被测程序是否达到了错误状态。 一般来说，当前的JS引擎模糊器依赖于以下错误预言-指示错误程序行为的机制-来检测错误：分段故障和信号。如果引擎违反了CPU的执行模型，例如未映射的内存访问、除以零或类似的非法行为，则会检测到故障状态。记忆安全消毒剂 诸如ASAN或MSAN [50，52，53]之类的清理程序是使用编译时插装来检测软件错误的方法，例如未初始化的内存，释放后使用条件和类似的内存安全违规。消毒器还可以检测软件故障，··CCSLukas Bernhard、Tobias Scharnowski、Moritz Schloegel、Tim Blazytko和ThorstenHolz354publicvoid run（n）{2N |= 0;publicint findDuplicate（

下载后可阅读完整内容，剩余1页未读，立即下载