mGPTFuzz：大型语言模型辅助Matter物联网设备模糊测试

基本信息

原文名称：From One Thousand Pages of Specification to Unveiling Hidden Bugs: Large Language Model Assisted Fuzzing of Matter IoT Devices

原文作者：Xiaoyue Ma; Lannan Luo; Qiang Zeng;

原文链接：https://www.usenix.org/conference/usenixsecurity24/presentation/ma-xiaoyue

发表期刊：the Proceedings of the 33rd USENIX Security Symposium

开源代码：https://iot-fuzz.github.io(链接中目前还未发布代码)

 

一、引言

Matter是一种开放、免版税的物联网连接标准，得到了200多家公司的认可，包括Apple、Google、Amazon和Samsung。它的目的是建立一个统一的标准，促进不同供应商的智能设备之间的互操作性。在众多大型科技公司的支持下，这一统一标准有望彻底改变物联网生态。鉴于其受欢迎程度，发现Matter设备中的错误和漏洞是一个新兴的重要问题。

由于大量的定制和专有硬件组件，模拟物联网固件仍然具有挑战性。构建精确的模拟器既复杂又困难。因此，黑盒模糊测试成为一种有吸引力的选择。

为了对Matter进行黑盒模糊测试，作者构建了第一个Matter模糊器，名为mGPTFuzz，它可以帮助物联网供应商、安全研究人员以及众多公司和组织识别Matter设备中的错误和漏洞，主要的关键点为：

（1）利用LLM从大量规范中提取信息：通过Matter规范中广泛而详细的信息来指导测试输入的生成；

（2）采用基于控制器的模糊测试架构：这种设计无需对任何配套应用程序进行逆向工程或收集API测试脚本，并且可以导出被测设备支持的命令的完整列表。这样可以获得设备的高命令覆盖率；

（3）丰富的模糊测试策略和状态分析：可以发现有状态错误和非崩溃错误，以及崩溃错误。

二、研究动机

要从Matter规范中提取信息，一种直接的方法是手动仔细阅读并绘制所有状态机（FSM）。然而，由于以下原因，作者使用LLM来进行该过程：

（1）节省大量繁琐的手动工作。该规范长达1,258页。虽然描述集群的部分只有589页，但剩下的部分也并非毫无用处。例如，它涵盖了数据类型及其范围，以及集群描述中使用的符号的定义。首先要提取此类知识，然后用于与 LLM 进行后续交互以进行特定于集群的查询。

（2）避免忽略重要信息。手动从规范中提取信息可能会忽略重要信息。例如，Matter SDK开发人员省略了不应删除GroupKeySetID = 0的信息（CVE-2023-42189），如图1所示。作者发现的许多非崩溃错误也表明开发人员遗漏了信息。

• KeySetRemove命令用于移除一个密钥集（Key Set）。
• 如果尝试移除的GroupKeySet ID是0，这个命令应该失败。
• GroupKeySet ID为0时，它关联的是身份保护密钥（Identity Protection Key，简称 IPK）。
• 当命令失败时，应该返回一个INVALID_COMMAND状态码给发起者。

图 1  被开发者忽略的规范信息

（3）应对标准的快速演变。自2022年10月发布1.0版本以来，已经发布了三个新版本（2023年5月V1.1、2023年10月V1.2、2024年5月V1.3）。知识库提取的自动化可以加速模糊器的更新。

另一种替代方法是从代码中提取FSM。然而，它是不完整的。例如，Matter SDK提供了开发物联网设备的框架，但没有规定所有细节。其次，它可能包含错误，例如，错误地处理参数值范围。总之，该方法没有提供Matter设备应遵守的“标准”。因此，作者选择从规范中提取信息。

 

现有SOTA黑盒物联网模糊测试器SNIPUZZ的局限性：

（1）手动收集测试程序。SNIPUZZ需要手动收集每个被测设备的API测试脚本，而只有少数供应商公开它们。

（2）命令覆盖率低。即使对于具有可用API测试脚本的设备，这些脚本通常也仅涵盖设备支持的一小部分命令。

