消除物联网上的缓冲区溢出漏洞

在过去 30 年中，缓冲区溢出一直是网络传播攻击中最常被利用的漏洞。考虑到缓冲区的创建方式，这并不奇怪。

下面是 C 中的一个示例：

第 1 步。程序员使用 malloc 函数并定义缓冲区内存量（例如 32 字节）

第 2 步。返回一个指针，指示内存中缓冲区的开头

第 3 步。程序员在需要读取或写入该缓冲区时（仅）使用指针作为引用

有了指针，程序员很容易忘记分配给给定缓冲区的实际内存量。编译器在组装过程中使用元数据来分配适当的缓冲区大小，但此元数据通常在生成时丢弃以减少占用空间。

如果在程序内部或程序之间传输的数据随后超过最初定义的缓冲区大小，则该数据信息将覆盖相邻内存。这可能会导致内存访问错误或崩溃，以及安全漏洞。

缓冲区溢出和漏洞利用

黑客可以使用堆栈缓冲区溢出将可执行文件替换为恶意代码，从而使他们能够利用堆内存或调用堆栈本身等系统资源。例如，控制流劫持利用堆栈缓冲区溢出将代码执行重定向到正常操作中使用的位置以外的位置。

一旦负责控制流，控制流劫持者就可以修改指针并重用现有代码，同时还可能替换代码。控制流的命令还允许攻击者修改指针，以用于间接调用、跳转和函数返回，从而留下有效的图形以向防御者隐藏其操作。

尽管动态地址空间布局随机化 （ASLR） 机制和堆栈金丝雀用于在代码执行发生之前检测和防止缓冲区溢出，但此类威胁仍然是一个挑战。

安全性：软件还是芯片？

ASLR 和堆栈金丝雀是基于软件的缓冲区溢出保护机制，确实使攻击者更难利用缓冲区溢出。例如，ASLR 动态重新定位内存区域，以便黑客有效地猜测目标组件（如基本可执行文件、库以及堆栈和堆内存）的地址空间。不幸的是，最近的漏洞（如Spectre和Meltdown）泄漏了CPU分支预测器的信息，由于显而易见的原因，这限制了ASLR的有效性。

另一方面，堆栈金丝雀在内存中的返回指针之前插入小整数。在例程可以使用相应的返回指针之前，将检查这些整数以确保它们未更改。尽管如此，如果黑客确定包含正确的金丝雀值，他们还是有可能读取金丝雀并简单地覆盖它和随后的缓冲区而不会发生任何事件。此外，虽然 Canary 保护控件数据不被更改，但它们不保护指针或任何其他数据。

当然，基于软件的安全解决方案的另一个挑战是它们极易受到错误的影响。据估计，每 1，000 行代码存在 15-50 个错误，这意味着解决方案中存在的软件越多，漏洞的数量就越多。

在解决疾病而不是缓冲区溢出的症状时，更强大的方法是在硅中实现安全性 - 虽然堆栈缓冲区溢出漏洞旨在操纵软件程序，但解决此类攻击的根本原因首先要意识到处理器无法确定给定程序是否正在正确执行。

除了减轻软件错误的影响之外，硅不能远程更改。但是，必须对处理器或硅IP进行编程，以便在运行时识别尝试写入内存或外设的指令是执行合法操作还是非法操作。

Dover Microsystems开发了一种名为CoreGuard的技术。

运行时的芯片安全性

CoreGuard是一种硅IP，可以与RISC处理器架构集成，以在运行时识别无效指令。该解决方案以 RTL 形式提供，可以针对各种功耗和面积要求进行优化，也可以进行修改以支持自定义处理器扩展。

如图 2 所示，CoreGuard 架构包括一个硬件互锁，用于控制主机处理器与系统其余部分之间的所有通信。硬件互锁将这些通信汇集到策略实施器中。

另外，CoreGuard 使用称为微策略的可更新安全规则，这些规则是用高级专有语言创建的简单管理策略。这些规则安装在与其他操作系统或应用程序代码隔离的安全、无法访问的内存区域中。CoreGuard 还在此处为通常由编译器丢弃的应用程序元数据保留少量内存分配，用于为系统中的所有数据和指令生成唯一标识符。这些组件在系统引导时加载。

当指令尝试在运行时执行时，在特权模式下运行的 CoreGuard 策略执行核心或主机处理器会根据定义的微策略交叉引用指令的元数据。硬件联锁确保处理器仅向内存或外设输出有效指令，从而防止无效代码完全执行。应用程序会收到类似于被零除错误的策略冲突通知，并通知用户。

与主机处理器集成以支持指令跟踪输出、失速输入、不可屏蔽中断 （NMI） 输入和中断输出所需的一切。对于非芯片设计人员，Dover Microsystems最近宣布其CoreGuard技术正在设计用于某些NXP处理器。

消除各类攻击

在缓冲区溢出的情况下，像CoreGuard这样的技术的好处是显而易见的。可以合并作为经常丢弃的编译器元数据的一部分捕获的缓冲区大小，以限制攻击者从整个网络操纵系统堆栈的能力。更进一步，相同的原则可以应用于一般的控制流劫持，因为从内存中各个点返回可以在它们发生之前受到限制。

在实践中，这种实时感知也为安全行业创造了新的竞争环境。通过能够在损坏发生之前识别错误或攻击，用户可以选择动态重新分配内存，切换到单独的，更安全的程序或记录事件，同时继续运行相同的程序。如何进行完全取决于应用程序或业务案例的需求。

我们是否看到了零日漏洞的终结？只有时间会证明一切，但似乎我们走在正确的道路上。

审核编辑：郭婷