在互联互通和自动化的时代，汽车行业正在采用大量技术，将以驾驶员为中心的车辆转变为由软件组件驱动的智能机械设备。软件集成和网络连接继承了许多安全问题，为恶意攻击打开了大门。软件安全测试是一种可扩展和实用的方法，可以在早期阶段和整个生命周期确定系统的弱点和漏洞。安全专家建议进行模糊测试，以确定车辆软件系统内的漏洞。然而，模糊分析的随机性和盲目性阻碍了它成为可靠的安全工具。本文介绍了一个面向漏洞的fuzz(VulFuzz)测试框架，该框架利用专门为联网和自动驾驶汽车设计的安全漏洞标准，指导并优先考虑最脆弱的组件进行fuzz测试。虽然大多数灰盒模糊技术的目的只是为了扩大代码覆盖面，但所提出的方法分配了权重，以确保对最脆弱的组件进行彻底检查。此外，我们采用了一种输入结构感知突变技术，可以绕过车辆软件系统的输入格式，以提高测试性能并避免测试用例丢失。这样的测试技术将有助于提高车辆软件工程的质量保证。我们在OpenPilot（一个驾驶辅助系统）上实施了所提出的方法，并将我们的结果与American fuzzy lop（AFL）和一个非指导性的基于突变的模糊器进行了比较。在16.8小时内，VulFuzz暴露了335个崩溃，是AFL的41倍，是非引导突变fuzzer的两倍。VulFuzz对于汽车系统来说非常有效，它可以达到与AFL相同的代码覆盖率，但是暴露的崩溃更多，丢失的消息更少。
汽车行业正面临着众多的安全挑战。保护驾驶员不再局限于为车辆配备安全带和安全气囊，而是扩大到实施适当的安全和安保措施，以保护车辆免受恶意网络攻击。
技术和网络连接的快速发展已经改变了汽车的形状。现代汽车不仅仅是仅由人类控制和驱动的机械装置。它们是联网的自动驾驶汽车（CAVs），将基础设施和计算机处理与先进的无线通信相结合，以做出决策，为司机和乘客提供更安全、更有趣的体验。
当原始设备制造商（OEMs）朝着自动驾驶和驾驶辅助的方向继续竞争时，攻击者控制车辆的机会也在增加[1]。软件集成和连接使车辆成为智能设备。然而，这为软件缺陷和漏洞打开了窗口，吸引了恶意的行为。事实上，与完全手动、断开连接的车辆或完全自动驾驶车辆相比，同时具有人类驾驶员和自动驾驶或驾驶员辅助功能的车辆具有最大的攻击面，因此具有最大的风险。互联网曝光带来了大量的漏洞，为攻击者的工作提供了便利。黑客在车辆领域的威胁并不限于只利用个人数据的漏洞；他们可以通过改变车辆的软件系统来扩大风险。目前有许多针对不同汽车制造商发起的车辆攻击报道[2]。因此，原始设备制造商正在努力加强他们的安全措施，以提高车辆对网络攻击的抵御能力。
由于现代汽车开发依赖于软件，确保开发生命周期的安全对于为消费者提供更好的体验至关重要。不同的标准，如汽车开放系统架构（AUTOSAR）[3]、J3061[4]和ISO 26262[5]强调了在车辆软件工程（VSE）的所有阶段部署安全措施的重要性[6]。由于开发安全的汽车软件系统的需求比以往任何时候都高，国际标准化组织（ISO）[7]与汽车工程师协会（SAE）[8]合作，设计了一个标准，即ISO/SAE 21434[9]，明确针对安全开发。该标准旨在帮助原始设备制造商在整个车辆工程生命周期内解决网络安全问题。
在车辆发布之前，安全工程师需要验证系统的安全性，以避免灾难性的事件。车辆行业缺乏质量保证和测试程序是导致漏洞存在的主要因素之一[10]。
显然，安全测试是VSE的一个关键阶段，以确定漏洞和系统的弱点。在车辆行业中使用了不同的安全保障方法，包括静态代码分析、动态程序分析、漏洞扫描、渗透测试和模糊测试[11]。这些安全测试技术减少了系统中的漏洞。
不管怎么说，车辆软件系统的安全测试是一项复杂的任务，给OEM厂商留下了多重挑战[6]。汽车软件系统是一个复杂的系统，大约有一亿行代码驻留并运行在几十个电子控制单元（ECU）上[12]。这些ECU根据来自雷达、激光雷达、摄像机、超声波传感器、温度传感器、轮胎压力传感器和许多其他传感器的输入进行操作。由于车辆在一个不断发展的环境中运行，ECU的输入变化很大。因此，要预测ECU的所有可能的输入组合是很困难的。
一些研究人员[10]，[13]-[16]认为模糊测试是发现车辆软件系统内漏洞的最合适工具之一。然而，目前只有少数文献介绍了专门为汽车行业[10]、[14]、[15]、[17]设计的模糊测试工具。该领域的研究工作仅限于评估和研究黑盒模糊测试对CAV的适用性[18]-[21]。然而，在汽车系统中采用这样的测试方法并不是一个可靠的解决方案。黑盒随机模糊不能提供测试组件的完整图像。因此，汽车行业需要一个软件安全测试解决方案，该解决方案可以促进测试过程，模拟车辆环境，并锁定漏洞。
我们的研究旨在满足这些要求，为汽车行业提供安全保障，减轻安全工程师的工作负担。这一目标是通过设计一个创新的灰盒模糊测试框架来实现的，该框架优化了漏洞暴露过程，同时解决了汽车行业的安全测试挑战。灰盒模糊测试是一种强大的安全机制，在不增加测试复杂性的情况下积累系统信息，实现快速有效的安全测试。
本文提出了一个面向漏洞的模糊测试（VulFuzz）框架，该框架系统地将测试的重点放在车辆软件系统的较弱组件上。该框架利用安全漏洞度量，旨在识别车辆软件系统中的脆弱组件，并通过分配权重确保对这些组件进行彻底测试。此外，为了说明自主系统强大的输入验证，我们引入了一个突变引擎，在输入的高层设计中进行小数据类型的突变。我们通过将VulFuzz应用于一个汽车子系统来评估其识别意外行为的有效性。我们还回顾了汽车工业中软件安全测试的挑战，并强调了汽车软件系统灰盒安全测试的局限性和好处。
我们在这篇文章中的主要贡献总结如下：
我们为汽车行业提供了一个模糊测试工具，该工具可以高效、可靠地管理VSE的许多测试挑战。所提出的灰盒模糊测试框架通过对系统进行知识性验证，击败了汽车行业中常见的盲目黑盒模糊器。
我们在开发阶段通过确保对车辆软件系统的脆弱组件进行全面测试来扩展漏洞识别。因此，我们加强了车辆对不可预测的网络攻击的抵御能力。
我们将优先级引入灰盒模糊测试，以有效地管理复杂和大型车辆软件系统的评估。我们将测试的优先级首先放在漏洞探索上，然后扩大覆盖范围。
我们提出了一种突变技术，保留了车辆系统的输入格式，通过减少丢失的模糊信息来提高灰盒模糊的性能。
我们在暴露汽车系统漏洞方面的表现优于其他两种模糊测试技术，证明了VulFuzz的有效性和可扩展性。
文章的其余部分组织如下：
第二节概述了汽车行业的安全测试挑战。第三节回顾了相关工作，并提供了关于汽车行业内采用的不同安全保证方法的背景知识。第四节介绍了VulFuzz框架并解释了拟议方法的细节。第五节讨论了评估设置和结果。最后，第六节是本文的结论。
安全测试是一个强大的机制，可以检测和识别系统的漏洞。在像车辆软件系统这样的关键系统中，软件测试可以防止危及生命的事件。然而，许多挑战使得安全测试在汽车行业成为一项复杂的任务。本节总结了这些挑战。
系统的复杂性和规模。汽车软件系统包括不同的功能，如安全相关的功能、基础设施软件和多媒体系统[6],[22]。CAV必须执行的大量操作增加了代码的源行数（SLOC）和所需的硬件设备。车辆软件系统被认为是现有最大的软件系统之一[23]。安全工程师需要确保系统的稳定运行，然而由于系统的规模比较大，这项工作变得很耗时。使安全工程师的工作更具挑战性的是系统的复杂性。汽车软件系统的异构功能采用了各种先进技术，如传感器、电子控制单元、网络连接、人工智能、数据分析等。研究表明，复杂的代码在设计和开发上具有挑战性，增加了漏洞和安全问题[24]-[26]。安全工程师必须管理代码的复杂性和规模，以验证安全性并确保系统在整个运行周期内保持安全。
外包：嵌入在车辆软件系统中的异质功能的开发需要不同的专业知识和技能。
因此，原始设备制造商倾向于将大量的车辆功能外包[27]。虽然这可能会提高产品质量，但外包使安全工程师的工作更加复杂。第三方开发的软件会给系统带来新的威胁和漏洞[28]。由于层次分明且往往复杂的供应链，这一点变得更加困难。安全工程师必须在不知道其底层开发细节或全部出处的情况下处理组件并认证其安全性和可靠性。此外，安全测试和系统故障率应适用于整个系统。由于车辆软件系统中的许多功能相互依赖，这个过程可能会被推迟，直到所有的组件被完全集成，大大减少了可用的测试和分析时间。
输入和输出的波动：CAVs根据周围环境做出合理的决定，将乘客安全送到目的地。它们利用传感器、雷达、激光雷达、照相机、其他车辆和外部系统来收集所需信息，以了解道路状况、天气状况和周围的交通情况[29]。评估所有可能的外部环境数据集是一个难以解决的问题。因此，测试和验证车辆软件系统的行为是一项具有挑战性的任务。除了外部数据，ECU还交换内部数据以触发特定的事件。例如，动力总成控制模块（PCM）控制推动车辆所需的燃料消耗。PCM依靠不同的输入来确定正确的混合比，包括发动机温度、空气温度和节气门位置。在现代汽车中，PCM还接收来自自适应巡航控制（ACC）ECU的内部信息，以控制速度。安全工程师必须验证系统的灾难性故障率落在可接受的范围内，这需要数小时的密集测试，应涵盖大量的可能性[30]。
测试台的复杂性：测试条件会大大影响结果的准确性。系统的安全保证和验证应该在与真实世界场景相同的条件下进行。考虑到车辆软件系统的结构和错综复杂的架构，模拟真实环境成为一项昂贵和耗时的工作[31]。车辆在各种不同的情况下运行，包括不同的道路、速度、视野、密度、通信模式和司机。模仿一个场景可能不足以确保系统的安全和可靠。许多工业解决方案为原始设备制造商提供软件在环（SiL）和硬件在环（HIL）测试模拟器，模仿真实环境来评估车辆软件系统[32], [33]。然而，一些局限性阻碍了模拟器成为能够替代真实世界测试的自主车辆的完整解决方案。模拟器容易出错，可能无法全面模拟所有的真实世界场景[34]。
III.背景和相关工作
在汽车行业中，安全和保障是紧密相关的学科。车辆软件系统中的任何安全漏洞都会对车辆的安全产生巨大的影响，这使得网络安全保证成为VSE中不可或缺的工作。
在安全验证和确认阶段，安全工程师必须保证车辆系统的开发和设计符合车辆标准的网络安全要求，如AUTOSAR、ISO 26262和ISO/SAE 21434标准。这包括计划、报告，以及最重要的是一系列的安全测试，以验证车辆软件系统的保护机制。由于车辆系统融合了各种先进技术，包括不同的通信手段和硬件设备，要确保系统在整个生命周期内的安全，就需要采用多种安全测试技术。一些测试技术被自动地纳入开发过程，以便及时发现潜在的弱点，而其他技术则需要人为干预，并在开发阶段后进行验收测试[11]。本节提供了关于车辆行业最常见的安全保障方法的背景知识，这些方法相互补充：静态代码分析、动态代码分析、漏洞扫描、渗透测试和模糊测试。我们更彻底地讨论模糊测试及其管理安全测试挑战的能力，因为它是拟议框架的核心。在本节的最后，我们简要回顾了验证操作系统和软件应用安全的现有灰盒模糊测试技术。
A. 静态代码分析
由ISO 26262[5]和许多其他标准推荐，静态代码分析是一种白盒测试方法，动态和自动分析车辆系统的源代码，以识别可能使系统受到攻击的编程错误[35]。Imparato等人[36]研究了现有的静态分析工具在识别汽车软件组件的漏洞方面的潜力。他们的研究表明，Bug Finder[37]和Polyspace Code Prover[38]只能识别出不符合安全和保障标准的部分代码，即使这些工具在其他系统中具有很高的性能。质量加速（QA）[39]在识别不符合汽车工业软件可靠性协会制定的MISRA编码标准的软件缺陷方面表现更好[40]。Keul[41]强调了识别汽车软件组件中多线程组件的竞赛条件的重要性。作者提出了一个静态竞赛条件代码分析器，并展示了它在检测严重缺陷方面的潜力。
静态代码分析工具可以在开发阶段早期快速运行，以确定削弱系统的各种代码缺陷。它们通常被认为是值得的，特别是在MISRA的遵守方面。然而，这些扫描器的能力是有限的。它们通常会产生大量的假阳性结果[42]。静态代码分析器不能发现那些在源代码中没有被很好理解和建模的漏洞（例如，未检查的输入和边界），因此需要额外的工具。
B. 动态程序分析
动态程序分析检查和监控程序的执行，以确定不正确的行为。
它涵盖了所有典型的软件测试形式，包括单元、组件、集成和系统测试。从安全角度来看，它被用来寻找危险的条件，如内存错误、并发错误和崩溃。Celik等人[43]采用程序分析技术来识别汽车系统等物联网（IoT）系统中的安全和隐私问题。在他们的研究中，研究人员展示了动态程序分析在发现用其他技术无法识别的漏洞方面的力量。Koscher[44]强调了驻留在汽车系统中的漏洞的严重性，并强调了动态程序分析在快速和容易地识别汽车漏洞方面的适用性。研究人员提出了一个动态分析工具，可以近乎实时地模拟嵌入式ECU的输入和输出。Cabodi等人[45]提出了一个用于汽车系统安全测试的动态程序分析工具，该工具监测和分析CAN消息路由和排序，以识别不稳定行为。他们对一个网关ECU的案例研究显示了该工具在最小化工作量和识别异常反应方面的有效性。
尽管动态程序分析可以暴露出静态代码分析无法触发的漏洞，但它只能涵盖已知的软件问题。动态程序分析针对预先设定的场景运行，限制了测试的范围。
C. 漏洞扫描
漏洞扫描验证了车辆软件系统对已知漏洞和安全漏洞的恢复能力。换句话说，这样的安全保证方法可以检测到不完全可追溯的开发错误，但这些错误可以被利用来生成攻击。漏洞扫描需要以前对车辆行业的攻击和安全问题的了解。2015年，业内领先的先驱者成立了汽车信息共享和分析中心（AUTO-ISAC）[46]，在全球范围内收集和分析汽车行业内的新兴网络安全风险。AUTO-ISAC为原始设备制造商提供了30多家汽车制造商确定的漏洞信息，从而能够更快地发现漏洞并分担责任。除了工业力量来改进漏洞扫描，研究人员还通过巩固现有的攻击来促进这一过程。Ring et al.[47]建立了一个已发现漏洞的数据库，以便在安全验证和验证阶段进行访问。同样，Sommer等人[48]对汽车安全攻击进行研究和分类，以丰富VSE的安全测试阶段。
毫无疑问，漏洞扫描对于避免重复攻击至关重要，包括在渗透测试期间发现的攻击，并且也可以在开发周期的早期应用。然而，这样的安全测试工具并不能全面地评估汽车系统。各方开发的系统有不同的弱点，漏洞扫描无法识别。因此，扫描必须不断为每个特定的系统量身定做，并且需要额外的测试工具。
D. 渗透测试
为了验证车辆软件系统对恶意行为的恢复能力，安全工程师戴上白帽子，试图渗透到系统中。渗透测试是车辆行业中研究最多的测试技术[35]。Koscher等人[49]通过进行几种物理和远程攻击对车辆的安全性进行了实验。通过模拟重放攻击，研究人员可以绕过车辆内的基本网络安全保护措施。Cheahetal. [50] 采用渗透测试来评估车辆蓝牙接口的安全性。
其他研究人员利用渗透测试来评估车内通信安全。Corbett等人[51]介绍了一个测试框架，试图绕过车内网络入侵检测系统。Taylor等人[52]设计了一个适用于CAN总线的异常检测框架。研究人员研究了以前成功的攻击，以确定共同特征，并模拟了一系列新的攻击。Huang等人[53]通过提出一个自动向CAN总线注入攻击数据包的工具，验证了CAN防御机制。
研究人员通过进行渗透测试确定了车辆内部的一些漏洞，这种方法是验证车辆网络安全的最有效方法。虽然渗透测试会产生最重要和最有意义的结果，但它通常是最耗时的，从定义上讲是不完整的，并且需要深厚的领域专业知识。在VSE中，已知攻击的自动化始终是功能渗透测试策略的一个重要方面。通过渗透测试，可以很好地覆盖众所周知的问题和攻击，以及最可能的和重要的攻击。然而，仅仅通过渗透测试来保证车载软件系统的弹性是不够的。
E. 模糊测试
模糊测试是一种稳健的测试技术，针对任意输入验证系统行为，以识别攻击者可以用来发起攻击的意外行为[54]。可以采用三种不同的测试方法：白盒、黑盒和灰盒模糊测试。
车辆行业的研究人员专注于黑盒模糊测试，避免采用白盒模糊测试。虽然白盒测试可以全面评估系统，但考虑到系统的复杂性和规模，在汽车行业部署这样的机制是很耗时的，需要付出巨大的努力。此外，由于车辆软件系统的许多组件都是外包的，在所有组件上应用白盒测试目前是不现实的。
Oka等人[18]认为黑盒模糊测试是发现车辆软件系统内漏洞的最有力工具之一。他们通过对发动机ECU和网关ECU进行模糊测试来展示其效率。研究人员通过监测发动机ECU对模糊和随机消息的响应，成功地识别了损坏的脉宽调制(PWM)频率。
在其他研究工作中，Oka等人[55]强调了验证和测试像车辆软件系统这样复杂而广泛的系统的挑战。
在系统完成后启动测试会导致车辆生产的延迟。Oka等人发现，模糊测试允许在开发过程的早期阶段开始测试。随机输入可以取代验证开发功能所需的输入。
Fowler等人[19]-[21]提出略微修改有效的控制器区域网络（CAN）信息以识别ECU的安全问题。他们在车辆的显示ECU上执行黑箱模糊，并展示了模糊汽车输入的好处，以识别车辆软件系统中的漏洞和弱点。Patki等人[56]提出了联合诊断服务模糊器，它使用有效的输入信息，并对特定的字段进行突变，以生成无效的输入。
尽管黑盒模糊测试能够管理系统的复杂性、外包以及输入和输出波动挑战，但对关键系统进行盲测试可能是有风险的。黑盒测试不能保证系统的良好覆盖和全面评估。此外，任意的测试用例可能无法通过初始输入验证需求，从而阻止测试扩展到系统的核心。这在VSE中是具有挑战性的，因为在VSE中，强大的输入验证是一个核心要求，而且通常是通过静态分析来验证的。在汽车行业采用这样的测试方法可能无法确保无风险的寿命。
为了克服黑箱模糊的限制，Radu和Garcia[57]使用静态分析来管理汽车ECU的模糊。他们介绍了EffCAN，这是一个通过CAN信息对ECU固件进行模糊处理的工具，当源代码不可用时，它是最有效的。EffCAN要求拆解ECU固件，以建立控制流图，帮助指导模糊测试。然而，反汇编ECU固件是一项具有挑战性的工作。将硬件特定的驱动程序和代码区域从软件组件中分离出来是一项艰巨的任务，需要人工分析。因此，安全测试人员需要对底层ECU硬件架构有扎实的了解。
本文旨在通过采用对系统更了解的高效灰盒模糊测试技术，弥补黑盒模糊测试的局限性。灰盒模糊测试提供了一个更有针对性和更有效的评估，无需分析每一行代码。灰盒测试与白盒测试不同，白盒测试需要进行密集的代码分析和约束解算，而灰盒测试则不会造成高额的开销。同时，灰盒模糊法克服了黑盒模糊法的随机性，同时产生了大量的测试案例。因此，灰盒方法解决了三个测试难题：通过避免密集的代码分析来解决系统的复杂性和规模，通过限制对系统的了解来解决外包问题，通过创建大量的输入来解决输入和输出的波动。
F. 其他灰盒模糊测试技术
最近，灰盒模糊测试已经成为一种流行的安全测试工具[58]。最著名的灰盒模糊测试技术是美国模糊罗普（AFL）[59]，我们在评估部分与之进行了比较。AFL收集覆盖率信息，以确定扩大代码覆盖率的测试案例。
为了提高AFL的覆盖率和性能，引入了各种策略[60]-[62]。然而，这些技术都没有被应用于验证汽车部件的安全性。研究人员将他们的方法设计为针对基于桌面的程序。这种灰盒模糊技术并不针对CAV的安全测试挑战，特别是系统的复杂性和规模。他们花费数小时进行测试，完全专注于扩大代码覆盖率。在严格的时间预算和复杂的系统下，测试最好集中在可能使系统受到攻击的薄弱部分。
Zhang和Zhou[63]试图对AFL生成的种子进行排序，但他们的测试用例优先级并没有指导测试的具体方向。Marinescu和Cadar[64]提出了一种测试工具KATCH，旨在自动验证软件补丁。KATCH使用一个带有多个补丁感知启发式的符号引擎来查找执行已更改语句的输入。尽管KATCH暴露了与新的代码修改有关的错误，但它对于像汽车软件系统这样的大型复杂系统来说是不适用的。符号执行详尽地探索了多条路径，并收集了可以被否定的分支条件，并由可满足性理论求解器满足，以产生新的输入。这种重量级的代码分析造成了内存管理的开销，并对效率构成了巨大的障碍。
与基于符号执行的模糊器不同，定向灰盒模糊器造成的开销较少。Böhmeetal. [62]介绍了定向灰盒模糊测试（DGF），它侧重于测试由用户指定的目标。他们在AFL的基础上实施他们的方法，并将其命名为AFLGo。他们通过消除离目标较远的测试案例来实现其目标。他们计算系统节点之间的最小距离来识别接近的种子。最小距离形成了一个重要的限制，因为它消除了系统中可能存在错误的关键路径。DGF取决于对脆弱地区的事先了解，这种了解可以在威胁和风险评估的指导下进行，但不可能是完整的。此外，在测试一个新开发的系统时，有必要检查整个系统，而不仅仅是特定的功能。VulFuzz能有效地、全面地对易受攻击的组件进行优先测试。与需要手动指定目标的AFLGo相比，VulFuzz利用安全漏洞指标自动识别脆弱组件。VulFuzz考虑了所有可能导致弱点的路径，在确保完整的系统测试的同时，不把测试过程限制在特定的路径上。
IV.车辆灰盒测试框架
车辆软件系统是复杂的软件系统，依靠众多技术来运行并提供智能功能。灰盒模糊测试可以使用一组广泛的输入组合来评估软件组件的安全性。我们提出了一个VulFuzz测试框架，用许多有效的输入来验证车辆软件系统的安全性，力求彻底检查其脆弱的组件。该框架通过利用针对车辆软件系统独特挑战的安全漏洞指标，将测试引向系统最脆弱或薄弱的部分。
图1. 面向漏洞的模糊测试框架。(a) 框架步骤。(b) 框架引擎（每个引擎的自动化步骤都列在括号内）。
VulFuzz采用漏洞度量来自动识别系统的弱点或脆弱功能1，并根据度量值分配一个权重（w）。漏洞得分越高，函数的安全性就越脆弱，因此w的值也越高。该框架对弱函数给予了高度优先级，并对它们进行了深入的检查。与其他灰盒技术不同，VulFuzz不仅关心覆盖范围，还关心弱函数被遍历的次数。分配给函数的权重确定了测试的门槛。该框架被赋予一个良好的输入样本，以产生一系列有效的测试案例。VulFuzz运行每个测试用例以监视它是否遍历一个加权函数或是否与一个加权函数有连接。
这样的测试用例允许验证脆弱的功能，所以它们被转移到一个高优先级的队列中，以创建更多的测试用例。相比之下，对不包括脆弱功能的测试用例的关注较少。
图1所示为框架。图1(a)显示了框架步骤，由图1(b)所示的四个引擎自动化:脆弱性引擎、突变引擎、评估引擎和优先级引擎。每个引擎在完成VulFuzz的步骤中都起着至关重要的作用。漏洞引擎测量功能的漏洞值。突变引擎生成一系列有效输入来检查系统。评估引擎评估测试用例的有用性。最后，优先级排序引擎对易受攻击的组件进行优先级排序。本节首先概述框架步骤，然后深入研究VulFuzz的引擎。
A. 框架步骤
框架步骤如图1(a)所示，具体如下。模糊例程(步骤①、②和③)的准备工作在编译时运行，以最小化安全测试阶段的开销。① 首先，该框架首先利用系统的源代码计算每个函数的安全漏洞值，并为有漏洞的函数分配权重。② 然后，生成系统的调用图。③ 使用样本输入，框架建立了一个字典来识别输入格式。这些样本被移到高优先级队列中以启动测试。
其余的步骤(④至⑨)可以结合在模糊程序中，如算法1所描述的。该程序是在安全测试阶段启动的。④ 该框架首先从高优先级队列中选择一个种子输入。如果高优先级队列是空的，那么低优先级队列被激活。如果两个队列都是空的，那么这个过程就终止了。⑤下一步，选定的种子被改变，程序以新的输入执行。⑥ 框架根据种子执行情况更新覆盖率表和加权函数的调用计数。根据结果，该框架对测试进行优先排序。⑦如果测试用例遍历了一个调用次数少于指定权重的脆弱函数，它就会将变异的输入添加到高优先级队列。⑧如果不满足高优先级队列的要求，但发现了新的分支，面向漏洞的模糊测试框架就会把变异的输入加入到低优先级队列中。⑨ 如果两个队列的条件都不满足，则输入被丢弃。如果VulFuzz不能找到更多的输入来评估易受攻击的函数或扩大覆盖范围，模糊处理程序就会停止。如果VulFuzz根据分配的权重检查易受攻击的函数并达到最大覆盖率，它也会终止。
B. 框架引擎
本小节详细讨论了图1(b)的灰盒模糊测试框架引擎，强调了每个引擎在安全测试框架中的作用。
漏洞识别。漏洞引擎在编译期间运行，将汽车系统的源代码作为输入，并自动测量漏洞分数，以识别构成高风险的功能。如[65]所述，每个组件的脆弱性得分是根据明确设计的安全参数（指标）计算的，以确定车辆软件系统的脆弱性。为了根据组件的脆弱性得分对其进行优先排序，我们将（1）中的每个参数除以所有组件中同一参数的最大值。S是汽车系统所有部件的集合，i是S中的一个部件。α、β、γ、δ和θ是重要性参数。
ECU耦合风险（ECR）衡量ECU的耦合所带来的风险，它可以允许恶意信息从系统中的一个脆弱组件传播到另一个。ECRi是通过计算部件i中与系统中其他ECU耦合的ECU数量来确定的。CAVs利用不同的通信手段，暴露出不同类型的威胁[66]。CRi是组件i的通信风险（CR），它是通过识别组件采用的通信手段集来计算的。CXRi，即组件i的复杂性风险（CXR），被定义为SLOC和嵌套复杂性的组合。DRi是组件i的输入和输出风险(DR)。DR衡量与波动输入和输出相关的风险，如果没有很好的测试，可能成为攻击者突破系统的窗口。DRi是通过确定组件i的浮动输入、固定输入、浮动输出和固定输出的集合来评估的。以前有助于攻击成功的组件需要被重新评估和测试，以保证适当的安全。HISTi，组件i的安全问题历史（HIST），通过计算影响组件i的攻击来计算。HIST还利用遗忘因子对尚未解决的近期攻击给予更大的重视。
彻底测试高风险实体以在早期阶段暴露系统的故障是至关重要的。现有的灰盒测试技术只致力于扩大代码覆盖率，而不对弱系统实体进行区分。然而，多次检查某些函数是很有必要的。例如，考虑清单1中提出的脚本；如果x被赋予一个大于0的值，这个脚本就能正常运行。然而，当x的值为0时，这个脚本会引发一个异常。因此，覆盖率不够高，不足以暴露系统中的一些缺陷。
同时，在一个特定的时间范围内对系统的所有实体进行多次测试是不可行的。
这些安全指标指导我们对那些需要特殊处理和密集测试的完整组件进行标注，以便在早期阶段最大限度地披露错误。总体安全脆弱性指标的值越高，它可能带来的风险就越大。根据一个函数的安全脆弱性，分配一个权重w，代表一个函数应该被测试的次数。不易受攻击的函数被分配为零权重（w = 0）。
调用图构建:漏洞引擎在编译时创建调用图，因为评估引擎需要将测试导向漏洞功能。一个组件（C）的调用图（CG）有一个节点集（N），代表CG中的总节点数。CG中的每个节点代表一个函数，两个节点之间的有向边(n→n，)展示了从函数n到函数n，的穿越的可能性。
2) 突变引擎：突变引擎的目标是生成通过汽车部件验证标准的种子输入，以扩大代码覆盖率。汽车部件通过汽车以太网、CAN或Flexray总线进行通信。完全随机的通信信息突变往往在数据验证步骤中失败，使代码的关键部分没有得到任何验证。最先进的模糊器AFL的突变引擎对好的输入进行小比特级的突变，以产生一系列的种子输入。它是为紧凑的数据格式设计的，例如，多媒体文件、图像和压缩数据[59]。当应用于像车辆软件系统这样的格式特定的系统时，位级突变会有一些关键的限制[60]。虽然比特级突变带来的微小变化几乎不影响输入，但突变会毁掉输入结构。此外，位级突变未能保留输入数据类型。为了克服这些挑战，Vul- Fuzz突变引擎采用了一种输入结构感知的突变方法，由三个主要部分组成：1）输入格式；2）基于数据类型的突变；3）基于交叉的突变。在开始模糊例程之前，输入格式是确定的。然后，VulFuzz将种子输入传递给突变引擎，以执行基于数据类型的突变。在使用基于数据类型的突变完成模糊化过程之后，突变引擎切换到基于交叉的突变，以找到好的测试用例并扩大代码覆盖率。
输入格式：一些解决方案被提出来，以减少丢弃的信息，并使突变结构感知，包括基于污点的突变、输入解析器和字典[67]。基于污点的模糊器需要大量的代码分析，增加了测试的开销[68]。灰盒模糊器采用的输入解析器被用来识别输入结构，引导突变到数据块并保留重要的文件头。
然而，这些输入解析器在媒体文件、视频文件和网络文件上效果最好[60]。在面向漏洞的变异引擎中，我们利用字典来保存输入格式。词典是一种稳健的技术，广泛用于向模糊器提供关于输入的信息，提高模糊处理的效率[59]，[69]。面向漏洞的字典标记了文件头和重要字段，以防止输入丢失。
基于数据类型的突变：在识别输入格式后，突变引擎试图自动识别数据字段类型。这一步需要进行基于数据类型的突变，这有助于种子输入通过初始验证步骤并探索系统。这种变异技术比随机变异引发更多的错误，因为它巧妙地保留了信息的结构，同时用不同的输入范围来验证系统[70]。
对于每个种子的输入，突变引擎对一个字段进行一次突变操作。我们进行小规模的突变，因为我们需要保持种子的大多数内容，帮助探索系统和测试脆弱的组件。变异引擎首先尝试将需要变异的字段解析为数据类型，如数字、布尔和字符串。根据数据类型，可以进行一系列的操作。对于数字数据，突变引擎被设计为随机选择以下数学运算之一：减法、乘法、除法和加法。对于一个给定的数字字段F，一个任意的数字字段A被生成，以随机地应用其中的一个数学运算。变异引擎将布尔数据变异为真或假。对于字符串，我们执行单比特随机删除、插入或翻转。如果突变引擎不能识别数据字段类型，它将执行经典的随机单比特突变[59]。此外，为了测试系统的输入验证程序，变异引擎对不同数据类型的字段进行变异（例如，数字字段被变异为字符串）。然而，这种验证只对每个字段进行一次，以避免验证过程的停止，并对系统进行探索。
交叉变异: 在遗传算法的启发下，一些灰盒模糊器使用这种类型的变异[59], [60], [71]。我们静态地交换不同种子的小块，以保持输入结构。考虑到这些情况，我们随机选择一个部分p，其中p1和p2是这个部分的开始和结束索引。使用相同的索引，另一部分p，从一个随机的种子s，被切开。然后，部分p被放在s，中p的位置，p，被放在s中p的位置，产生两个新的种子。我们明确地保留被交换部分的位置，以保持种子的格式。
3) 评估引擎:VulFuzz以易受攻击的组件和覆盖面的扩大为导向。评估引擎通过监测种子投入的性能来帮助实现这一目标。受AFL的启发，对于每个种子输入，评估引擎记录遍历的优势。它利用轻量级的仪器来检测分支覆盖率。 与语句覆盖相比，分支覆盖对执行路径的洞察力要大得多。它可以识别简单语句覆盖率无法识别的条件语句的分支[72]。覆盖率有助于模糊器了解模糊处理的进展，并确定种子输入的有用性。
图2.一个显示通往脆弱函数的路径的调用图示例。
为了成功地将模糊器引向易受攻击的组件，评估引擎检测穿越或具有通往易受攻击功能的种子输入。评估引擎使用由漏洞引擎创建的加权函数，识别出脆弱的函数，并监控穿越这些函数的测试案例。VulFuzz高度重视脆弱功能，并努力彻底验证其安全性。因此，即使种子输入没有遍历易受攻击的函数，评估引擎也会检查该种子输入最终是否能够到达易受攻击的组件。遍历连接到易受攻击函数的节点的输入有机会通过轻微的突变到达它们。漏洞引擎产生的调用图被用来确定一个被执行的输入是否有一个可以到达漏洞函数的路径，不包括系统入口点。考虑到图2的调用图，其中有一个脆弱的函数n7，一个种子输入只有在穿越节点n3或n6时才有路径到n7。例如，考虑一个种子输入s1，它穿过节点n1、n2和n4。种子s1不太可能到达节点7。因此，它被标记为不适合用于测试脆弱功能。
4)优先级引擎：在像车辆软件系统这样复杂的大型系统中，测试用例的优先级在测试和验证阶段是至关重要的。在有限的时间预算下，系统的脆弱性正在增加。现有的灰盒模糊技术不区分测试案例；它们都在同一个队列中，以先来后到（FIFO）的方式执行。相反，VulFuzz根据发现的情况对测试案例进行优先排序；触发脆弱功能的种子被赋予更高的优先权。该引擎分析由评估引擎产生的覆盖率表和加权函数计数，以确定种子输入是否应被添加到高优先级队列、低优先级队列或被忽略掉。可以利用两个以上的队列来针对多个阈值的功能。
正如在脆弱性引擎中所讨论的那样，每个被识别的脆弱功能都被分配了一个权重（w），以彻底测试脆弱功能。探索或有通往脆弱组件的路径的测试用例，其数量小于分配的权重，是非常必要的，因此被添加到高优先级队列中。如果测试用例不执行，或者没有通往易受攻击的函数的路径，但是扩展了代码覆盖范围(发现了至少一个之前没有发现的新分支)，则被认为是低优先级的，并被移动到低优先级队列中。最后，不探索新分支和不执行易受攻击的函数的测试用例不会添加到任何队列中。
加入队列的种子输入被赋予能量值，以进一步变异并作为模糊处理程序中的新输入。一个能量值代表一个种子输入应该被变异的次数。优先级引擎采用恒定的能量分配，同时给探索脆弱功能的种子以更多的能量。遍历脆弱函数的高优先级种子输入被赋予三倍于低优先级种子输入的能量，使其能够产生更多的输入，为探索脆弱函数提供更好的机会。属于高优先级队列的种子，但没有穿越易受攻击的函数，被分配的能量是低优先级种子的两倍。这样的测试用例有很高的机会穿越易受攻击的函数，但它们可能永远无法到达这些函数。
例如，考虑图2，有一个脆弱的节点n7，其执行数小于其权重。一个穿越n7的种子s被分配一个3x的能量值，其中x是一个由安全工程师定义的常数。一个执行节点n1和节点n3的种子s，被赋予一个能量值2x。因此，为了节省对弱函数的模糊处理能力，与s，类似的测试用例被分配的能量值比与s类似的测试用例少，以保证脆弱性的探索。另一方面，属于低优先级队列的测试案例被分配较低的能量值。一个首次发现边n1→n2的种子（seed）s,,被分配了一个x的能量值。
V.实施和评估
为了评估VulFuzz的有效性和性能，我们实现了该框架并将其应用于一个汽车系统OpenPilot。本节介绍了评估设置，分析了所获得的结果，并将其与其他两种模糊方法进行了比较：AFL和基于突变的模糊器。本节还包括对VulFuzz的四个引擎的消融研究。
A. 评估设置
我们在OpenPilot（0.7.8版）[73]上实现该框架并评估其性能。OpenPilot是一个由comma.ai开发的开源、驾驶和安全助理系统[74]。它提供SAE 2级驾驶辅助能力，满足自适应巡航控制（ACC）、自动车道居中（ALC）、前方碰撞警告（FCW）和车道偏离警告（LDW）的功能。它支持各种汽车型号，包括本田、丰田、现代和雷克萨斯。该汽车系统还通过实施驾驶员监控（DM）功能提供安全功能，对注意力不集中的驾驶员发出警告。
这样的安全关键系统需要密集的安全测试来验证和确认系统对恶意行为的稳固性。模糊测试会产生一系列意外的输入，这些输入会触发系统中的不正当行为。OpenPilot支持回归测试工具Process Replay[75]，它可以执行系统进程并根据预先设定的输入验证输出。为了运行模糊测试，我们调整了该工具，使其能够不受限制地接受任何输入，从而对系统的安全性进行强有力的验证，以应对意外输入。
为了验证VulFuzz测试框架的有效性，我们将我们的结果与最先进的模糊器AFL[59]和一个无指导突变模糊器进行了比较。
表一：Vulfuzz、AFL和无指导突变模糊器的比较概况突变模糊器的运行结果
OpenPilot是用Python和Clanguages两种语言设计的。原来的AFL不支持Python语言，所以我们使用AFL的Python分叉。然而，Python AFL并没有对基于C代码的文件进行检测。因此，我们建立了一个脚本来验证和检测基于C代码的文件。为了比较汽车系统中灰盒模糊与黑盒模糊的性能，我们设计了一个无指导突变模糊器。该测试工具实现了VulFuzz的突变引擎，并随机尝试在系统中发现崩溃。我们用Python构建框架，并在同一台机器上执行所有的实验，该机器采用英特尔酷睿i7- 1065G7处理器，这是一个带超线程的四核芯片，其基本运行频率为1.3GHz，内存为8GB。该机器运行的是64位的Ubuntu 16.04长时间支持系统。
B. 实验和结果
我们执行VulFuzz和AFL，直到它们不能发现新的分支或到达易受攻击的函数。然后，我们对VulFuzz生成的相同数量的测试案例运行无指导突变模糊器。为了测试所提出的框架的性能，我们比较了测试案例的数量、丢弃的信息、覆盖率和崩溃，如表I所示。为了控制随机性的影响，我们还报告了每种模糊测试方法的10次运行结果。消融研究的结果将在下一小节单独讨论。
1) 测试案例分析：如表一所示，VulFuzz产生了1810个测试用例，比AFL多了808个测试用例。测试用例的数量影响了处理时间。AFL在其他两个模糊器所消耗的一半时间内完成了执行。正如VulFuzz框架中所描述的那样，为易受攻击的函数分配权重，以进行多次验证。因此，即使一个测试用例没有扩大覆盖范围，但评估了脆弱的函数，它也会被保留在队列中，并进一步变异。相反，AFL只存储扩大覆盖面的测试用例。因此，AFL需要更少的测试案例来达到其目标。
2) 丢弃的测试用例分析:接下来，我们通过检查每个测试工具的丢弃消息的数量来调查突变引擎的有效性。OpenPilot的输入包括各种数据类型，包括布尔型、数字型和字符串。正如所描述的算法中所讨论的那样，拟议的突变引擎试图用不兼容的数据类型来突变输入，以验证系统的输入验证程序，因此产生了20个丢弃的信息。AFL的突变引擎比VulFuzz和无指导突变模糊器有明显更多的放弃信息。
图3. 面向脆弱性的突变引擎和AFL的突变引擎在一个样本输入上的比较。
具体来说，在AFL生成的1002个测试案例中，有233个测试案例没有通过OpenPilot的输入验证程序。也就是说，23%的测试用例被放弃，而其他两个测试工具的放弃率为1%。汽车系统，如OpenPilot，有一个严格的验证方案，防止随机变异成为验证系统安全的有效方法。
例如，图3概述了OpenPilot的一个样本输入的一小部分。为了确定车辆的健康状况，该系统将电压（数值）、点火线（布尔值）、允许控制（布尔值）、CAN发送错误（数值）和CAN转发错误（数值）作为输入。种子s代表一个良好的输入，由突变引擎用来生成新的种子。VulFuzz的变异引擎根据输入字段进行小规模变异，产生两个符合标准的新输入s1和s2，帮助验证系统。AFL突变引擎执行了一个单比特突变，将s3中的 "A "从 "FALSE "改为"@"，将s4中的 "0 "改为 "p"。这两个新的输入s3和s4都不符合OpenPilot的输入验证过程，被放弃。
AFL花了大约1.8小时，超过20%的处理时间用于无效输入。因此，所提出的突变引擎优于小型随机突变策略，并专注于测试能够发现漏洞的有效输入。
3) 覆盖率分析：为了分析VulFuzz的覆盖率，我们测量分支覆盖率和语句覆盖率。分支覆盖率（也被称为过渡覆盖率）可以更好地了解模糊测试在解决复杂条件和到达更深的代码部分方面的能力。
表I显示了访问条件分支的总数。这三种方法的分支覆盖率比较接近，达到了系统条件分支的大约91%。VulFuzz比AFL多覆盖3个分支，比无指导突变模糊器多覆盖12个分支。由于VulFuzz和AFL实施了相同的策略来扩大代码覆盖面，它们的覆盖面预计是相似的。由于分配给脆弱函数的权重，我们的方法取得了稍好的分支覆盖率。对那些没有发现新分支但验证了彻底的弱功能的测试用例进行变异，最终产生了能够发现新分支的种子输入。
图4.语句覆盖率与时间的比较，以秒为单位。
图5. 撞车事故与时间的比较，以秒为单位。
我们通过分析权重对覆盖行为的影响来进一步研究测试工具的覆盖率。图4展示了每个测试工具的语句覆盖率曲线。我们在分析中使用了语句覆盖率，因为它提供了广泛的覆盖率。AFL在8.3小时内达到最佳覆盖率，而VulFuzz需要15.8小时。在最初的15.8小时内，VulFuzz将搜索和评估的重点放在易受攻击的组件上，而不是扩大覆盖范围。一旦完成对高优先级功能的全面测试，模糊器就会切换到低优先级测试。因此，在15.8小时后，VulFuzz遵循AFL的方法。主要目标是在这个阶段扩大覆盖率，由于帮助扩大覆盖率的测试用例被保存在低优先级队列中，没有被忽略，所以模糊器很快就实现了这一点。
虽然AFL的覆盖率图和VulFuzz的形状相似，但无指导突变的模糊器却有不同的形式。该模糊器逐渐达到其最佳覆盖率，而其他工具的覆盖率则急剧增加。这种差异突出了测试指导的重要性。无指导的突变模糊器试图随机地验证系统。由于不了解测试性能，模糊器无法识别穿越系统的特殊测试案例。在浪费了超过11个小时的时间在相同的功能上循环后，模糊器随机地击中了更多的语句。
为OpenPilot实现良好的测试覆盖率并不是很有挑战性。图4显示了AFL和VulFuzz图中覆盖率的急剧增加。两个模糊器都发现了运行几个大型代码块的测试案例。因此，实验中的优先级作用没有得到很好的证明。Comma.ai准备的回归测试案例套件旨在运行Open- Pilot的所有子流程。因此，通过简单的修改，这三个模糊测试器可以实现充分的覆盖。在评估整个车辆软件系统的安全性时，优先排序是明智的，也是必要的。代码的大小和复杂性被放大了，使得完整的测试成为一个无法实现的目标。
4)碰撞分析：图5描述了三种测试工具所引发的崩溃情况。崩溃是汽车系统由于意外行为而引发的异常。测试工具检测到的大多数是索引超限的异常。例如，系统期望散热器风扇速度在0到65 535 r/min之间。任何更大的数值都会导致系统崩溃。同样地，任何大于10000的温度都会导致系统崩溃。我们还发现了其他类型的漏洞，如使用未初始化的值、值错误（非法参数异常），以及其他未处理的异常。考虑到我们的目的是评估VulFuzz的有效性，而不是验证OpenPilot，所以当OpenPilot不在模拟环境中运行时，一些检测到的崩溃可能并不适用。
如图所示，VulFuzz识别的崩溃数量超过了AFL和无指导突变模糊器识别的崩溃。拟议的框架共实现了335个崩溃。图5显示了VulFuzz发现的崩溃数量呈指数级增长。建议的框架始终在测试的前15.8小时内发现崩溃。那时，fuzzer正在维护遍历加权函数的测试用例。这反映在图4中，用一个稳定的覆盖图对弱函数进行彻底的估值。在335次崩溃中，VulFuzz有296次独特的崩溃；288%的被发现的崩溃是唯一的。这显示了权重分配的有效性，它将评估分布在不同的功能上，而不是随机评估系统，这可能会在有限的功能上阻止搜索，导致更少的唯一崩溃。
无指导突变的模糊器共达到176次崩溃。然而，在获得的撞车事件中，只有45%是唯一的。
图6. 唯一的崩溃次数和测试案例执行加权函数的次数。
非指导性突变模糊器识别出的重复崩溃的数量相对较多，这表明黑盒模糊测试在发现各种代码区域方面效果不佳。一般来说，突变引擎和生成的测试用例的数量提高了测试工具的性能，使其能够比AFL发现更多的崩溃。我们故意对1810个测试案例运行随机模糊器，以评估车辆行业中灰盒测试的重要性。这给了模糊器一个发现崩溃的公平机会。然而，VulFuzz发现的崩溃比这种黑盒测试方法多90%，独特的崩溃多274%。所提出的突变引擎的有效性无疑提高了黑盒验证的性能。模糊测试器没有在无效输入上消耗时间；99%的测试运行是成功的。随机黑盒模糊测试技术的效果会比较差，它试图创建汽车系统不接受的任意输入。
AFL在发现撞车方面表现不佳。在最初的4.5小时内，AFL检测到了8次碰撞，这些碰撞都是独一无二的。正如前面所讨论的，AFL的突变引擎在处理媒体文件时具有显著的性能。然而，对于一个包含强大输入验证机制的复杂系统来说，它的效率较低。测试时间浪费在没有评估系统和寻求崩溃识别的无效输入上。AFL相对较快地达到了其覆盖率峰值。不过，这也影响了检测到的崩溃数量。如图4所示，在最初的4.5小时内，模糊器仍在试图扩大覆盖范围，但也在检查脆弱的功能。实验新的测试用例有助于AFL触发未发现的崩溃。一旦AFL增加覆盖率，发现的崩溃就会减少。
我们还研究了加权函数和独特碰撞之间的关系。图6比较了三种测试工具的独特碰撞次数和弱函数的测试次数。VulFuzz使用安全漏洞指标来识别系统的薄弱部分。通过分配权重来实现对这些组件的彻底评估。根据安全漏洞评分，OpenPilot中的功能被分为低（功能没有漏洞）、中（功能可能构成一些风险）和高（功能有漏洞）。
图7. 维恩图显示了不同模糊测试工具所检测到的独特崩溃的比较。
脆弱性低的功能被赋予0的权重，以避免将测试的优先级放在对系统构成最小风险的组件上。中等脆弱功能的权重为50，高脆弱功能的权重为100。5%的 OpenPilot有5%的功能有高数量的漏洞，3%的功能有中等数量的漏洞。VulFuzz生成了808个测试用例，检查了高、中等级的漏洞功能，而无指导突变模糊器的测试用例为188个，AFL为79个。如图6所示，测试的脆弱功能越多，发现的独特崩溃的数量就越多。AFL拥有最低的加权函数执行数，这体现在所发现的崩溃数量上。相比之下，VulFuzz对脆弱组件的详尽评估增强了其崩溃检测能力。这证明了安全度量和权重分配的重要性。安全指标将测试指向更容易出现漏洞的复杂功能。权重分配使VulFuzz有机会更多地检查这些组件，并找出漏洞。
图7比较了三种测试工具报告的独特碰撞。VulFuzz识别了AFL识别的所有崩溃，以及非引导突变的模糊器检测到的59个独特的崩溃。拟议的框架只识别了基于突变的模糊器发现的12个独特的崩溃（占总数的4%）。
我们通过在不同的子进程上运行VulFuzz框架，进一步检查了VulFuzz在识别独特崩溃方面的有效性。如前所述，OpenPilot是一个由不同子进程组成的大型系统，我们对整个系统进行了评估。然而，为了证明VulFuzz能够持续识别车辆软件组件上的崩溃，我们在OpenPilot的三个子进程上连续运行该框架，并将识别的独特崩溃与其他测试工具得到的结果进行比较。这些过程是随机选择的。表二中的结果证实了VulFuzz在识别汽车软件组件的独特碰撞方面的有效性，同时一致地优于AFL和不针对汽车行业测试挑战的非引导突变模糊器。例如，对于子流程1（控制），VulFuzz识别的独特崩溃比无指导突变模糊器多106%，比AFL多675%。同样，对于子流程2，VulFuzz检测到的独特崩溃比AFL多150%，并获得与无指导突变模糊器类似的结果。
表二：对不同OpenPilot子程序的碰撞分析
表三：10次运行的平均结果
表四：Vulfuzz发动机的烧蚀研究结果
5) 平均运行：为了减轻随机性对评估过程结果的影响，我们对每一个模糊的时间进行了调整，并计算出了平均结果。平均结果见表三。我们注意到，AFL变异引擎和VulFuzz变异引擎中加入的随机性对模糊处理工具的性能影响不大。这十次运行的结果非常相似。相反，缺乏指导和随机性因素影响了无指导突变模糊器的覆盖结果。十次运行中，有六次覆盖的条件语句少于4790条。因此，灰盒模糊测试对于保持代码覆盖率和高效评估至关重要。
C. 烧蚀研究
VulFuzz中部署的每一个引擎都旨在加强车辆软件系统的漏洞识别过程。本节进行了一项烧蚀研究，以证明每个发动机的功能及其对脆弱性暴露的贡献。我们运行VulFuzz四次，在每次运行中，我们消除四个引擎中的一个。消减研究的结果总结在表四中。
漏洞引擎在将模糊测试引向需要密集测试的薄弱组件方面起着重要作用。省略漏洞引擎会影响到框架的其他引擎。评估引擎只监控种子的执行，更新覆盖率表，而不监控权重计数。此外，测试用例的优先级也依赖于漏洞得分。因此，通过消除脆弱性引擎，优先级引擎的作用也被排除。
移除漏洞引擎会对发现的崩溃数量产生负面影响。只有59个独特的崩溃被定位，而VulFuzz则有296个崩溃。在突变引擎的帮助下，模糊测试实现了良好的覆盖率，只有341个测试案例。这限制了测试时间，也限制了漏洞引擎强迫对弱小组件的密集测试。
在消融研究的第二次运行中，我们将评估引擎的作用限制在只更新权重函数的调用数。因此，在这种变化下，Fuzz测试不能识别穿越新分支的测试用例，并在满足加权函数的调用计数后停止。限制评估引擎的功能并不会对模糊测试结果产生巨大影响。漏洞引擎迫使人们对弱点功能进行彻底检查，这导致了大量的测试案例，并发现了290个独特的崩溃现象。
为了验证变异引擎的关键作用，在本研究的第三次运行中，我们将VulFuzz变异引擎与AFL的变异引擎放在一起。取消VulFuzz突变引擎后，丢弃的信息数量大大增加，达到702个丢弃的测试案例。这反过来又影响了模糊测试在识别预期行为方面的进展。只有50个独特的崩溃被发现，而VulFuzz发现的是296个。第三次运行中的模糊测试未能找到足够的测试案例来彻底检查加权函数。不过，消除突变引擎的结果是，模糊测试比AFL的性能更强。对脆弱功能进行优先测试有助于发现比AFL多525%的独特碰撞。
消减研究的最后一步是省略VulFuzz的优先级引擎。在汽车行业，当安全测试时间不足以进行全面评估时，对测试案例进行优先排序很有价值。然而，在进行完整的测试时，优先级引擎并没有增强结果。如表四所示，第四次运行的结果与VulFuzz相似。通过生成1820个测试案例，总共发现了338个独特的崩溃。总之，引擎的聚合使VulFuzz成为一个强大的模糊测试工具；取消任何一个引擎都会使VulFuzz的效率降低。然而，漏洞和突变引擎是最关键的引擎，在有效和全面地识别车辆软件系统中的漏洞方面发挥着重要作用。
VI.总结
建立一个能够安全和可靠地驾驶、感知周围环境并为乘客提供娱乐的车辆，需要将大约1亿条代码线、数十个电子设备和多种先进技术纳入一个系统，使车辆面临无数潜在的网络攻击。静态代码分析、动态程序分析、漏洞扫描、渗透测试和模糊测试是安全保证方法，可以在VSE期间帮助OEM和供应商保证系统的安全性。然而，汽车行业正面临着一些挑战，这些挑战继续使安全测试成为一项艰巨的工作。
黑盒模糊测试是建议的工具之一，可以帮助缓解这些挑战。
然而，黑盒模糊测试的天真性使其成为不可靠的测试工具，使关键系统具有最低的安全弹性保证。白盒模糊测试可以提供一个更可靠的安全测试工具；然而，考虑到系统的规模，白盒测试成为一个耗时的工作，在严格的项目期限内难以管理。
本文提出了一个面向漏洞的灰盒模糊测试框架，该框架通过获取系统的一些知识，克服了黑盒测试的局限性，而不会造成白盒测试所带来的开销。VulFuzz是专门为测试和识别软件系统中可能存在的漏洞而定制的。该框架包含了四个引擎。1）漏洞，2）突变，3）评估，和4）优先级，它们共同引导测试向系统的漏洞方向发展。与盲目验证系统的黑匣子模糊器相比，拟议的框架利用安全指标来监督和指导测试。安全指标定量地测量了车辆软件系统中各组件的脆弱性。这种估计反映了代码的复杂性，并确定了可被攻击者违反的弱点集成。根据漏洞值，每个组件被分配了一个权重，代表一个组件应该被测试的次数。对潜在的弱点组件进行彻底检查可以提高漏洞检测率，保证系统的安全。VulFuzz监控种子输入的覆盖率，以实现其目标并确定测试的优先次序。为了加强灰盒模糊器的性能，突变引擎通过推断输入的数据类型，生成符合自动机系统输入结构的各种测试案例。
为了评估所提出的框架的有效性，我们在一个汽车系统OpenPilot上进行了实验。VulFuzz优于黑盒fuzzer和著名的灰盒fuzzer, AFL。OpenPilot复杂组件的全面测试帮助VulFuzz在16.8小时内发现了335次崩溃，比AFL多4088%，比非引导突变fuzzer多90%(比AFL多100%，比非引导突变fuzzer多0%)。此外，该框架基于数据类型的突变满足了OpenPilot的输入要求，仅丢弃了20条消息，比AFL减少了91%。这些结果显示了VulFuzz在暴露车辆软件系统漏洞方面的有效性。该框架提供了一种可靠的安全测试工具，它不会增加测试的复杂性，而是智能而有效地识别出薄弱的组件，并将重点放在它们上。此外，测试的优先级可以帮助安全工程师在有时间限制的项目中自动管理安全测试。然而，有时灰盒模糊测试可能无法达到系统中的某些功能。因此，使用另一种工具来支持模糊测试是至关重要的，它可以补充模糊测试，并确保完整的测试覆盖率。
在未来，我们计划设计一个静态代码分析工具，只验证未发现的功能，以提高安全保证的可靠性。此外，我们计划进一步扩展这项工作，并将其应用于具有多个队列和阈值的不同汽车系统。由于该行业正逐步转向ECU整合，预计将降低制造成本并提高安全性，我们计划应用VulFuzz并实验这种转变是否能有效减少汽车系统的漏洞。
参考文献：
[1] S. Parkinson, P. Ward, K. Wilson, and J. Miller, “Cyber threats facing autonomous and connected vehicles:Future challenges,” IEEE Trans. Intell. Transp. Syst., vol. 18, no. 11, pp. 2898–2915, Nov. 2017.
[2] Q1 2019 Sees a Rapid Growth of Automotive Cyber Incidents. [On-
line]. Available: https://www.upstream.auto/blog/q1-2019-sees-a-rapid- growth-of- automotive-cyber-incidents/
[3] Autosar Enabling Continuous Innovations. [Online]. Available: https://
www.autosar.org/
[4] Cybersecurity Guidebook for Cyber-Physical Vehicle Systems J3061_201601 [Online]. Available: https://www.sae.org/standards/ content/j3061_201601/
[5] What Is the ISO 26262 Functional Safety Standard? [Online].
Available: https://www.ni.com/en-ca/innovations/white-papers/11/what-is-the-iso-26262-functional- safety- standard- .html
[6] L. J. Moukahal,M. A. Elsayed, and M. Zulkernine, “Vehiclesoftware engineering(VSE):Researchandpractice,”IEEEInternetThingsJ.,vol. 7, no. 10, pp. 10 137– 10149, Oct. 2020.
[7]ISO/IEC27005.[Online].Available:https://www.iso.org/standard/43464.html
[8] Society of Automotive Engineers. [Online]. Available: https://www.sae.
org/
[9] Road Vehicles -Cybersecurity Engineering ISO/SAE Dis 21434. [Online]. Available: https://www.sae.org/standards/content/iso/sae21434.d1/
[10] D. Oka, “Securing the modern vehicle:A study of automotive industry cybersecurity practices,” in Embedded World-Class 4.1: The ESCRYPT Class - Security for a Globally Connected Vehicle, vol. 10,no. 4, 2019, Art. no. 148.
[11] T. Brennich andM. Moser, “Putting automotive security to the test,” ATZelectronics Worldwide, vol. 15, no. 1, pp. 46–51, 2020.
[12] U. Drolia,Z. Wang,Y. Pant,andR. Mangharam,“Autoplug:Anautomotive test-bedforelectroniccontrollerunittestingandverification,”in Proc. 14th Int. IEEE Conf. Intell. Transp. Syst., 2011, pp. 1187– 1192.
[13] Successful Security Tests Using Fuzzing and HiL Test Systems. [Online].
Available: https://www.etas.com/download-center- files/products_LABCAR_Software_Products/Hanser- automotive_Successful- security- tests-hil- system_en.pdf
[14] S. Bayer, T. Enderle, D.-K. Oka, and M. Wolf, “Security crash test-practical security evaluations of automotive onboard it components,”Bonn: Gesellschaft für Informatik e.V., In: Klenk, H., Keller, H. B., Plödereder, E. &Dencker, P. (Hrsg.),Automot. - Saf. Secur., pp. 125– 139,
2015.
[15] D. S. Fowler,J. Bryans, S. A. Shaikh,and P. Wooderson, “Fuzz testing for automotive cyber-security,”in Proc. 48th Annu. IEEE/IFIP Int. Conf.Dependable Syst. Netw. Workshops, 2018, pp. 239–246.
[16] The Fuzz on Automotive Cybersecurity Testing. [Online]. Available: https:
//securitybyescrypt.com/fuzztesting/
[17]Defensics Fuzz Testing. [Online]. Available: https://www.synopsys.com/ software-integrity/security-testing/fuzz-testing.html
[18] D. K. Oka,A. Yvard,S. Bayer,andT. Kreuzinger,“Enablingcybersecurity testingof automotive ECUs by addingmonitoring capabilities,” in Proc. 15th Embedded SECUrity Cars Conf., 2016, pp. 1– 13.
[19] Automating fuzz test generation to improve the security of theController Area Network [Online]. Available: https://pure.coventry. ac.uk/ws/portalfiles/portal/11566144/Fowler_Bryans_Shaikh_ECU_ Fuzz_Testing.pdf
[20] D. S. Fowler, J. Bryans, M. Cheah, P. Wooderson, and S. A. Shaikh, “A method for constructing automotive cybersecurity tests, a CAN fuzz testing example,” in Proc. IEEE 19th Int. Conf. Softw. Quality, Rel. Secur. Companion, 2019, pp. 1–8.
[21] D. S. Fowler,J. Bryans, S. A. Shaikh,and P. Wooderson, “Fuzz testing for automotive cyber-security,”in Proc. 48th Annu. IEEE/IFIP Int. Conf.Dependable Syst. Netw. Workshops, 2018, pp. 239–246.
[22] A. Pretschner, M. Broy, I. H. Kruger,and T. Stauner, “Software engi-neering for automotive systems: A roadmap,” in Proc. Future Software
Engineering, 2007, pp. 55–71.
[23] Code Bases. [Online]. Available: https://www.informationisbeautiful.net/
visualizations/million-lines-of-code/
[24] S. Moshtari,A. Sami,andM. Azimi,“Usingcomplexitymetricstoimprove software security,” Comput. FraudSecur.,vol. 2013,no. 5,pp. 8– 17,2013.
[25] Y. Shin and L. Williams, “Can traditional fault prediction models be
used for vulnerability prediction?” Empirical Softw. Eng., vol. 18,no. 1,
pp. 25–59, 2013.
[26] I. Chowdhury and M. Zulkernine, “Using complexity, coupling,and co-
hesion metrics as early indicators of vulnerabilities,” J. Syst. Architecture,
vol. 57, no. 3, pp. 294–313, 2011.
[27] M. Broy, “Challenges in automotive software engineering,” in Proc. 28th
Int. Conf. Softw. Eng., 2006, pp. 33–42.
[28] S. A. Haider, G. Samdani, M. Ali, and M. Kamran, “A comparative
analysis of in-house and outsourced development in software industry,”
Int. J. Comput. Appl., vol. 141, no. 3, pp. 18–22, 2016.
[29] C. Hubmann, M. Becker, D. Althoff, D. Lenz, and C. Stiller, “Decision
making for autonomous driving considering interaction and uncertain
predictionofsurroundingvehicles,”in Proc. IEEEIntell. Veh. Symp.,2017,
pp. 1671– 1678.
[30] P. Koopman and M. Wagner, “Challenges in autonomousvehicle testing
and validation,” SAE Int. J. Transp. Saf., vol. 4, no. 1, pp. 15–24, 2016.
[31] P. Koopman and M. Wagner, “Autonomous vehicle safety: An interdisci-
plinarychallenge,” IEEEIntell. Transp. Syst. Mag.,vol. 9,no. 1,pp. 90–96,
Spring 2017.
[32] Testing ECUs and Networks With Canoel. [Online]. Available: https://
www.vector.com/int/en/products/products-a-z/software/canoe/
[33] OPAL-RT Testing Platform for Automotive Simulation. [Online]. Avail-
able: https://www.opal-rt.com/automotive-overview/
[34] C. Obermaier,R. Riebl, C. Facchi, A. Al-Bayatti, and S. Khan, “Lim-
itations of HIL test architectures for car2x communication devicesand
applications,”in Proc. ACM Comput. Sci. Cars Symp., 2019, pp. 1–9.
[35] I. Pekaric, C. Sauerwein, and M. Felderer, “Applying security testing
techniquestoautomotiveengineering,”in Proc. 14thInt. Conf.Availability,
Rel. Secur., 2019, pp. 1– 10.
[36] A. Imparato, R. R. Maietta, S. Scala, and V. Vacca, “A comparative
study of staticanalysis tools for autosar automotive software components
development,” in Proc. IEEE Int. Symp. Softw. Rel. Eng. Workshops, 2017,
pp. 65–68.
[37] Bugfinder - Insect Search and Identification Tool. [Online]. Available:
https://www.insectidentification.org/bugfinder-start.asp
[38] Polyspacecodeprover.[Online].Available:https://www.mathworks.com/
products/polyspace-code-prover.html
[39] Quality Accelerated. [Online]. Available: https://www.qa-systems.com/
[40]What is MISRA ? [Online]. Available: https://www.misra.org.uk/
MISRAHome/WhatisMISRA/tabid/66/Default.aspx
[41] S. Keul, “Tuningstatic data race analysis for automotive controlsoftware,”
in Proc. IEEE 11th Int. Working Conf. Source Code Anal. Manipulation,
2011, pp. 45–54.
[42] A. G. Bardasetal.,“Staticcodeanalysis,”J. Inf. Syst. OperationsManage.,
vol. 4, no. 2, pp. 99– 107, 2010.
[43] Z. B. Celik, E. Fernandes, E. Pauley, G. Tan, and P. McDaniel, “Program
analysis of commodityIOT applications for security and privacy: Chal-
lenges and opportunities,” ACM Comput. Surv., vol. 52, no. 4, pp. 1–30,
2019.
[44] K. A. Koscher, “Securing embedded systems: Analysesof modern au-
tomotive systems and enabling near-real time dynamic analysis,”Ph.D.
dissertation, 2014.
[45] G. Cabodi, D. F. S. Finocchiaro, and D. Montisci, “Security-oriented dy-
namiccodeanalysisinautomotiveembeddedsystems,” Ph.D. dissertation.
Politecnico di Torino. 2018. Available: https://webthesis.biblio.polito.it/
7510/
[46] AutomotiveInformationSharingandAnalysisCenter. [Online]. Available:
https://automotiveisac.com/
[47] M. Ring, J. Dürrwang,F. Sommer, and R. Kriesten, “Survey on vehicular
attacks-building a vulnerability database,”in Proc. IEEE Int. Conf. Veh.
Electron. Saf., 2015, pp. 208–212.
[48] F. Sommer, J. Dürrwang,and R. Kriesten, “Survey and classification of
automotive security attacks,”Inf., vol. 10, no. 4, p. 148, 2019.
[49] K. Koscher etal., “Experimental security analysis of a modern automo-
bile,” in Proc. IEEE Symp. Secur. Privacy, 2010, pp. 447–462.
[50] M. Cheah, S. A. Shaikh,O. Haas, and A. Ruddle, “Towards a systematic
security evaluation of the automotivebluetooth interface,” Veh. Commun.,
vol. 9, pp. 8– 18, 2017.
[51] C. Corbett, T. Basic, T. Lukaseder, and F. Kargl, “A testing framework
architecturefor automotive intrusion detection systems,” Automot. Saf.
Secur. Sicherheit Zuverlässigkeit automobile Informationstechnik, pp. 89–
102, 2017.
[52] A. Taylor, S. Leblanc, and N. Japkowicz, “Probing the limits of anomaly detectors for automobiles with a cyberattack framework,” IEEE Intell.Syst., vol. 33, no. 2, pp. 54–62, Mar./Apr. 2018.[53] T. Huang,J. Zhou,andA.Bytes,“ATG:Anattacktrafficgenerationtoolfor security testing of in-vehiclecan bus,” in Proc. 13th Int. Conf. Availability, Rel. Secur., 2018, pp. 1–6.
[54] H. Liang, X. Pei, X. Jia, W. Shen, and J. Zhang, “Fuzzing: State of the art,”IEEE Trans. Rel., vol. 67, no. 3, pp. 1199– 1218, Sep. 2018.
[55] D. K. Oka, T. Fujikura,and R. Kurachi, “Shift left: Fuzzing earlier in the automotive software development lifecycleusing HIL systems,”in Proc. 16th ESCAR Europe, 2018, pp. 1– 13.[56] P. Patki,A. Gotkhindikar,andS.Mane,“Intelligentfuzztestingframework for finding hidden vulnerabilities in automotive environment,” in Proc. 4thInt. Conf. Comput. Commun. Control Automat., 2018, pp. 1–4.
[57] A.-I. Radu and F. D. Garcia, “Grey-box analysisand fuzzing of automo- tive electronic components via control-flow graph extraction,” in Proc. Comput. Sci. Cars Symp., 2020, pp. 1– 11.
[58] P. Wang and X. Zhou, “SoK: The progress, challenges, and perspectives of directed greybox fuzzing,” 2020, arXiv:2005.11907.
[59] M. Zalewski, “AmericanFuzzy Lop. 2015,” 2015. [Online]. Available: URL http://lcamtuf.coredump.cx/afl
[60] V.-T. Pham, M. Böhme, A. E. Santosa, A. R. Caciulescu, and A. Roychoudhury,“Smartgreyboxfuzzing,”IEEETrans. Softw. Eng.,vol. 47, no. 9, pp. 1980– 1997, 1 Sep. 2021.
[61] C. Lemieux and K. Sen, “Fairfuzz: A targeted mutation strategy for increasing greybox fuzz testing coverage,”in Proc. 33rd ACM/IEEE Int.Conf. Automated Softw. Eng., 2018, pp. 475–485.
[62] M. Böhme, V.-T. Pham, M.-D. Nguyen, and A. Roychoudhury, “Directed greybox fuzzing,” in Proc. ACMSIGSAC Conf. Comput. Commun. Secur.,2017, pp. 2329–2344.
[63] G. Zhang and X. Zhou, “AFL extended with test case prioritization techniques,” Int. J. Model. Optim, vol. 8, no. 1, pp. 41–45, 2018.
[64] P. D. MarinescuandC. Cadar,“KATCH:High-coveragetestingofsoftware patches,” in Proc. 9th Joint Meeting Foundations Softw. Eng., 2013, pp. 235–245.
[65] L. Moukahal and M. Zulkernine, “Security vulnerability metricsfor con- nected vehicles,” in Proc. IEEE 19th Int. Conf. Softw. Quality, Rel. Secur. Companion, 2019, pp. 17–23.
[66] S. S. Tangade and S. S. Manvi, “A survey on attacks, securityand trust management solutions in VANETs,” in Proc. 4th Int. Conf. Comput., Commun. Netw. Technol., 2013, pp. 1–6.
[67] A. Zeller, R. Gopinath, M. Böhme, G. Fraser,and C. Holler, The Fuzzing Book, 2019.
[68] P. Chen and H. Chen, “Angora: Efficient fuzzing by principled search,”in IEEE Symp. Secur. Privacy, IEEE, 2018, pp. 711–725.
[69] V. Wüstholz and M. Christakis, “Learning inputs in greyboxfuzzing,” 2018, arXiv:1807.07875.
[70] V. Jain, S. Rawat,C. Giuffrida, and H. Bos, “TIFF: Using input type inference to improve fuzzing,”in Proc. 34th Annu. Comput. Secur. Appl.Conf., 2018, pp. 505–517.
[71] S. Rawat and L. Mounier, “Offset-aware mutation based fuzzing for buffer overflow vulnerabilities: Few preliminary results,”in Proc. IEEE4th Int. Conf. Softw. Testing, Verification Validation Workshops, 2011, pp. 531–533.
[72] R. C. Bhushan and D. D. Yadav, “Number of test cases required in achieving statement,branch and path coverage using ‘gcov’: An analysis,” in Proc. 7th Int. Workshop Comput. Sci. Eng., 2017, pp. 176– 180.
[73] Openpilot. [Online]. Available: https://github.com/commaai/openpilot [74] Comma.ai. [Online].Available: https://comma.ai/
[75]Openpilot Process Replay. [Online]. Available: https://github.com/
commaai/openpilot/tree/master/selfdrive/test/process_replay
分享不易，恳请点个【👍】和【在看】