（3）忽视规范中丰富的信息。SNIPUZZ没有利用模糊测试规范中的丰富信息，并且无法检测有状态或非崩溃的错误。

（4）无法处理加密消息。SNIPUZZ通过修改收集的网络消息来改变测试输入。该方法不适用于Matter使用的加密通信。

针对上述问题，作者设计了mGPTFuzz：

（1）定制设备无法获得由经过审查的供应商签署的合法证明证书。但是，控制器的证书没有被检查，因此可以构建自定义控制器，集成模糊器。这样，就可以使用控制器来测试设备，而无需依赖 API 测试脚本或配套应用程序。

（2）根据Matter规范，当控制器添加设备时，它会在设置消息中宣布设备类型以及支持的命令和属性。这样，就可以从设置消息中获取支持的命令和属性的完整列表。因此，可以获得高命令覆盖范围。

（3）鉴于冗长且包含大量详细信息的规范，作者利用预先训练的大型语言模型将人类可读的内容转换为机器可读的信息，从而指导模糊测试。

（4）作者不会为了模糊测试而改变网络消息，而是修改控制器的代码以生成明文的测试消息，然后将其加密并发送到设备。此外，作者在运行自定义控制器的计算机中配置一个 Thread边界路由器。这样，控制器就可以测试Thread设备以及WiFi和以太网设备。

三、概述

mGPTFuzz的架构如图2所示。它包含以下主要组件。

（1）自定义Matter控制器调试Matter设备，向其发送测试消息并接收响应。 

（2）当Matter设备被调试时，它会生成一系列设置消息。功能提取器组件从这些消息中了解设备的功能，例如支持的命令和属性。

（3）通过提示工程，利用LLM将Matter规范转换为知识库。 

（4）根据丰富的模糊测试策略，模糊测试变异器生成测试消息。 

（5）设备状态监视器监视物联网设备以捕获错误和漏洞，并将结果用于进一步指导模糊测试。

图 2  mGPTfuzz的主要架构

1．学习Matter设备的功能

（Learning Functionality of Matter Devices）

Matter规范分为两部分：Matter核心规范和Matter应用集群规范。前者提供用于建立和维护通信的基础集群（例如组密钥管理和网络诊断集群）的信息。后者提供有关应用程序集群的信息，详细说明设备如何通过特定应用程序数据和命令进行交互。

一个集群代表一组相关的功能，并具有唯一的2字节集群标识符（CID）。所有可用集群的列表可以在两个Matter规范中找到。

提取支持的设备集群：当Matter 设备连接控制器时，会生成一系列设置消息，其中包含有关设备的丰富信息，包括设备 ID、制造代码和支持的集群。根据报告的信息并根据两个 Matter 规范，可以了解设备支持的功能，并确定（1）哪些命令可以控制该设备，以及（2）设备支持哪些属性。

2．使用LLM提取知识库

（Learning Knowledge Base via LLM）

从规范中提取与命令和属性相关的信息（Information Extraction）

作者采用了三种方法通过LLM提取准确、稳定的信息：

（1）采用temperature=0：目标是获取从 Matter 规范中提取的事实信息，此设置确保LLM严格遵循源材料的事实性质来提取知识，在不同的查询中提供稳定且一致的信息。

（2）采用上下文中的小样本学习（In-context few-shot learning）：确保LLM提取的信息准确并遵循指定的输出格式。上下文中的小样本学习是一种有效的策略，通过用少量说明所需输入和输出的示例来增强上下文，从而提高模型的准确性。这种方法丰富了LLM的背景，使他们能够更好地理解提示的语法、识别输出模式并准确地提取信息。通过采用这种技术，作者通过示例指导LLM以所需的格式准确提取有用的信息。

（3）采用自我一致性检查：完善和验证生成的响应，确保结果的可靠性。即使采用上述方法，模型仍然可能输出包含一些随机信息的答案，尽管这种情况很少见。作者与LLM进行了多次对话，并将大多数一致的答案视为最终结果。

