【翻译】动态完整性度量和证明：防御面向返回的编程攻击——Dynamic Integrity Measurement and Attestation...

动态完整性度量和证明：防御面向返回的编程攻击

【文章为google-translate的直译结果，最近暂时没有时间修改翻译内容。google-translate的翻译结果中有很多明显的错误，遇到类似的问题，请读者结合英文仔细揣摩。】

ABSTRACT

摘要

Despite the many efforts made in recent years to mitigate runtime attacks such as stack and heap based buffer overflows, these attacks are still a common security concern in today’s computing platforms. Attackers have even found new ways to enforce runtime attacks including use of a technique called return-oriented programming. Trusted Computing provides mechanisms to verify the integrity of all executable content in an operating system. But they only provide integrity at load-time and are not able to prevent or detect runtime attacks. To mitigate return-oriented programming attacks, we propose new runtime integrity monitoring techniques that use tracking instrumentation of program binaries based on taint analysis and dynamic tracing. We also describe how these techniques can be employed in a dynamic integrity measurement architecture (DynIMA). In this way we’ll the gap between static load-time and dynamic runtime attestation and, in particular, extend trusted computing techniques to effectively defend against return-oriented programming attacks.

尽管近年来为缓解运行时攻击（例如基于堆栈和堆的缓冲区溢出）做出了许多努力，但这些攻击仍然是当今计算平台中常见的安全问题。攻击者甚至发现了执行运行时攻击的新方法，包括使用一种称为面向返回的编程的技术。可信计算提供了一些机制来验证操作系统中所有可执行内容的完整性。但是它们仅在加载时提供完整性，而不能阻止或检测运行时攻击。为了减轻面向返回的编程攻击，我们提出了新的运行时完整性监视技术，该技术使用基于污点分析和动态跟踪的程序二进制文件的跟踪工具。我们还将描述如何在动态完整性度量体系结构（DynIMA）中采用这些技术。这样，我们将消除静态加载时间与动态运行时证明之间的差距，尤其是扩展可信计算技术以有效防御面向返回的编程攻击。

Categories and Subject Descriptors

类别和主题描述符

D.4.6 [Operating Systems]: Security and Protection; H.4 [Information Systems Applications]:Miscellaneous

D.4.6 [操作系统]：安全性和保护； H.4 [信息系统应用]：其他

General Terms

一般条款

Measurement, Security

Keywords

关键词

return-oriented programming, integrity monitoring, attestation systems

Permission

允许

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
STC’09, November 13, 2009, Chicago, Illinois, USA.
Copyright 2009 ACM 978-1-60558-788-2/09/11 …$10.00.

只要不为牟利或商业利益而制作或分发副本，并且副本载有本通知和第一页的完整引用，则可免费提供允许将本作品的全部或部分制作为个人或教室的数字或纸质副本，以供个人或教室使用 。 若要进行其他复制，重新发布，在服务器上发布或重新分发到列表，则需要事先获得特定许可和/或费用。
STC’09，2009年11月13日，美国伊利诺伊州芝加哥。
版权所有2009 ACM 978-1-60558-788-2 / 09/11 … $ 10.00。

1. INTRODUCTION

1.引言

Distributed computing and worldwide business transactions over open networks, such as the Internet, increasingly demand for secure communication and secure operation due to rising online fraud [13] and software attacks [30]. While cryptographic techniques protect data communication satisfactorily in a pragmatic view, the security of the endpoints and their underlying software components suffer from exploitation of different vulnerabilities. Some of these vulnerabilities are due to the complexity and architectural constraints of the underlying execution environment (CPU hardware and commodity operating systems), some are due to poor software development practices and lack of software security in applications. In this context, the integrity of system software and applications is a fundamental requirement and necessary consequence in order to ensure trust in the computing infrastructure.

由于在线欺诈[13]和软件攻击[30]的增加，通过开放网络（例如Internet）进行的分布式计算和全球业务交易对安全通信和安全操作的需求日益增长。 尽管加密技术以实用的方式令人满意地保护了数据通信，但端点及其底层软件组件的安全性却受到不同漏洞的利用。 其中一些漏洞是由于底层执行环境（CPU硬件和商用操作系统）的复杂性和体系结构约束所致，有些是由于不良的软件开发实践和应用程序中软件安全性不足所致。 在这种情况下，系统软件和应用程序的完整性是基本要求和必要结果，以便确保对计算基础结构的信任。

Trusted Computing as proposed by the Trusted Computing Group (TCG) offers a technology that is able to verify the integrity of executable content through remote attestation. This procedure allows a verifier to check the integrity of a remote system by verifying integrity measurement values digitally signed by a trusted hardware component called Trusted Platform Module (TPM) [35]. Several operating system extensions [22, 29] already support the TPM as underlying security module. However, such attestation mechanisms provide only integrity verification at load-time but not at run-time: An attacker can change the ow of execution of a program, e.g., via buffer overflow attacks [2] that are despite numerous countermeasures still a great security concern in software systems today.

可信计算小组（TCG）提出的可信计算提供了一种技术，该技术能够通过远程证明来验证可执行内容的完整性。 此过程允许验证者通过验证由称为“可信平台模块”（TPM）的可信硬件组件进行数字签名的完整性测量值来检查远程系统的完整性[35]。 几个操作系统扩展[22、29]已经支持TPM作为基础安全模块。 但是，这种证明机制仅在加载时提供完整性验证，而在运行时不提供：攻击者可以例如通过缓冲区溢出攻击[2]来更改程序的执行情况，尽管采取了许多对策仍然具有很高的安全性。 当今软件系统的关注。

