这篇文章发表于今年的NDSS，主要研究了自动驾驶（Autonomous Driving, AD）系统中过于保守策略的漏洞。文章针对AD系统中过于保守的策略，设计了一个自动搜索语义拒绝服务攻击漏洞的方法 PlanFuzz。
背景及简介
在高级（$\ge LV4$）自动驾驶系统中，行为规划（Behavioral Planning, BP）负责较高级的驾驶决策，例如：巡航、停车等等，由此可见BP对于自动驾驶的安全性至关重要。
在先前的一些研究工作中，AD系统中的语义安全漏洞主要聚焦于环境感知，比如：相机、雷达的目标检测错误等。最近也有一些工作聚焦于行为规划中的语义错误（semantic planning errors），与本文不同的是，它们主要被设计用于：
- AD系统整体测试而非行为规划相关
- 仅考虑过于激进的行为
- 确保AD系统的保护性而非安全策略（缺乏显式的威胁模型）
基于此状况，本文提出了首个AD系统中规划相关的自动语义漏洞发现框架PlanFuzz。PlanFuzz 被设计用于发现AD系统中过于保守策略的漏洞，特别是那些会引起AD交通工具无法正常工作的漏洞（比如：永久停止）。
行为规划（Behavioral Planning）
在L4自动驾驶系统中，AD 规划（planning）是一个非常重要的模块，它被设计用于生成安全、高效、平稳的行驶路径。
在工业级AD中，此模块通常分为三层：
- 路径规划（route planning）：从地图中选择一个到达目的地的路径（类似我们常用的地图APP）
- 行为规划（behavioral planning, BP）：用于进行高层次的驾驶决策，比如巡航、停车、变道等等
- 本地规划：用于将行为规划翻译为底层的行驶轨迹，进而转化为车辆的控制决策
本文的重点在于BP，从BP的描述我们可以看出，一旦BP出错就很可能会导致交通安全事故。比如，如果BP策略太过激进就有可能导致撞车，而如果太过保守又可能会导致紧急停车、交通拥堵。当前BP策略通常用过预规划的规则或者通过学习得到的逻辑来生成。最近也有一些工作使用基于学习（机器学习等）的方法，但是此类方法在实际应用时限制太多，特别是它们缺乏可解释性，所以此类方法尚不能在工业级AD中得到广泛应用。
PlanFuzz
威胁模型
攻击向量：攻击者仅能控制马路上常见的一些对象。
在此威胁模型中，攻击者可以将常见的一些对象引入到自动驾驶环境中（比如：静止的自行车、路边的行人等），并且攻击者引入的这些对象对于正常行驶（人类驾驶）的车辆是不会产生影响的（新引入的对象不会违反交通礼仪、规范等）。
攻击目标
本文的攻击目标是引起行为规划中的语义拒绝服务攻击。
【定义】BP中的语义DoS：
通过让正常驾驶的车辆触发过于保守的行为规划策略，以致自动驾驶车辆的性能显著降低（如：让车辆永久无法到达目的地）的攻击。
本文考虑两种类型的具体攻击：
- 引起车辆急停或永久停止
- 引起攻击对象放弃原有的重要驾驶决策（如：放弃正常转向、变道等）
本文将重点放在了过于保守的策略，而非激进的策略。原因是，在现实的AD设定中，为了让车辆更加安全，大家都倾向于将策略设计得越保守越好。
攻击举例
在上图中，我们假设AD的驾驶策略为：车辆左右边界必须距离两边的物体0.4米以上。在图A中，所放置的物体距离车辆在0.4米以上，车辆可以正常行驶；在图B中，物体被放置在靠近马路边缘的地方，但此时将两边的物体向内延伸0.4米的距离之后（红色虚线边框），车辆检测到安全路径的宽度仅有1.9m，小于车身2.11米，这就导致了AD判定无法通过前面的路，车辆最终停止。而在正常人在开车时，显然不会认为此时路段无法通行。图三中为此攻击在模拟场景中的实验结果，车辆最终停止在了两个放置在路边的物体之前。
设计挑战及解决方案
为了及时发现及解决上述问题，提前检测是必要的。PlanFuzz的设计基于当前较为成功的一个基于属性的测试框架。在此框架下，我们可以将上面的攻击例子描述为：
$$
可以安全驾驶 \to \neg 停止
$$
此属性描述表示：当当前的路径允许安全驾驶的时候，车辆应该可以正常沿路径行驶，不会被不相关的物体影响而停止。上述属性看起来简单，但在设计自动检测方案时，有三个个问题需要解决：
- 缺乏一个语义DoS攻击的检测预言机。以上述攻击的属性描述为例：我们应该如何定义安全？文中提出使用规划不变量（Planning Invariant， PI）来解决此问题。PI由三部分组成：规划场景、物理对象的限制以及期望的规划行为。这三个组成部分共同定义了一个属性描述。以上面的攻击为例，规划场景就是沿路行驶；物理对象限制为：将物体放置在路边，且在路的边界以外并静止保持不动；期望的规划行为是车辆沿路正常行驶不停止
- 如何根据复杂的、问题相关的限制来系统地生成攻击输入。文中的策略是，生成物体时不考虑限制条件，在生成之后，根据实施的限制条件来不断调整生成的物理对象。这些物理限制由PI来提供，并且满足遗传算法中样本生成过程的多样性和继承性原则
- 如何从
规划代码中获取细粒度的反馈来引导漏洞发现。文中提出定义一个BP缺陷距离来衡量某一BP的执行是否会违背预定义的PI，从而触发一个BP DoS漏洞。这个缺陷距离是根据当前代码执行路径与可以到达攻击目标的代码执行路径之间的差异来计算的，这个差异需要同时考虑代码中的数据流与控制流
整体设计
PlanFuzz的设计目标是从BP决策代码中发现未知的语义拒绝服务漏洞。PlanFuzz 框架分为线下分析与线上测试运行两部分（如下图）。
线下分析部分负责分析与某个PI相关的攻击路径的控制流与数据流的数据。并将攻击执行路径的控制流与数据流记录下来，用于运行时计算BP缺陷距离。
线上测试运行部分负责使用遗传算法生成攻击样本放入环境，而后运行模拟测试环境，一旦检查器发现AD车辆违背了PI定义的规则，那么就将此攻击样本记录下来。
在PlanFuzz框架中，攻击样本生成是整个框架的重要组成部分。它主要包含三个部分：规划不变量（PI）、物理对象生成以及进化算法。
论文中考虑了8个不同的规划场景，这些场景覆盖了现实中常见的基本驾驶情形，比如：沿路行驶、过十字路口（有交通信号灯指示）、变道、借道等等。
这些场景的期望行为就是非常朴素地正常按照场景行驶。
PI中不同场景下需要生成不同的物理对象（比如：自动驾驶车辆、行人、路边物体等等），这些物理对象需要满足的限制需要根据不同的场景来预先定义。最基本的限制就是需要满足正常的驾驶规范、交通规则等。具体的PI及其限制等可参考论文中表4。
进化算法中的fitness指标使用的是我们前面定义的BP缺陷距离。此距离的详细定义可参考论文。此处的重点是论文在控制流距离（基于灰盒模糊测试技术）的基础上引入了数据流的距离。这一点也很好理解，就以上面的攻击为例，在路边放置的物体的横向距离显然与攻击是强相关的，因此在物体生成过程中加入此数据显然可以更方便地生成更好的攻击样本。
实验
为了测试PlanFuzz的漏洞检测能力，研究者测试了两个开源的自动驾驶框架：Baidu Apollo和Autoware。Apollo和Autoware中都使用了基于规则的逻辑来进行决策（在Autoware 的BP中，所有的规划改变使用了单个整体的状态机；而Apollo 更加模块化，整个驾驶决策被划分为更小的驾驶任务，如：碰撞避免、变道、变速等等）。测试环境使用了LGSVL，这是一个产品级的自动驾驶模拟环境。
在实验过程中，PlanFuzz共发现了Apollo和Autoware中的9个 BP DoS 漏洞。这些漏洞根据场景的不同可以分为三类：
- 车道跟随（lane following）拒绝服务攻击：在此场景下，车辆原本应该正常沿路行驶，而攻击者通过将物体放置在路边，最终导致了车辆永久停止或者紧急停止而导致追尾
- 路口通过拒绝服务攻击：在此场景下，攻击者通过在路口附近放置（在模拟环境中）静态或动态的自行车或者行人来让路口的自动驾驶车辆停在人行道前或者路口处。这些行人或者自行车实际上是完全不会影响车辆的正常行驶的，而由于AD策略的过于保守，最终导致了AD车辆无法行驶
- 变道拒绝服务攻击：在此场景下，攻击者通过在被攻击车辆后放置一辆跟随的车辆来让前面的车辆不敢变道。在此场景中，后面的车辆会让车身稍微偏左行驶，这导致前方想要向左变道的车辆不敢变道
其它
此类攻击应该与DDoS攻击一样，目前如何应对还是一个开放问题，很难在近期被解决。保守策略本身就是为了保护自动驾驶的安全。而如果保守策略被利用来进行攻击，那么简单地将策略改为不保守显然是不行的。而动态调整策略需要穷尽所有的现实场景，这显然也是不现实的。此外，如何平衡AD策略也远不只是一个技术问题。
引用
[1] Wan, Ziwen, et al. "Too Afraid to Drive: Systematic Discovery of Semantic DoS Vulnerability in Autonomous Driving Planning under Physical-World Attacks."arXiv preprint arXiv:2201.04610(2022).
更多推荐