规范划分：由于GPT-4的token限制，作者无法将整个规范提供给它。作者注意到每个集群对应于规范中的一章。因此，将规范的集群描述部分分成多个部分，每个部分对应一个集群。然而，在2023年11月延长token限制之前，一个跨越67页的长集群DoorLock超出了token限制。因此，作者进一步对DoorLock集群的内容进行分段，并逐一查询每个分段的信息。然后，将响应连接起来。

提示词：数据类型有两种类型：（1）基本数据类型，例如uint、int和bool，以及（2）派生数据类型，从基本数据类型派生。

基本数据类型是所有集群共享；因此，只需要对所有26 种基本数据类型进行一次查询，而不是对每个集群进行一次查询。图3显示了查询基本数据类型及其对应值范围的提示。

图 3 查询基础数据类型的提示词

图4显示了查询每个集群信息的提示词模板，包括集群文本、查询和示例输出。每个集群单独查询，并通过使用脚本组装提示模板来自动生成提示。给定一个集群，集群文本是从规范中的章节转换而来的。具体来说，作者使用光学字符识别工具将PDF格式的规范转换为文本。

图 4 查询每个集群信息的提示词模板

响应：图5显示了OnOff集群的示例响应，其中包括五条信息（对应于提示中的五个查询）。具体来说，该集群有一种派生数据类型、六个命令和五个属性。对于每个命令，都会提取其参数、相应的数据类型和命令 ID。对于每个属性，还会提取其数据类型和 ID。

图 5 大语言模型关于onoff集群的响应

使用LLM生成FSM（FSM Generation）

FSM是一个元组 (Q,Σ,Δ,δ)，其中Q表示有限状态集，Σ表示初始状态，Δ表示目标状态，δ表示可以将Σ映射到Δ的命令。给定一个集群，作者对每个命令进行查询，并生成特定于该命令的FSM。之后，所有FSM组合起来形成代表整个集群的综合FSM。

图6显示了用于查询命令（使用命令ID指定）的有用信息以生成FSM的提示模板。在这个过程中：

（1）应用上下文少样本学习，如图6的Shot 1部分所示；

（2）提供了有关基本数据类型的数据类型知识（通过图3中基本数据类型的提取）和与集群相关的派生数据类型（通过图4中的查询1）。这使得LLM能够准确理解思想链过程第二步中的数据范围；

（3）利用思想链提示来确保LLM提取信息的准确性（见图6中的思想链部分）。思维链提示涉及构建提示来指导LLM完成一系列逻辑步骤，类似于人类的思维过程，以达到所需的输出。当简单的问答格式可能无法产生全面的结果时，这种技术在复杂的情况下被证明特别有效。

（4）利用自我一致性检查来增强响应的可靠性。

即使采用设置temperature=0等方法来防止随机性和创造性，仍然存在以下罕见情况：1）LLM 可能会产生格式与Shot 1不一致的响应，2）LLM 在以下情况下伪造信息：提供的集群文本不包含与查询相关的信息。作者将第一个问题归因于输出的复杂性。为了确保 LLM 响应遵循所需的格式，作者在提示末尾添加“所需的输出格式”部分。为了解决第二个问题，作者强调不要编造信息，如图6第一段的最后一句所示。

图 6 生成FSM的提示词模板

通过这些提示设计方法，作者能够有效地获取FSM信息。在为集群内的每个命令生成 FSM后，作者将所有FSM合并为代表该集群的综合FSM。生成了52个 FSM，总共有521 个状态和522个转换。对于52个FSM，状态数在[1, 46]范围内，边数在[1, 50]范围内。

例子：图7显示了生成的 FSM 的一部分，它是通过合并与LevelControl集群内的所有命令相对应的多个FSM来实现的。此示例包含10个状态和13个边。每条边都包含有关状态转换过程的详细信息，包括命令名称以及每个参数的可能值和数据类型。

 

图 7 LevelControl集群生成的FSM

 

验证 FSM 的质量：除了使用多个查询进行自我一致性检查之外，作者还手动验证FSM 的质量。首先从522 个转换中随机抽取100个样本。三位作者总共花费了9个小时手动独立检查100个转换中描述的信息的准确性。作者确认所有信息都是准确的。然后作者选择一个集群LevelControl，并检查FSM是否涵盖了规范中描述的所有转换，结果是肯定的。检验表明LLM能够准确提取FSM信息。

 

 

 