In particular, new runtime attacks were found based on so called return-oriented programming [5, 31]. These attacks do not need to inject new code, but instead use code that already exists in the process’s memory. Existing protection mechanisms such as marking the stack as non-executable [24] cannot detect this class of attacks because only instructions are executed that reside in valid code pages. Moreover, the new attacks generalize the original return-into-libc attack [32] by allowing the attacker arbitrary computation without calling any functions. In a traditional return-into-libc attack an attacker could execute only straight-line code without using branching, and could only invoke functions that reside in libc. In the new attacks, an attacker overwrites the stack with return addresses that point to existing code fragments in the program or system libraries.

特别是，基于所谓的面向返回的编程[5，31]发现了新的运行时攻击。 这些攻击不需要注入新代码，而是使用进程内存中已经存在的代码。 现有的保护机制（例如将堆栈标记为不可执行[24]）无法检测到此类攻击，因为仅执行了位于有效代码页中的指令。 此外，新的攻击通过允许攻击者任意计算而无需调用任何函数，从而将原始的返回libc攻击[32]进行了概括。 在传统的返回libc攻击中，攻击者只能执行直线代码而不使用分支，并且只能调用驻留在libc中的函数。 在新的攻击中，攻击者使用指向程序或系统库中现有代码片段的返回地址覆盖堆栈。

The existing TCG attestation method cannot reflect such malicious changes during runtime since it takes static integrity measurements at load-time. Recent works try to fill the gap between load-time and runtime attestation by monitoring (dynamic) properties of programs [16, 12] or by enforcing information flow policies that allow low integrity data to flow only to high integrity processes [14]. However, these approaches require either the source code of applications to be monitored or are restricted to special runtime environments. To the best of our knowledge, none of these approaches can detect or prevent attacks that are based on return-oriented programming, which we consider a major threat in practical computing environments.

现有的TCG证明方法无法在运行时反映这种恶意更改，因为它在加载时进行静态完整性测量。 最近的工作试图通过监视程序的（动态）属性[16、12]或强制执行仅允许低完整性数据仅流向高完整性进程[14]的信息流策略来填补加载时间和运行时证明之间的空白。 但是，这些方法需要监视应用程序的源代码，或者仅限于特殊的运行时环境。 据我们所知，这些方法都无法检测或阻止基于面向返回的编程的攻击，我们认为这是实际计算环境中的主要威胁。

We propose a dynamic integrity measurement technique that is able to detect this new class of attacks. Our solution extends existing load-time measurement with a novel dynamic integrity monitoring using code rewriting techniques. In this paper, we present the current work-in-progress of our dynamic integrity measurement architecture (DynIMA). In particular, our contributions are the following:

我们提出了一种动态完整性度量技术，该技术能够检测到这种新型攻击。 我们的解决方案通过使用代码重写技术的新型动态完整性监控功能来扩展现有的负载时间测量。 在本文中，我们介绍了动态完整性度量体系结构（DynIMA）的最新进展。 特别是，我们的贡献如下：

• We propose a general design for a dynamic integrity measurement architecture (Section 3). The main idea is to instrument the code of programs before loading them to include runtime checks. These checks monitor changes during runtime in the data segment, in particular on the stack in order to detect attacks such as return-oriented programming.

  我们提出了动态完整性度量体系结构的通用设计（第3节）。 主要思想是在加载程序之前对程序代码进行检测，以包括运行时检查。 这些检查监视运行时在数据段中（尤其是在堆栈上）的变化，以检测攻击，例如面向返回的编程。

• We explore two promising rewriting techniques to integrate in our integrity measurement architecture as tracking instrumentation (Section 4): taint tracking and dynamic tracing.

  我们探索了两种有前途的重写技术，它们可以作为跟踪工具集成到我们的完整性度量体系结构中（第4节）：污点跟踪和动态跟踪。

2. BACKGROUND AND PROBLEM

背景与问题

2.1 Trusted Computing Concepts

2.1可信计算概念

The Trusted Computing Group (TCG), an industrial initiative towards the realization of Trusted Computing, has specflified security extensions for commodity computing platforms. The core TCG specification is the Trusted Platform Module (TPM) [35], a hardware security module embedded in computer mainboards. The TPM provides some cryptographic functions and protected storage for small data such as cryptographic keys.

可信计算小组（TCG）是实现可信计算的一项工业计划，它已指定了商品计算平台的安全扩展。 TCG的核心规范是可信平台模块（TPM）[35]，这是嵌入在计算机主板中的硬件安全模块。 TPM为小数据（例如，加密密钥）提供了一些加密功能和受保护的存储。

The TPM supports a trusted boot process by allowing to record measurements of the hardware configuration and software stack during the boot process. Measurements are taken at load-time of the software components (using cryptographic hashing of binaries). These measurements are securely stored in specific TPM registers called Platform configuration Registers (PCRs). Based on these PCR values, the TPM provides the sealing functionality, i.e., binding encrypted data to the recorded configuration , and attestation, i.e., reporting the system state to a (remote) party by presenting the PCR values digitally signed by the TPM.

TPM允许在启动过程中记录对硬件配置和软件堆栈的测量，从而支持受信任的启动过程。 在软件组件加载时进行测量（使用二进制加密散列）。 这些测量值安全地存储在称为平台配置寄存器（PCR）的特定TPM寄存器中。 基于这些PCR值，TPM提供密封功能，即将加密数据绑定到记录的配置，并提供证明，即通过显示由TPM数字签名的PCR值向（远程）用户报告系统状态。

2.2 Return-Oriented Programming Attacks

2.2面向返回的编程攻击

Runtime attacks can change the process behavior and they are not reflected in the attestation of load-time integrity measurement. A traditional vulnerability of programs is the buffer overflow on the stack [2]. An attacker overwrites the saved return address of a function on the stack such that it points to injected code, which the attacker also places on the stack. Subsequent instructions are executed on the stack, which is now interpreted as code and not data. Marking the stack as non-executable [24] prevents such code injection attacks. Modern processors from AMD and Intel provide a non-executable bit for each memory page, which operating systems can set for data pages.

