通过分析可执行文件提高可靠性和安全性

当今可用的许多源代码分析工具，包括 Coverity Prevent、GrammaTech CodeSonar、Klocwork K7 和 MathWorks PolySpace Verifier，可检测软件缺陷和漏洞。在过去的几年里，对可执行机器代码进行类似分析的兴趣越来越大。三个主要因素推动了对直接机器代码分析的兴趣：控制 COTS 软件可靠性和安全性的需要、相对于源代码分析的技术优势，以及最近其可行性和实用性的增加，这些已被研究的突破所证实社区。David 探讨了机器代码分析的优势并总结了当前的技术水平。

收回对应用程序可靠性和安全性的控制

上市时间和成本要求增加了开发人员在嵌入式软件应用程序中使用 COTS 组件的情况。虽然这些组件具有优势，但它们的代价是一些公认的缺点。特别是，消费者通常必须接受软件，“按原样”，并相信生产者已采取必要措施来确保安全性和可靠性。不幸的是，经验表明情况并非总是如此。

消费者如何知道 COTS 组件是否具有满足其需求的可接受的安全性和可靠性？一些 COTS 组件提供了一些关于所遵循的开发和测试过程的信息。示例包括一些实时操作系统 （RTOS），它们提供文档以帮助航空电子软件开发人员完成 DO-178B 认证过程。但即使在这些不寻常的情况下，通常也只有 RTOS 的精简功能版本有据可查。对于大多数第三方组件，没有关于开发和测试过程的信息可用。

对于开发安全或高可靠性应用程序的组织而言，无法评估第三方组件的质量是一个重大问题。毫不奇怪，最早支持开发更好的可执行文件分析技术的人之一是国家安全局，它在 2004 年公开强调了分析二进制文件的工具的重要性。特别值得关注的是用于国家关键基础设施的软件，例如应急准备通信和发电厂。

机器代码分析提供了一种评估第三方代码的方法，即使源不可用。检测缺陷、漏洞和故意插入的恶意代码的能力使用户能够重新获得一些控制权来确定一个软件是否符合他们的接受标准。用户不必盲目信任软件生产者。

机器码分析的技术优势

COTS 软件通常不提供源代码，因此需要进行机器代码分析。事实上，即使源代码可用，机器代码分析也比其他分析技术具有许多优势。这是因为源代码没有被执行；相反，它被编译成机器代码程序（可执行文件）。分析用解释性语言编写的程序是另一回事，尽管在那里，源代码也不是直接在处理器上执行的。

由于多种原因，源代码语义和编译后的可执行语义之间可能存在差异。这种潜在的不匹配被称为“你所看到的不是你所执行的”（WYSINWYX）效应。WYSINWYX 承认，鉴于过程中实际执行的内容，源代码中的语义可能不完整或不精确。

WYSINWYX 效果可能由多种因素引起，包括编译器错误和链接第三方库。图 1 说明了原始程序的含义如何随着在最终可执行文件创建之前添加模块而发生变化。

图1

在 2002 年 Microsoft的一次安全审查中发现了一个引发 WYSINWYX 效应的编译器错误示例。在这种情况下，登录程序的源代码中出现了如下代码：

memset（密码，，Äò\0，Äô， len）;

免费（密码）；

如其名称所示，缓冲区密码用于保存用户的密码。作为安全预防措施，程序员希望尽量减少这些敏感信息在内存中的保存时间。因此，在释放缓冲区（第 2 行）之前，目的是用零覆盖敏感密码（第 1 行）。

但是，在这种情况下，Microsoft C++ 编译器确定密码归零语句是“无用”，并将其删除。从技术意义上说，编译器是正确的：memset 写入的零不应该被任何其他语句读取，并且删除 memset 不会影响程序的结果。然而，优化导致了源代码中不可见的安全漏洞。

每一个潜在的 WYSINWYX 效果都强调了机器代码分析工具，Äô 优于源代码分析工具的优势。上一节讨论了无法访问程序源代码的问题。然而，即使是拥有源代码的开发人员也很少拥有最终包含在可执行文件中的所有代码的源代码。通常，他们将其源代码链接到仅以二进制形式存在的第三方库。特别是在嵌入式软件中，源代码可能包括内联汇编。在某些情况下，会在编译源代码后对可执行文件进行修改。源工具通常针对以一种语言编写的程序，但可执行文件可以从多种不同语言的源代码编译。