3．模糊测试策略

（Fuzzing Policies）

模糊器迭代FSM以生成测试输入。使用以下策略：

策略1：对于每个FSM边， (a) 作者将参数值更改为边指定的值； (b) 如果有效参数值是一个范围，请提供极值（例如有效范围的最小值和最大值）； (c) 提供排除极值的随机有效值。此外，对于每个命令，（d）作者更改字符串类型参数的长度，试图触发缓冲区溢出； (e) 向字符串提供空值以触发未初始化的读取或空指针引用； (f) 向数组、集合或包提供 NULL 或仅一个元素，以导致空指针引用或越界访问。

策略2：改变参数类型。给定一个假定数据类型为 t 的参数，作者将其类型更改为随机选择的类型 t′。

策略3：更改参数数量。对于需要n个参数的命令，作者提供n + 1、n − 1或0个参数。

策略4：尝试不受支持的集群和命令。除了支持的集群之外，作者还随机选择一些不支持的集群。对于选定的不受支持的集群中的每个命令，作者都会按照命令定义生成测试消息。通过这个策略，作者检查意外的命令是否会导致设备崩溃。

4．构造测试消息

（Constructing Test Messages）

要在给定命令的情况下构建测试消息，一种简单的方法是在调用该命令的控制器中调用API。然而，此类API包含各种输入清理。因此，无法构建无效的测试消息。

为了解决这个问题，作者的解决方案是找到打包消息的过程，称之为message packing procedure。每个API都会调用它来生成要发送到 IoT 设备的消息。然后，作者删除包装程序中的输入清理。

有两种类型的命令：

• 普通命令：每个集群包含零个或多个普通命令。控制器chip-tool中的打包过程 InteractionModelCommands::SendCommand 用于生成此类命令。  
• Write-Attribute 可以修改指定的集群属性：控制器chip-tool的打包过程InteractionModelCommands::WriteAttribute 用于生成此类命令。

5．设备状态检测

（Device State Monitor）

（1）崩溃错误：从mGPTFuzz的角度来看，检测设备崩溃是微不足道的，因为崩溃会导致断开连接（以及下一个测试消息的超时异常）。

（2）非崩溃错误：对于每个测试消息，如果响应消息和目标状态（就所涉及的属性值而言）不遵守FSM中描述的转换，则捕获非崩溃错误。具体来说，给定有效的测试消息（即有效的命令/属性ID和参数值），控制器期望来自被测设备的响应消息SUCCESS，并且还通过查询描述状态的属性来检查目标状态。给定一个无效的命令，它需要一条错误消息，例如 INVALID_COMMAND。

（3）有状态错误：如果只有当设备处于某些状态时才能重现症状，则它是一个有状态错误。

（4）无状态错误：反之，就是无状态的。

四、评估

1．实验设置

实现：作者实现了mGPTFuzz的原型。

（1）利用Matter Consortium提供的开源工具chip-tool来构建定制控制器。在消息打包过程中删除了输入清理，这样测试输入就不会因为清理而被拒绝。该控制器能够使用chip-tool code-wifi pairing脚本来调试Matter-over-WiFi和Matter-over-Ethernet设备。为了支持 Thread 无线电通信功能，作者将nRF52840 Micro Dev Kit USB Dongle插入桌面计算机。此外，作者安装了ot-br-posix库，它将桌面计算机变成了 OpenThread边界路由器（OTBR）。随后，作者的自定义控制器能够使用chip-tool code-thread pairing脚本来调试Matter-over-Thread设备。

（2）LLM：GPT-4-Turbo，temperature=0。

（3）要对设备进行模糊测试，唯一的手动操作是将其与mGPTFuzz配对。

环境：

（1）测试的Matter设备：从线上和线下市场采购了23种流行的消费者Matter IoT设备，涵盖Philip Hue、Yeelight、Yale等多个品牌。Matter设备的类型包括智能开关、插头、照明、储物柜、传感器和集线器。