运行时攻击可以更改流程行为，并且不会反映在负载时完整性度量的证明中。 程序的传统漏洞是堆栈上的缓冲区溢出[2]。 攻击者覆盖函数在堆栈上保存的返回地址，以使其指向注入的代码，攻击者也将这些代码放入堆栈中。 后续指令在堆栈上执行，现在将其解释为代码而非数据。 将堆栈标记为不可执行[24]可防止此类代码注入攻击。 AMD和Intel的现代处理器为每个内存页提供了一个不可执行的位，操作系统可以为数据页设置该位。

In contrast, in return-oriented programming (ROP) attacks [5, 31, 32], the attacker overwrites the stack with addresses that point to already existing code. Addresses that are mainly used point to the standard C library (libc) because it is linked into most Unix programs. But other libraries or parts of the program may serve as target addresses as well.

相反，在面向返回的编程（ROP）攻击[5、31、32]中，攻击者使用指向已经存在的代码的地址覆盖堆栈。 主要使用的地址指向标准C库（libc），因为它已链接到大多数Unix程序中。 但是其他库或程序的某些部分也可以用作目标地址。

Instead of calling a function, ROP carefully sets return addresses on the stack to the middle of instruction sequences (gadgets) that end with a return instruction. After executing the instructions of the gadget, the return takes the next address from the stack where execution continues, and increments the stack pointer. Hence, by carefully crafting the data that overwrites the stack, an attacker can point to existing code sequences. The stack pointer effectively determines the program control flow then and acts like an instruction pointer. This attack completely circumvents protection methods based on non-executable data pages.

ROP无需调用函数，而是仔细地将堆栈上的返回地址设置为以返回指令结尾的指令序列（小配件）的中间。 执行完小工具的指令后，返回值从堆栈中继续执行的下一个地址开始，并递增堆栈指针。 因此，通过精心设计覆盖堆栈的数据，攻击者可以指向现有的代码序列。 堆栈指针然后有效地确定程序控制流，并像指令指针一样起作用。 这种攻击完全规避了基于不可执行数据页的保护方法。

Buchanan et al. [5] have shown that this attack can be generalized from x86 to RISC processor architectures. They even showed that it is possible to build a high-level language and a compiler based on those gadgets, which enables attackers to easily construct the stack to include return addresses which result in the execution of arbitrary behavior within a vulnerable process.

Buchanan等。 [5]表明，这种攻击可以从x86推广到RISC处理器体系结构。 他们甚至表明，可以基于这些小工具构建高级语言和编译器，这使攻击者可以轻松构造堆栈以包含返回地址，从而导致在易受攻击的进程中执行任意行为。

The authors of [5] briefly mention some strategies to be worth to explore as possible mitigating techniques for ROP attacks. However, they state that \any ‘Trusted Computing’ technology using cryptographic attestation" cannot detect ROP attacks. The reason is that such attestation covers only load-time integrity measurements. Therefore, we want to extend the TCG based integrity measurement and attestation techniques to include runtime checks. We aim at proving that trusted computing, with certain extensions, can be adopted to detect return-oriented programming attacks.

[5]的作者简要地提到了一些值得探索的策略，作为缓解ROP攻击的技术。 但是，他们声明“任何使用密码证明的“可信计算”技术都无法检测到ROP攻击。原因是这种证明仅涵盖了加载时完整性度量。因此，我们希望将基于TCG的完整性度量和证明技术扩展到 包括运行时检查我们的目标是证明可以采用带有某些扩展的可信计算来检测面向返回的编程攻击。

3. ARCHITECTURE FOR DYNAMIC INTEGRITY MEASUREMENT

3.动态完整性测量的体系结构

To explain the main concept of our dynamic integrity measurement architecture (DynIMA), we consider a simple process model. A process consists of code and data. Code is the static part of the program binary, whereas the data contains runtime variables and, in particular, the stack, which holds function arguments and return addresses of function calls.

为了解释我们的动态完整性度量体系结构（DynIMA）的主要概念，我们考虑一个简单的过程模型。 一个过程由代码和数据组成。 代码是程序二进制文件的静态部分，而数据包含运行时变量，尤其是堆栈，其中包含函数自变量和函数调用的返回地址。

The general idea of DynIMA is to combine load-time integrity measurement with dynamic tracking techniques. A program’s code will be instrumented with tracking code that will perform integrity-related runtime checks. To realize this idea, we propose to change the usual program loader of the operating system. It should not only include static integrity measurement facility (as in IMA [29]), but also a new component that rewrites the code of programs to be loaded to include special tracking code that monitors dynamic events of the program and maintains tracking data. Tracking code will be generically instrumented to program binaries because we aim to track common patterns of ROP attacks and not program-specific behavior. Hence, we do not require the source code of programs to be monitored by DynIMA.

DynIMA的总体思路是将负载时间完整性测量与动态跟踪技术结合起来。 程序代码将带有跟踪代码，这些代码将执行与完整性相关的运行时检查。 为了实现这个想法，我们建议更改操作系统的常规程序加载器。 它不仅应包括静态完整性测量工具（如IMA [29]中所述），还应包括一个新组件，该组件重写要加载的程序代码，以包括监视程序动态事件并维护跟踪数据的特殊跟踪代码。 跟踪代码将一般用于程序二进制文件，因为我们的目标是跟踪ROP攻击的常见模式，而不是特定于程序的行为。 因此，我们不需要DynIMA监视程序的源代码。

Program loading.

程序加载。

The sequence of loading a program in DynIMA works as follows: When a program is going to be loaded, the loader measures the static binary of the program and a tracking instrumentation component rewrites the code to include tracking code. The process of the program is then started and the tracking code stores tracking data in the data segment. The tracking code will dynamically update tracking data as tracking events occur. The tracking events are pre-defined for all program binaries.[DynIMA could be extended that tracking events also contain individual, program-specific events. However, this would require knowledge on details of each program and probably require the source code. This is out of scope of this paper since we aim to detect ROP attacks, which are a general problem.] For instance, based on the measurement of the binary, a different event pattern and tracking code could be applied. Which pattern and tracking code has to be applied is defined in a tracking policy of DynIMA. The components of the loader and the tracking instrumentation are contained within the Process Integrity Manager (PIM). In contrast to a program monitor such as [12], PIM instruments the program (and other parts of the operating system) with tracking code, which results in a distributed monitor. Parts of the monitoring are performed in PIM and the operating system, and parts are performed within the program’s process. Figure 1 shows the DynIMA architecture.