WYSINWYX 效应最突出的原因之一是源语言语义通常未指定。例如，C 和 C++ 没有指定函数调用参数的求值顺序。（Scott Meyers的 Effective C++ 中的示例请参见侧边栏。）从技术上讲，由于源语言歧义导致的问题在源代码中是可见的。然而，分析一个模棱两可的陈述的所有可能行为很快就会变得棘手。出于这个原因，源代码分析工具（通常是程序员）通常通过任意选择一种合理的解释来解决歧义。由于无法保证他们的选择与编译器相同，因此语言歧义被认为是 WYSINWYX 效应的主要原因。

编译器为解决源语言歧义所做的选择可能会对漏洞的存在产生重要影响。安全漏洞经常依赖于数据对象布局、堆栈中变量的顺序、值是存储在 RAM 中还是仅存储在寄存器中等细节。在像 C 或 C++ 这样的语言中，这些细节中的大部分都由编译器自行决定。

源代码分析工具不能考虑编译器可能选择的所有不同选项，至少在没有做出模糊近似的情况下不能考虑。然而，机器代码分析具有查看编译器做出的确切决定的优势。出于这个原因，机器代码分析有可能比源代码分析更精确。

机器码分析的最新进展

研究人员在将静态分析应用于机器代码方面取得了长足的进步。几个小组已经证明了机器代码分析在识别恶意代码、安全漏洞和影响可靠性的缺陷方面的实用性。

机器代码分析的一种用途是创建捕获程序语义的中间表示 （IR）。用于查找错误和安全漏洞的源代码分析工具通常依赖于源代码中现成的信息（例如类型），而不是机器代码。IR 恢复的目标是填补这一空白，并允许开发人员在机器代码上使用源分析技术。与开发专门技术或一次采用一种源分析技术相比，IR 恢复可以同时启用多种技术。

CodeSurfer/x86 是从可执行文件中恢复 IR 的一种高级工具，它是 GrammaTech 和威斯康星大学合作研究的成果。对于需要了解一段恶意代码的潜在影响的安全分析师来说，CodeSurfer/x86 是一个很有价值的工具。虽然该工具目前支持 x86 机器代码分析，但支持其他处理器架构的工作正在进行中，包括 PowerPC 架构和 ARM。它的目的是构建一个类似于编译器或源分析工具使用的 IR。具体来说，恢复的 IR 代表以下信息：

拆解清单

控制流图，解决了间接跳转

调用图，解决了间接调用

关于程序的信息，Äôs 变量

指针变量的可能值

每个控制流图节点的已使用、已终止和可能已终止的变量集

数据依赖关系，包括涉及内存访问的指令之间的依赖关系

类型信息（例如，基类型、指针类型和结构）

CodeSurfer/x86 从在 Intel x86 处理器上运行的可执行文件执行 IR 恢复。IR 可用作构建进一步分析以查找错误和漏洞的基础，或用于浏览 GUI 界面。图 2 显示了臭名昭著的 Nimda 病毒版本的恢复 IR。可视化的 IR 组件包括反汇编列表、所选程序点的可能数据值和调用图。

图 2

许多因素会使 IR 恢复复杂化。CodeSurfer/x86 不依赖符号表或源代码信息，因为这些信息通常从 COTS 产品中剥离。即使存在此信息，它在潜在的恶意代码中也不可靠。恢复有关潜在指针值的信息需要同时分析指针和数值，因为地址值和数值不容易区分。必须根据数据访问模式推断类型信息，因为没有可用的结构化数据类型。

尽管执行 IR 恢复有困难，但该技术已经发展到足以开始产生结果。Balakrishnan 和 Reps 最近在 Windows 设备驱动程序分析中展示了 IR 恢复的使用。他们发现 CodeSurfer 的 IR 恢复在设备驱动程序上产生了精确的结果，并证明通过在恢复的 IR 上进行构建，他们可以采用一种分析设备驱动程序源代码的技术来分析机器代码并复制一些相同的结果。分析机器代码也有助于解决前面讨论的所见即所得问题。

满足安全关键需求

机器代码分析已经在识别软件中的错误和安全漏洞以及帮助用户评估第三方代码方面发挥着重要作用。预计安全关键软件生产商将开始对他们自己的软件使用机器代码分析来解释所见即所得效应。不断增长的需求和不断增加的工具支持和功能将继续推动机器代码分析的增长。

审核编辑：郭婷