（2）测试环境：配备4.9 GHz Intel® Core(TM) i7 CPU和32 GB RAM的Ubuntu 20.04 PC。

Baseline：SNIPUZZ。（1）排除了IoTFuzzer和Diane，因为它们从配套应用程序发送测试输入，而Matter设备无法通过设备的配套应用程序进行控制。（2）排除了HubFuzzer，因为它仅测试ZigBee和ZWave设备。（3）排除了非开源的模糊器。因此，作者选择了 SNIPUZZ 进行比较。选择SNIPUZZ的另一个原因是因为 SNIPUZZ 的评估表明它优于之前的工作，例如NEMESYS、BooFuzz和DooNA。

2．崩溃发现结果

作者将错误分为两类：（1）崩溃错误，会导致设备崩溃；（2）非崩溃错误，会导致不正确的行为，但不会导致设备崩溃。

从23个Matter设备中，作者发现了147个错误，其中包括5个崩溃错误和142个非崩溃错误。在这147个错误中，有10个有状态错误，其中4 个有状态崩溃错误和6个有状态非崩溃错误。无论当前设备状态如何，都可以触发其他137 个错误。详细结果如表1所示。在147个错误中，有61个错误导致拒绝服务，即设备崩溃（CVE-2023-45955 和 CVE2023-45956），或者直到重新配对后才响应控制器 (CVE-2023-42189)。鉴于DoS性质，作者将这61个错误归类为漏洞。

表 1 mGPTFuzz 检测到的错误。(1) UT 代表 Unexpected Transition，意思是设备转变到意外状态。 (2) DoS 是指拒绝服务。模糊测试时间主要由设备支持的命令和属性的数量决定。

崩溃错误：

已识别的5个崩溃 bug如下：

• 设备Nanoleaf Lighting NF080K03-2LS（设备ID = 4）中存在一个崩溃错误，已分配CVE-2023-45955。
• Govee Lighting H61E1（设备ID = 10）存在4个崩溃错误，这些错误都是有状态错误，需要将设备设置为要触发的特定状态。这些错误已分配为CVE-2023-45956。

请注意，为了节省CVE资源，如果设备存在与一组相似命令或漏洞利用消息相关的多个错误，则仅请求一个CVE。

表2总结了这些错误的详细信息。隐藏API意味着供应商的API测试脚本中未涵盖该命令或属性，也未在其网站中进行描述。

表 2 检测到的崩溃错误的详细信息

 

非崩溃错误：

mGPTFuzz从23个Matter设备中发现了142个非崩溃错误，其中6个是有状态的非崩溃错误。与崩溃错误相比，检测非崩溃错误提出了更大的挑战，因为可用作崩溃错误检测线索的网络连接状态对于检测非崩溃错误没有用处。

作者发现两种类型的非崩溃错误：N1）设备应拒绝相应的漏洞利用消息但接受并处理它们的错误；N2）设备应该接受相应的漏洞利用消息但错误地拒绝它们的错误。两种类型的非崩溃错误在测试设备上的分布如表3所示。

表 3 非崩溃错误

 

表4总结了非崩溃错误案例的详细信息：

（1）两个N1型的非崩溃错误影响所有Matter设备，如表4所示（设备ID标记为All）。这些错误已分配为CVE-2023-42189。它们不是有状态的错误，因此可以在任何设备状态下触发。这两个错误都与隐藏命令KeySetRemove (uint16) 有关。

（2）作者在设备Govee Lighting H61E1（设备ID=10）中发现了6个N1型的有状态非崩溃错误。这些非崩溃错误与三个隐藏命令（MoveHue、MoveSaturation、EnhancedMoveHue）有关。

（3）作者在Orein Bulb OS0100811267（设备ID = 3）和Linkind Bulb LS0101811266（设备ID=11）这两台设备中各发现一个N2型非崩溃错误。此错误与隐藏命令MoveColor(int16, int16) 有关。

表 4 一些检测到的非崩溃错误案例

 

3．与Baseline方法的对比