在DynIMA中加载程序的顺序如下：当要加载程序时，加载程序将测量程序的静态二进制文件，并且跟踪工具组件将代码重写为包含跟踪代码。然后启动程序的过程，并且跟踪代码将跟踪数据存储在数据段中。跟踪事件发生时，跟踪代码将动态更新跟踪数据。跟踪事件是为所有程序二进制文件预先定义的。[DynIMA可以扩展为跟踪事件还包含单独的，特定于程序的事件。但是，这需要了解每个程序的详细信息，并且可能需要源代码。由于我们的目标是检测普遍存在的ROP攻击，因此这超出了本文的范围。]例如，基于二进制的测量，可以应用不同的事件模式和跟踪代码。 DynIMA的跟踪策略中定义了必须应用的模式和跟踪代码。装载程序和跟踪仪表的组件包含在过程完整性管理器（PIM）中。与程序监视器（例如[12]）相比，PIM使用跟踪代码对程序（和操作系统的其他部分）进行检测，从而生成了分布式监视器。监视的一部分在PIM和操作系统中执行，部分在程序的过程中执行。图1显示了DynIMA体系结构。

Attestation.

证明。

We assume the TCB (including, BIOS, bootloader, operating system, and PIM) to be measured statically at boot time and recorded in the PCRs of the TPM. Any other program is loaded and measured by the PIM, similar to static measurement as done in IMA [29] (in fact we use IMA for the static part). The result of the static measurement and the dynamic tracking is stored on a per-process basis within the PIM. Hence, an attestation procedure is composed of the following steps:

我们假设TCB（包括BIOS，引导程序，操作系统和PIM）在引导时进行静态测量，并记录在TPM的PCR中。 任何其他程序都由PIM加载和测量，类似于IMA [29]中所做的静态测量（实际上，静态部分使用IMA）。 静态测量和动态跟踪的结果按过程存储在PIM中。 因此，证明程序由以下步骤组成：

1. A verifier requests attestation of a certain program.

2. PIM requests a PCR quote from the TPM to attest to the TCB (including the PIM).

3. PIM digitally signs the measurement and current tracking data of the program which attestation is requested.

4. PIM sends the quoted PCRs (signed by the TPM) and the dynamic measurement of the program (signed by PIM) to the verifier .

5. The verifier verifies the presented data and decides further steps according to the result.

6. 验证者要求证明某个程序。

7. PIM向TPM请求PCR报价以证明TCB（包括PIM）。

8. PIM对需要证明的程序的测量和当前跟踪数据进行数字签名。

9. PIM将引用的PCR（由TPM签名）和程序的动态度量（由PIM签名）发送给验证者。

10. 验证者验证显示的数据，并根据结果决定进一步的步骤。

4. TRACKING INSTRUMENTATION

4.跟踪仪器

In this section we briefly explore two possible code instrumentation techniques that could be applied as our tracking instrumentation in DynIMA. The integration and implementation of these techniques in our architecture is currently work-in-progress.

在本节中，我们简要探讨了两种可能的代码检测技术，这些技术可以用作DynIMA中的跟踪检测工具。 这些技术在我们架构中的集成和实现目前仍在进行中。

4.1 Using Taint Tracking

4.1使用污点追踪

As one possible countermeasure to prevent attacks that are based on buffer overflows and return-oriented programming we consider dynamic taint analysis. Dynamic taint analysis marks any untrusted data as tainted, tracks the propagation of tainted data during program execution, and alerts or terminates the program if tainted data is misused. Misuse of tainted data is, for instance, using tainted data as a pointer, since most buffer overflow attacks are based on changing return addresses and function pointers.

作为防止基于缓冲区溢出和面向返回的编程的攻击的一种可能的对策，我们考虑动态污点分析。 动态污点分析将任何不受信任的数据标记为污点，在程序执行过程中跟踪污点数据的传播，如果污点数据被滥用，则将警告或终止程序。 例如，由于大多数缓冲区溢出攻击都是基于更改返回地址和函数指针，因此污染数据的滥用例如是使用污染数据作为指针。

To design a dynamic integrity measurement architecture, we propose a combination of trusted computing and taint tracking to achieve both load-time and run-time integrity. The design we propose is depicted in Figure 2.

为了设计动态完整性度量体系结构，我们提出了可信计算和污点跟踪的组合，以实现加载时和运行时的完整性。 我们提出的设计如图2所示。

On the left side of Figure 2, we see a usual Unix process that is running in an emulation environment that contains a taint tracking system as plug-in. Only the Code (or Text) segment is protected by IMA at load-time. In addition, dynamic taint analysis monitors data flow integrity. The static results from IMA and the dynamic results from taint tracking are both collected by PIM. If the taint tracking detects an integrity violation, the program will be marked as tainted and PIM records this accordingly. Hence, a verifier can check through dynamic attestation (see above) whether the system has been compromised at run-time. Moreover, the verifier must be able to verify that the taint tracking system is running on the verified system for the application he wants to verify. Besides, the taint tracking system should be based on binary instrumentation. Otherwise, some libraries have to be excluded from the taint analysis since the source code of libraries is not always available or they are written in assembly language.

