模糊测试如何加强物联网设备的安全性

模糊测试是工程师发现嵌入式弱点的一个重要场所。设备，应考虑用于强化物联网设备接口。

随着物联网设备的激增，嵌入式安全攻击也随之增加。从历史上看，尽管嵌入式设备的许多领域都容易受到错误的影响，但嵌入式系统工程师忽略了设备层的安全性。串口、无线电接口，甚至编程/调试接口都可以被黑客利用。模糊测试是工程师发现嵌入式设备弱点的重要场所，应考虑用于强化物联网设备接口。

什么是模糊测试？

模糊测试就像神话中的百万只猴子随机打字写莎士比亚。在实践中，小说作品需要很多随机组合来产生一个简单的短语，但对于嵌入式系统，我们只需要从一个已知的好句子中改变几个字母即可。

许多商业和开源工具可用于实施模糊攻击。这些工具生成随机字节串，也称为模糊向量或攻击向量，并将它们提交给被测试的接口，跟踪可能表示错误的结果行为。

模糊测试是一个数字游戏，但我们不能尝试无限多个可能的输入。相反，我们专注于通过最大化模糊向量提交率、模糊向量的有效性和错误检测算法来优化测试时间。

模糊测试概念

由于许多模糊测试工具旨在测试 PC 应用程序，如果您将嵌入式代码作为本机编译的 PC 应用程序运行，则更容易调整它们。在 PC 上运行嵌入式代码会产生巨大的性能优势，但有两个缺点。首先，PC 微处理器的反应与嵌入式微控制器不同。其次，我们必须重写任何涉及硬件的代码。但是，在实践中，在 PC 上运行的优点大于缺点。真正的障碍是很难将代码移植到 PC 上进行本地编译。

我们如何知道模糊向量何时触发错误？崩溃很容易被发现，但很难识别导致重置的模糊向量。内存溢出错误或杂散指针写入（对黑客来说最有价值的错误类型）几乎不可能从系统外部辨别出来，因为它们通常不会导致崩溃或重置。

许多现代编译器，例如 GCC 和 Clang，都具有称为内存清理的功能。这将内存块标记为干净或脏，这取决于它们是否在使用中，并标记任何访问脏内存的尝试。但是，内存清理会消耗闪存、RAM 和 CPU 周期，因此难以在嵌入式设备上运行。因此，相反，我们可能会测试一部分代码，构建具有更多资源的设备版本，或者使用 PC。

测试的有效性可以通过执行的代码量来评估。在这里，编译器也可以通过使用面包屑子例程调用来跟踪内存使用情况。代码覆盖库为每个代码路径维护一个使用值表，并在面包屑执行时增加它们。

然而，对于嵌入式模糊测试，代码覆盖率数字很难解释，因为模糊向量无法访问大部分代码；例如，独立于接口运行的外设的设备驱动程序。因此，很难为嵌入式系统定义“完整的代码覆盖率”——也许只有 20% 的嵌入式代码是可访问的。代码覆盖率还会消耗大量闪存、RAM 和 CPU 周期，并且需要专门的硬件或 PC 目标才能运行。

错误报告

当模糊测试发现导致不良行为的向量时，我们需要详细信息。错误发生在哪里？调用堆栈的状态是什么？错误的具体类型是什么？所有这些信息都有助于分类并最终修复错误。

错误分类在模糊测试中至关重要。新的 fuzz 项目经常会发现很多 bug，我们需要一种自动的方法来确定它们的严重性。此外，模糊错误往往会阻塞错误，因为它们通常会掩盖代码路径下的其他错误。我们需要快速解决模糊测试期间出现的问题。

嵌入式客户端不像 PC 那样愿意透露他们的信息。通常，崩溃只会导致设备重置和重启。虽然这在现场是需要的，但它会擦除设备的状态，因此很难了解是否发生了崩溃、发生的地点或原因，或者所采用的代码路径。工程师必须找到一致的再现向量，然后使用调试器跟踪不良行为并找到错误。

在模糊测试中，一个测试可能会为一些错误产生数千个崩溃向量，给人一种错误系统的错误印象。快速确定哪些向量与相同的底层错误相关是很重要的。对于嵌入式设备，崩溃本身的位置对于错误通常是唯一的，并且通常不需要找到完整的调用堆栈跟踪。

持续模糊测试

由于模糊测试的随机性，长时间运行它们会增加发现问题的机会。但是没有任何项目计划可以吸收开发结束时冗长的模糊测试周期造成的延迟。

在实践中，模糊测试将在发布过程之后在其自己的分支上开始。任何新发现的错误都将在本地分支中修复，以便测试可以继续进行，而新错误不会阻止额外的错误发现。作为发布周期的一部分，从模糊测试先前版本中发现的错误将被评估以包含在新版本中。最后，应该将发现错误的模糊向量添加到正常的质量保证流程中，以验证修复并确保这些错误不会无意中重新引入代码中。

我们应该在不同场景下对设备进行模糊测试；例如，如果联网，设备对连接请求的响应方式不同。在每个可能的场景上运行模糊测试是不切实际的，但我们可以对每个可能状态的值进行模糊测试。例如，使用每种不同的设备类型运行模糊测试，同时保持其他变量相同。然后为另一种变量运行不同的值，例如一种设备类型的网络连接状态。

模糊测试架构

两种突出的模糊测试架构是定向模糊测试，其中模糊向量由工程师在测试前指定，以及覆盖引导模糊测试，其中模糊工具从一组初始测试向量开始，并根据数据包渗透的程度自动改变它们代码。

此外，并非所有代码都可以在 PC 上运行，并且为嵌入式应用程序开发 PC 模拟器可能不切实际，具体取决于所测试的内容。

以下是四种模糊测试架构的总结：

• 嵌入式硬件上的直接接口测试——在嵌入式设备上运行正常的生产映像，并通过接口注入模糊数据包
• 数据包（堆栈）注入测试——直接调用传入的数据包例程，而无需通过空中执行接口
• 使用模拟器进行定向模糊测试 - 使用基于 PC 的模拟技术来开发和测试嵌入式代码
• 使用模拟器进行覆盖率引导的模糊测试（如下所示为 Libfuzz）

多个模糊测试人员

在使用调试接口锁定和安全启动锁定嵌入式设备后，我们需要考虑对设备接口进行模糊测试。许多用于保护网络服务器的工具和概念都可以适用于嵌入式设备。

为工作使用正确的工具。 Coverage-guided fuzzing 对于连续模糊测试是必要的，但如果您的代码只在嵌入式硬件上执行，定向模糊器可能是提供某种程度的模糊测试覆盖率的不错选择。

最后，您应该在尽可能多的场景中使用多个模糊测试人员，因为每个人对设备的测试都会略有不同，从而最大限度地提高覆盖范围，从而提高嵌入式设备的安全性。

>> 本文最初发表于我们的姊妹网站 EDN。