为了公平比较，作者扩展了SNIPUZZ的功能。（1）SNIPUZZ 集成到自定义控制器中，因此纯文本消息会呈现给SNIPUZZ。这样，它能够测试始终使用加密通信的Matter设备。（2）向其提供隐藏命令。

详细内容如下所述：

（1）SNIPUZZ旨在检测崩溃错误，无法检测非崩溃错误。因此，作者比较了SNIPUZZ和mGPTFuzz之间的崩溃错误检测性能。作者使用增强型SNIPUZZ（即扩展后）来测试所有 23个Matter设备。然而，在对每台设备进行24小时的模糊测试后，SNIPUZZ没有发现任何错误。

（2）SNIPUZZ需要物联网设备的API测试程序来收集种子消息，并且只能测试API测试程序涵盖的命令。因此，它无法检测到由隐藏命令触发的崩溃错误，其中包括mGPTFuzz 检测到的所有5个崩溃错误。

（3）如果向SNIPUZZ提供相应的隐藏命令，它是否可以检测到这些错误：对于每个发现的崩溃错误，作者都会向SNIPUZZ提供一条与涉及此错误的隐藏命令相关的消息。然后，使用SNIPUZZ的片段确定算法来对这些消息进行分区。结果显示SNIPUZZ无法准确确定其中任何一个的片段。

（4）作者进一步研究了SNIPUZZ的片段确定算法，并得到了以下发现：Matter协议要求Matter消息的有效负载遵循JSON格式。然而，由于SNIPUZZ将消息中的字节一一删除来生成探测消息，这导致探测消息不遵循JSON格式。

4．效率

在表1的最后一列中，作者展示了mGPTFuzz测试每个设备所花费的总时间。对于ID = 7的设备，最长测试时间约为5小时。

以两台设备为例，通过随时间发现的错误数（Y 轴）和测试消息数量（X 轴）来说明模糊测试效率。如图8所示，mGPTFuzz可以高效地发现崩溃错误和非崩溃错误。对于图8(a)所示的设备Nanoleaf Lightstrip NF080K03-2LS，所有错误均在110分钟内发现且测试消息≤3100条，并且第一个错误在10分钟内发现。对于图8(b)所示的设备Eve Motion Sensor 20EBY9901，所有四个错误都在90分钟内被发现，且测试消息数≤1200条。

图 8 测试效率结果，红点代表崩溃错误，绿点代表非崩溃错误

五、讨论

影响：mGPTFuzz仅限于模糊测试Matter设备。然而，考虑到Matter的重要性，付出的努力是值得的。此外，LLM辅助的黑盒模糊测试方法可以推广到其他可用规范的场景，例如Zigbee、Thread 和蓝牙。

道德考虑和主动危害预防：作者已就其产品的错误和漏洞联系了所有供应商。作者已向Matter SDK开发人员报告了该漏洞 (CVE-2023-42189)，因为它会影响所有Matter设备。它已在Matter V1.1中修复。联系他们后，作者至少等待了90天才报告漏洞并进行 CVE分配。

Matter在Apache 2.0许可证下发布，允许多种用途。该规范可在官方网站上公开访问。根据ChatGPT的指示，ChatGPT不会使用其业务产品（例如ChatGPT Team或ChatGPT Enterprise）中的内容来训练其模型。作者在整个研究过程中使用了 ChatGPT Team。因此，使用ChatGPT的方法不会引起道德问题。

六、总结

作为全行业的物联网标准，Matter有望彻底改变智能设备的生态。因此，Matter设备的模糊测试是一个新兴的重要问题。作者提出了文献中的第一个Matter模糊器。利用大型语言模型将超过一千页的人类可读规范转换为有限状态机（FSM）形式的机器可读信息。在FSM的指导下，作者的黑盒模糊测试能够发现有状态错误和非崩溃错误，以及崩溃错误。作者已经构建了mGPTFuzz原型并进行了涉及23个Matter设备的广泛评估。它发现了147个新错误，其中包括61个零日漏洞并分配了3个CVE。

原文始发于微信公众号（FuzzWiki）：mGPTFuzz：大型语言模型辅助Matter物联网设备模糊测试