在图2的左侧，我们看到了一个普通的Unix进程，该进程在包含污染跟踪系统作为插件的仿真环境中运行。在加载时，只有代码（或文本）段受IMA保护。此外，动态污点分析可监控数据流的完整性。 PMA收集IMA的静态结果和污点跟踪的动态结果。如果污点跟踪检测到完整性违规，则程序将被标记为污点，并且PIM会对此进行记录。因此，验证者可以通过动态证明（参见上文）检查系统在运行时是否已受到威胁。此外，验证者必须能够验证他想要验证的应用程序的污点跟踪系统正在验证的系统上运行。此外，污染追踪系统应基于二进制仪器。否则，由于库的源代码并不总是可用或它们是用汇编语言编写的，因此必须从污点分析中排除某些库。

Tools that enforce dynamic taint analysis are usually implemented in Binary Instrumentation Frameworks (DBIs). Therefore we implemented a tool that tries to detect ROP attacks by counting any instruction between two return instructions in the PIN framework [20]. Since instruction sequences used in ROP attacks range from two to five instructions [31], we increment a counter if the instructions between two returns are less or equal than five. Further, because the small instruction sequences are all chained consecutively together to form a gadget, our pintool reports a ROP attack if three of these small instruction sequences were executed one after another. As a first test, we deployed a test program that exploits a buffer overflow vulnerability in a program and runs a ROP attack. Our pintool was able to detect the attack because of the small instruction sequences executed in the ROP attack. These are promising results, and in future work we have to identify the appropriate parameters for detecting return-oriented programming in general in order to distinguish a gadget call from ordinary short instruction sequences.

通常，在二元仪器框架（DBI）中实施用于执行动态污点分析的工具。因此，我们实现了一种工具，该工具通过对PIN框架中两个返回指令之间的任何指令进行计数来尝试检测ROP攻击[20]。由于在ROP攻击中使用的指令序列范围为2到5个指令[31]，因此，如果两个返回之间的指令小于或等于5，则我们增加一个计数器。此外，由于所有小指令序列都连续链接在一起形成一个小工具，因此如果这些小指令序列中的三个依次执行，我们的pintool会报告ROP攻击。作为第一个测试，我们部署了一个测试程序，该程序利用程序中的缓冲区溢出漏洞并运行ROP攻击。由于ROP攻击中执行的指令序列很小，我们的pintool能够检测到攻击。这些都是令人鼓舞的结果，在将来的工作中，我们必须确定用于检测面向返回的程序的适当参数，以便将小工具调用与普通的短指令序列区分开。

4.2 Using Dynamic Tracing

4.2使用动态跟踪

While taint tracking requires to instrument the program before execution, dynamic tracing techniques exist that allow to instrument code on-the-fly. DTrace [6] is a dynamic instrumentation framework for tracing kernel and processes operation in production systems. It uses code rewriting techniques to dynamically instrument both pre-defined probe points in the kernel but also arbitrary user process instructions. If probes are not activated, there is no tracing code instrumented in the processes or kernel. This allows dynamic instrumentation of running systems without restarting the processes under observation.

污点跟踪需要在执行之前对程序进行检测，但存在动态跟踪技术，可以动态检测代码。 DTrace [6]是一个动态的检测框架，用于跟踪生产系统中的内核和流程操作。 它使用代码重写技术来动态检测内核中的预定义探针点以及任意用户处理指令。 如果未激活探针，则进程或内核中没有检测到跟踪代码。 这允许动态检测正在运行的系统，而无需重新启动正在观察的进程。

Using a dynamic tracing mechanism such as DTrace would improve the flexibility of our design since tracing can be switched on and off as needed. Moreover, we expect a performance gain because when tracing is switched off, no tracing code will be actually executed.

使用动态跟踪机制（例如DTrace）将提高我们设计的灵活性，因为可以根据需要打开和关闭跟踪。 此外，我们希望性能有所提高，因为当关闭跟踪时，将不会实际执行任何跟踪代码。

DTrace was also examined how it can be used for reverse engineering tasks [34]. To overcome the constraints of the D language provided by DTrace, the authors use a combination of DTrace and the object-oriented programming language Ruby. The framework they propose is called RE:DTrace and is distributed with scripts that are able to detect stack and heap based buffer overflow attacks. We have to investigate if it is possible to use their work and their ideas to extend RE:DTrace in a way to detect ROP attacks.

DTrace还研究了如何将其用于逆向工程任务[34]。 为了克服DTrace提供的D语言的限制，作者结合使用DTrace和面向对象的编程语言Ruby。 他们提出的框架称为RE：DTrace，并随脚本一起分发，这些脚本能够检测基于堆栈和堆的缓冲区溢出攻击。 我们必须研究是否有可能利用他们的工作和想法来扩展RE：DTrace，以检测ROP攻击。

We are currently investigating DTrace as another means to detect ROP attacks. Therefore, we instrument the libc library and try to detect whether functions are called from the beginning or in the middle of instruction sequence. The latter would indicate a gadget call of a ROP attack. To track all entries and returns to and from libc, we developed the following script in the D language:

我们目前正在研究DTrace，将其作为检测ROP攻击的另一种方法。 因此，我们对libc库进行检测，并尝试检测是从指令序列的开头还是中间调用函数。 后者将指示ROP攻击的小工具。 为了跟踪libc的所有输入和返回，我们用D语言开发了以下脚本：

pid$target:libc::entry {activate[probefunc]++;}
pid$target:libc::return /activate[probefunc]==0 /
   {printf("Return of %s without entry!",probefunc);}
pid$target:libc::return /activate[probefunc]!=0 /
   {activate[probefunc]--;}

The array activate[probefunc] is initialized with null and holds for every function in libc a counter value, whereas a value greater than null means that the function is currently being executed. Therefore the first rule increments the counter in the case the function is called. The third rule decrements the counter if the function returns ordinary to its caller. However, the probes for the second rule will fire before rule three is applied if the counter value is set to null, which means that DTrace has not registered an entry to this function although a return from this function is issued. This could be an indication for a gadget call in a ROP attack. As we enabled these probes for some ordinary programs we found out that there are some functions (e.g. memmove and memcopy) were the second rule fires although no ROP attack occurred. Our ongoing work includes separating these functions in order to reduce the number of false positives.

