在过去N年里，缓冲区溢出一直是网络攻击中最常被利用的漏洞。 看一下缓冲区是如何创建的，就能知道原因所在。
下面是C语言的一个例子:
第一步，程序员使用 malloc 函数并定义缓冲区内存的数量(例如32位)
第二步，返回指针，指示内存中缓冲区的开始位置
第三步，当程序员需要读取或写入该缓冲区时，程序员都会使用该指针
有了指针，程序员很容易忘记分配给指定缓冲区的实际内存量。编译器在程序中使用元数据来分配适当的缓冲区大小，但是这个元数据通常在构建时被丢弃了。
如果在程序内或程序之间传输的数据随后超出原定义的缓冲区大小，则数据信息将覆盖相邻的内存。这会导致内存访问错误或崩溃，以及安全漏洞。
缓冲区溢出和漏洞利用
黑客可以使用堆栈缓冲区溢出替换带有恶意代码的可执行文件，这样他们就可以利用系统资源，比如堆内存或者调用堆栈的本身。例如，控制流劫持利用堆栈缓冲区溢出，将代码执行重定向到正常操作中以外的位置。
图1 控制流劫持
一旦掌握了控制流程，一个控制流程的劫持者可以修改指针和重用现有代码，同时还可能替换代码。控制流的命令还允许攻击者修改用于间接调用、跳转和函数返回的指针，这些指针会留下一个有效图来隐藏它们的行为。
在发生代码执行之前，动态位址空间配置的随机载入(ASLR)机制和用于检测并防止缓冲区溢出的堆栈金丝雀，这些仍然是一个挑战。
安全: 软件还是芯片负责？
ASLR和堆栈金丝雀是基于软件的缓冲区溢出保护机制，这些机制确实使攻击者更难利用缓冲区溢出。例如，ASLR，动态地重新定位内存区域，以便黑客有效地猜测目标组件的地址空间，如基础可执行文件、库、堆栈内存。不幸的是，最近像 Spectre 和 Meltdown 这样的漏洞泄露了CPU分支预测器的信息，这些明显的原因限制了ASLR的有效性。
另一方面，堆栈金丝雀在内存中的返回指针之前插入小整数。检查这些整数以确保它们没有改变，一个进程就可以使用相应的返回指针。尽管如此，如果黑客们确信包含了正确的金丝雀值，那么黑客们还是有可能读懂这些金丝雀，然后简单地重写它以及随后的缓冲区。此外，虽然金丝雀保护控制数据不被更改，但它们不能保护指针或任何其他的数据。
当然，基于软件的安全解决方案的另一个挑战是，它们极易受到漏洞的影响。据不完全统计，每1000行代码中就有15-50个漏洞，这意味着解决方案中存在的软件越多，漏洞的数量就越大。
当处理这种问题而不仅仅是缓冲区溢出的症状时，一个更加健壮的方法是在芯片中实现安全性，而堆栈缓冲区溢出开发是为了操纵软件程序。了解这类攻击的根本原因，首先要认识到处理器无法确定某个程序是否正确执行。
除了减轻软件缺陷的影响之外，芯片不可能被远程改变。但是一个处理器或者一块芯片必须在运行时识别试图写入内存或外围设备的指令是合法执行还是非法操作。
运行时的芯片安全性
Dover Microsystems 开发了一种叫做 CoreGuard 的技术，这是一个可以与RISC 处理器架构集成在一起的IP core，用于在运行时识别无效的指令。作为RTL交付，解决方案可以针对各种功率和区域需求进行优化，或者修改并支持自定义的处理器扩展。
图2 CoreGuard的体系结构
如图2所示，CoreGuard 体系结构包括一个硬件关联锁，控制主机处理器和系统其他部分之间的所有通信。硬件连接将这些通信汇集到一个政策执行者。
另外，CoreGuard 使用称为micropolicy 的可更新安全规则，这些规则是在高级别专有语言中创建的简单管理策略。 这些规则安装在一个安全的、无法访问的内存区域，与其他操作系统或应用程序代码隔离开来。此外，CoreGuard 还为编译器通常丢弃的应用程序元数据保留一个小的内存分配，用于为系统中的所有数据和指令生成唯一的标识符。这些组件在系统启动时加载。
当一个指令试图在运行时执行的时候，CoreGuard策略执行核心或主机处理器在特权模式下运行时，将指令的元数据与定义的micropolicy交叉引用。 硬件交互只能确保处理器输出有效的内存或外设指令，从而防止无效代码的执行。应用程序会被告知类似于一个零除错误的策略违规，并通知用户。
与主机处理器集成，支持指令跟踪输出、失速输入、非可屏蔽中断(NMI)输入和中断输出所需的所有功能。对于非芯片设计者来说，其CoreGuard技术正被某些 NXP 处理器所设计采用。
消除各种攻击
在缓冲区溢出的情况下，像 CoreGuard 这样的技术的好处是显而易见的。作为经常丢弃的编译器元数据的一部分而捕获的缓冲区大小可以被合并，以限制攻击者在网络上操作系统上访问堆栈的能力。进一步说，同样的原理可以应用于一般的控制流劫持，因为来自内存中不同点的返回值可以在发生之前受到限制。
实际上，这种实时意识也为安全行业创造了一个新的竞争环境。通过在损坏发生之前识别错误或者攻击，用户可以选择动态地重新分配内存，在继续运行相同程序的同时切换到单独的、更安全的程序或日志事件。如何执行代码完全取决于应用程序或业务案例的需要。
何时才能看到zero-day 漏洞的终结呢？！
（本文编译自 http://www.embedded-computing.com/iot/eliminating-buffer-overflow-vulnerabilities-on-the-iot）