数组Activate [probefunc]用null初始化，并为libc中的每个函数保留一个计数器值，而大于null的值表示该函数当前正在执行。 因此，在调用函数的情况下，第一个规则会增加计数器的数量。 如果函数将普通返回给其调用者，则第三条规则递减计数器。 但是，如果计数器值设置为null，则第二条规则的探针将在应用规则三之前触发，这意味着DTrace尽管已发布该功能的返回，但尚未注册该功能的条目。 这可能表示ROP攻击中有小工具调用。 当我们为某些普通程序启用这些探针时，我们发现虽然没有发生ROP攻击，但第二次规则触发了一些功能（例如memmove和memcopy）。 我们正在进行的工作包括分离这些功能，以减少误报的数量。

5. RELATED WORK

5.相关工作

In the literature, there are several works regarding loadtime integrity checks. For example, secure boot mechanisms [3] and trusted computing enhanced Linux kernel modules like Enforcer [21] perform integrity checks of the loaded operating system and other modules. The Integrity Measurement Architecture (IMA) [29] for Linux uses a TPM to record measurements of any dynamic executable content at load-time from the BIOS all the way up to the application layer. While the TCG attestation method is based on hashes of program binaries, several improvements have been proposed in the literature to overcome some inherent drawbacks, such as lack of flexibility for program updates or privacy concerns on reporting the exact platform configuration [26, 28, 15, 17, 21]. They mainly use certificates or abstract properties instead of binary hashes. However, all those approaches are still based on load-time integrity measurement, and are not capable of detecting (malicious) changes in the measured programs during their runtime.

在文献中，有许多关于加载时完整性检查的工作。例如，安全启动机制[3]和受信任的计算增强型Linux内核模块（例如Enforcer [21]）对已加载的操作系统和其他模块进行完整性检查。 Linux的完整性度量体系结构（IMA）[29]使用TPM在加载时记录从BIOS一直到应用程序层的任何动态可执行内容的度量。尽管TCG证明方法基于程序二进制文件的哈希值，但文献中提出了一些改进措施来克服一些固有的缺陷，例如缺乏程序更新的灵活性或在报告确切的平台配置上存在隐私问题[26，28，15 ，17，21]。它们主要使用证书或抽象属性，而不是二进制哈希。但是，所有这些方法仍然基于加载时完整性度量，并且无法检测到被测程序在其运行期间的变化（恶意）。

In addition to load-time measurement, there are also approaches to extend attestation with runtime integrity measurement techniques. Semantic remote attestation [12] exploits security properties of programming languages, e.g., type-safety, which allow for certain properties of runtime attestation. However, it requires a trusted language-specific environment. In contrast, we target runtime attestation of arbitrary program binaries independent of their programming language. PRIMA [14] extends simple load-time integrity measurement with information flow integrity. High integrity processes have to have an input filtering interface, or they are not allowed to access low integrity data. However, to the best of our knowledge PRIMA is not able to prevent ROP attacks. Runtime monitors for the Linux kernel have been proposed [19, 25] that analyze and inspect dynamic structures of the kernel memory. They periodically check function pointers [25], or verify dynamic data structures [19], which is also performed in response to system events. These approaches are useful to protect the operating system kernel, but do not target ROP attacks on user programs. Hence, they are complementary to our work.

除了负载时间测量之外，还可以使用运行时完整性测量技术来扩展证明。语义远程证明[12]利用了编程语言的安全属性，例如类型安全，它允许运行时证明的某些属性。但是，它需要一个受信任的特定于语言的环境。相反，我们的目标是独立于程序二进制代码的任意程序二进制代码的运行时证明。 PRIMA [14]通过信息流的完整性扩展了简单的加载时间完整性度量。高完整性进程必须具有输入过滤接口，否则不允许它们访问低完整性数据。但是，就我们所知，PRIMA无法阻止ROP攻击。已经提出了用于Linux内核的运行时监视器[19，25]，它可以分析和检查内核内存的动态结构。他们定期检查功能指针[25]或验证动态数据结构[19]，这也是响应系统事件而执行的。这些方法对于保护操作系统内核很有用，但不会针对用户程序进行ROP攻击。因此，它们是我们工作的补充。

The closest work to our architecture is ReDAS [16], a similar framework for dynamic attestation with runtime integrity monitoring of programs. Their approach differs to ours in two main aspects: (i) ReDAS requires the source code of each program to perform an analysis of dynamic properties before execution, and (ii) ReDAS cannot detect return-oriented programming attacks in general because it monitors applications on the granularity of system calls. But ROP attacks can change program behavior without any function calls by exploiting code fragments in the middle of functions [5]. In contrast, we aim to detect any ROP attack by monitoring ROP-specific dynamic behavior, which is generic for all programs, and we do not require the source code of applications.

与我们的体系结构最接近的工作是ReDAS [16]，这是一种用于动态证明的类似框架，具有对程序的运行时完整性进行监视。 他们的方法与我们的方法在两个主要方面不同：（i）ReDAS要求每个程序的源代码在执行之前都要对动态属性进行分析，并且（ii）ReDAS通常无法检测面向返回的编程攻击，因为它会监视应用程序上的应用程序。 系统调用的粒度。 但是ROP攻击可以通过利用函数中间的代码片段来更改程序行为，而无需任何函数调用[5]。 相比之下，我们旨在通过监视特定于ROP的动态行为来检测任何ROP攻击，这对于所有程序都是通用的，并且我们不需要应用程序的源代码。

Several architectures and tools for dynamic taint analysis were proposed and developed in the past years. On the one hand, software-based systems were deployed, whereas some are based on binary instrumentation [8, 9, 23, 27] and others are compiler-based [1, 7, 18, 36]. On the other hand, several hardware-based solutions were presented [10, 11, 33] that reduce overhead associated with software-based solutions, but require hardware extensions. We use these techniques, in particular binary instrumentation, in DynIMA in order to detect ROP attacks.

在过去的几年中，提出并开发了几种用于动态污点分析的架构和工具。 一方面，部署了基于软件的系统，而有些基于二进制工具[8、9、23、27]，而另一些则基于编译器[1、7、18、36]。 另一方面，提出了几种基于硬件的解决方案[10、11、33]，这些解决方案减少了与基于软件的解决方案相关的开销，但需要硬件扩展。 为了检测ROP攻击，我们在DynIMA中使用了这些技术，特别是二进制工具。

The authors of [4] describe in their position paper, which inspired much of our work, how tracing techniques such as DTrace could be used to complement load-time integrity measurement with runtime policy enforcement. In their vision software developers should define application-specific events of their programs as policy. In contrast, we aim at defining common events that are tracked for all programs in order to detect runtime changes, namely return-oriented programming attacks.

[4]的作者在他们的立场文件中描述了如何启发跟踪技术（例如DTrace）如何与运行时策略执行相结合来补充负载时完整性测量，这对我们的许多工作产生了启发。 在他们看来，软件开发人员应将其程序的特定于应用程序的事件定义为策略。 相比之下，我们旨在定义针对所有程序跟踪的公共事件，以检测运行时更改，即面向返回的编程攻击。

6. CONCLUSIONS AND FUTURE WORK

6.结论与未来工作

We have described how trusted computing concepts can be extended with tracking instrumentation in order to bridge the gap between static load-time and dynamic runtime integrity measurement. The DynIMA framework we propose is to the best of our knowledge the first framework that provides both load-time and runtime integrity for program binaries without knowledge of their source code and even under the presence of attacks that are based on return-oriented programming.

我们已经描述了如何通过跟踪工具扩展可信计算概念，以弥合静态加载时间与动态运行时完整性度量之间的差距。 就我们所知，我们提出的DynIMA框架是第一个为程序二进制文件提供加载时和运行时完整性的框架，而不需要知道其源代码，甚至在存在基于面向返回的编程的攻击的情况下。

Future work has do address some open questions, e.g., the design of the operating system loader: Should every program run with PIM or is it possible to exclude some programs from instrumentation to achieve better performance? We have to take into consideration that instrumentation, especially in the case of taint analysis, can highly impact the performance of the overall system. Further, we have to find meaningful values to integrate in the existing integrity measurement to include the tracking results in remote attestation procedures. Moreover, should we measure the program binaries before or after applying the code rewriting that includes the dynamic tracking? Does it have any meaningful implications in doing either way? We believe not if we assume the code rewriting as a trusted and deterministic process. However, on different platforms different code rewriting implementations could result in different measurements afterwards, resulting in unknown values to a verifier during attestation. We also have to take into consideration that code rewriting changes the process image and can hinder the execution of evaluated and certified programs. One approach to overcome this obstacle is to certify the rewriting techniques. The combination of the certified program and the certified rewriting technique then allows usual execution of the program. We will explore these and other issues in our ongoing work to complete DynIMA to fill the gap between load-time and runtime integrity measurement.

未来的工作确实解决了一些悬而未决的问题，例如操作系统加载程序的设计：每个程序都应使用PIM运行，还是可以将某些程序从工具中排除，以获得更好的性能？我们必须考虑到仪器，尤其是在污点分析的情况下，会严重影响整个系统的性能。此外，我们必须找到有意义的值以整合到现有的完整性度量中，以将跟踪结果包括在远程证明程序中。此外，我们是否应该在应用包含动态跟踪的代码重写之前或之后测量程序二进制文件？这两种方式都具有任何有意义的含义吗？如果我们认为代码重写是一个可信赖的确定性过程，我们相信不会。但是，在不同的平台上，不同的代码重写实现可能会导致以后的测量结果不同，从而在验证期间给验证者带来未知的值。我们还必须考虑到代码重写会更改过程映像，并可能妨碍执行经过评估和认证的程序。克服此障碍的一种方法是对重写技术进行认证。然后，将经过认证的程序和经过认证的重写技术相结合，即可正常执行该程序。我们将在正在进行的工作中探索这些和其他问题，以完成DynIMA，以填补加载时间与运行时完整性度量之间的空白。

7. REFERENCES

7.参考

[1] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti. Controlflow integrity: Principles, implementations, and applications. In CCS '05: Proceedings of the 12th ACM Conference on Computer and Communications Security, pages 340{353. ACM, 2005.

[2] Aleph One. Smashing the stack for fun and profit. Phrack Magazine, 49(14), 1996.

[3] W. A. Arbaugh, D. J. Farber, and J. M. Smith. A secure and reliable bootstrap architecture. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 65{71, Oakland, CA, May 1997.IEEE Computer Society.

[4] S. Bratus, M. E. Locasto, A. Ramaswamy, and S. W. Smith. New directions for hardware-assisted trusted computing policies. In Conference on the Future of Trust in Computing (FTC 2008), June 2008. http://www.cs.dartmouth.edu/~sws/pubs/berlin.pdf.

[5] E. Buchanan, R. Roemer, H. Shacham, and S. Savage. When good instructions go bad: generalizing return-oriented programming to RISC. In CCS '08: Proceedings of the 15th ACM conference on Computer and communications security, pages 27{38. ACM, 2008.

[6] B. M. Cantrill, M. W. Shapiro, and A. H. Leventhal. Dynamic instrumentation of production systems. In Proceedings of USENIX 2004 Annual Technical Conference, pages 15{28, Berkeley, CA, USA, 2004. USENIX Association.

[7] W. Chang, B. Streiff, and C. Lin. Efficient and extensible security enforcement using dynamic data flow analysis. In CCS '08: Proceedings of the 15th ACM Conference on Computer and Communications Security, pages 39{50. ACM, 2008.

[8] W. Cheng, Q. Zhao, B. Yu, and S. Hiroshige. Tainttrace: Efficient flow tracing with dynamic binary rewriting. In Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC 2006), pages 749{754. IEEE, 2006.

[9] J. Clause, W. Li, and A. Orso. Dytan: A generic dynamic taint analysis framework. In Proceedings of the 2007 International Symposium on Software Testing, pages 196{206, 2007.

[10] J. R. Crandall and F. T. Chong. Minos: Control data attack prevention orthogonal to memory model. In Proceedings of the 37th International Symposium on Microarchitecture, pages 221{232, 2004.

[11] M. Dalton, H. Kannan, and C. Kozyrakis. Raksha: A flexible information ow architecture for software security. In Proceedings of the 34th International Symposium on Computer Architecture, pages 482{493, 2007.

[12] V. Haldar, D. Chandra, and M. Franz. Semantic remote attestation: A virtual machine directed approach to trusted computing. In USENIX Virtual Machine Research and Technology Symposium, 2004.

[13] Internet Crime Complaint Center. 2008 Internet Crime Report. http://www.ic3.gov/media/ annualreport/2008_IC3Report.pdf, 2008.

[14] T. Jaeger, R. Sailer, and U. Shankar. Prima: policy-reduced integrity measurement architecture. In SACMAT '06: Proceedings of the eleventh ACM symposium on Access control models and technologies, pages 19{28, New York, NY, USA, 2006. ACM.

[15] S. Jiang, S. Smith, and K. Minami. Securing web servers against insider attack. In 17th Annual Computer Security Applications Conference (ACSAC), pages 265{276, 2001.

[16] C. Kil, E. C. Sezer, A. M. Azab, P. Ning, and X. Zhang. Remote attestation to dynamic system properties: Towards providing complete system integrity evidence. In Proceedings of the 39th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN 2009), 2009. to appear.

[17] U. Kuhn, M. Selhorst, and C. Stuble. Realizing property-based attestation and sealing with commonly available hard- and software. In STC '07: Proceedings of the 2nd ACM Workshop on Scalable Trusted Computing, pages 50{57. ACM Press, 2007.

[18] L. C. Lam and T.-C. Chiueh. A general dynamic information flow tracking framework for security applications. In Proceedings of the 22nd Annual Computer Security Applications Conference, pages 463{472. IEEE Computer Society, 2006.

[19] P. A. Loscocco, P. W. Wilson, J. A. Pendergrass, and C. D. McDonell. Linux kernel integrity measurement using contextual inspection. In Proceedings of the 2nd ACM Workshop on Scalable Trusted Computing (STC’07), pages 21{29. ACM, 2007.

[20] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S. Wallace, V. J. Reddi, and K. Hazelwood. Pin: building customized program analysis tools with dynamic instrumentation. In PLDI '05: Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation, volume 40, pages 190{200, New York, NY, USA, June 2005. ACM Press.

[21] R. Macdonald, S. Smith, J. Marchesini, and O. Wild. Bear: An open-source virtual secure coprocessor based on TCPA. Technical Report TR2003-471, Department of Computer Science, Dartmouth College, 2003.

[22] Microsoft Corporation. Bitlocker drive encryption, July 2007. http://www.microsoft.com/technet/ windowsvista/security/bitlockr.mspx.

[23] J. Newsome and D. Song. Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits on commodity software. In Proceedings of the Network and Distributed Security Symposium, 2005.

[24] PaX Team. http://pax.grsecurity.net/.

[25] N. L. Petroni, Jr. and M. Hicks. Automated detection of persistent kernel controlflow attacks. In CCS '07: Proceedings of the 14th ACM Conference on Computer and Communications Security, pages 103{115. ACM, 2007.

[26] J. Poritz, M. Schunter, E. Van Herreweghen, and M. Waidner. Property attestation|scalable and privacy-friendly security assessment of peer computers. Technical Report RZ 3548, IBM Research, May 2004.

[27] F. Qin, C. Wang, Z. Li, H. seop Kim, Y. Zhou, and Y. Wu. LIFT: A low-overhead information flow tracking system for detecting security attacks. In Proceedings of the 39th Annual IEEE/ACM Symposium on Microarchitecture, pages 135{148, 2006.

[28] A.-R. Sadeghi and C. Stuble. Property-based attestation for computing platforms: Caring about properties, not mechanisms. In The 2004 New Security Paradigms Workshop, pages 67{77. ACM, 2004.

[29] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. Design and implementation of a TCG-based integrity measurement architecture. In Proceedings of the 13th USENIX Security Symposium, pages 223{238, 2004.

[30] SANS Institute. SANS Top-20 2007 Security Risks. http://www.sans.org/top20/2007/top20.pdf, Nov. 2007.

[31] H. Shacham. The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86). In CCS '07: Proceedings of the 14th ACM Conference on Computer and Communications Security, pages 552{561. ACM, 2007.

[32] Solar Designer. “return-to-libc” attack. Bugtraq, 1997.

[33] G. E. Suh, J. W. Lee, D. Zhang, and S. Devadas. Secure program execution via dynamic information flow tracking. In ASPLOS-XI: Proceedings of the 11th International Conference on Architectural Support for Programming Languages and Operating Systems, pages 85{96. ACM, 2004.

[34] Tiller Beauchamp and David Weston. Dtrace: The reverse engineer’s unexpected swiss army knife. http://www.poppopret.org/DTrace-Beauchamp-Weston.pdf, 2008.

[35] Trusted Computing Group. TPM main specification. Specification Version 1.2 rev. 103, July 2007. https: //www.trustedcomputinggroup.org/specs/TPM/.

[36] W. Xu, S. Bhatkar, and R. Sekar. Taint-enhanced policy enforcement: A practical approach to defeat a wide range of attacks. In Proceedings of the 15th USENIX Security Symposium, pages 121{136, 2006.