循环导向编程：突破粗粒度控制流防御的新攻击策略

42 浏览量更新于2024-08-26 收藏 250KB PDF 举报

面向循环的编程（Loop-Oriented Programming, LOP）是一种新颖的代码重用攻击策略，它旨在绕过现代安全防御机制，尤其是粗粒度控制流完整性（Coarse-Grained Control Flow Integrity, CFI）和阴影栈（Shadow Stack）。传统的代码重用攻击，如Call-Presided Return Oriented Programming (CPR-ROP)，虽然能够避开粗粒度控制流限制，但它们未能完全突破阴影栈对控制流的强化约束。 LOP的核心理念是将整个函数作为基本构建块，也就是所谓的“ gadget”，并将这些 gadget 进行精心设计和串联。在 LOP 中，控制流不再局限于简单的函数调用和返回，而是通过循环结构巧妙地引导，使得攻击者能够绕过CFA检查和深度受限的控制转移。这种攻击方式利用了循环结构的灵活性，使得攻击者能够创建复杂的控制流图，从而在执行时实现预期的恶意行为，即使在存在粗粒度CFA和阴影栈保护的环境中也能生效。为了实施LOP，攻击者需要对程序的内存布局有深入理解，包括函数调用约定、栈帧布局以及循环控制结构的细节。他们可能利用数据依赖分析来识别可用于链接的 gadget，并确保这些 gadget 之间的控制流逻辑符合攻击目标。此外，LOP可能涉及动态代码调整，例如通过修改循环变量或条件判断来改变控制流程，使其在检测机制下不易被察觉。由于LOP的出现，对于软件开发人员和安全研究人员来说，这提出了一个新的挑战。为了应对这种威胁，除了继续改进现有的CFA和阴影栈技术外，还需要研发更加精细的控制流分析方法，结合其他防御手段（如类型系统、内存安全策略等），以防止此类复杂且隐匿的代码重用攻击。同时，对代码审计和静态分析工具的增强也是必要的，以便尽早发现并阻止LOP攻击的企图。 Loop-Oriented Programming是一种创新的代码重用攻击方式，它利用循环结构和精心设计的 gadget 链接，成功绕过了粗粒度控制流防护和阴影栈限制。这一领域的研究不仅对安全防御策略提出新要求，也为深入理解攻击者手法及其防御提供了新的视角。随着对抗性的攻防战不断升级，对LOP的理解和防御措施将直接影响到软件系统的安全性。

Loop-Oriented Programming: A New Code Reuse Attack to Bypass Modern

Defenses

Bingchen Lan, Yan Li, Hao Sun, Chao Su, Yao Liu, Qingkai Zeng

State Key Laboratory for Novel Software Technology

Department of Computer Science and Technology

Nanjing University, Nanjing 210023, China

Email: zongdugexia@163.com

Abstract—Code reuse attacks have become one of the most

popular exploitation techniques, and coarse-grained control

flow integrity (CFI) is a practical approach used to prevent

such attacks. Recently, some new approaches have been

proposed to construct call-preceded-ROP attacks to bypass

coarse-grained CFI, however, we find that they still fail to

bypass shadow stack, which enforces caller-callee semantics to

strengthen CFI that constrains the control flow in a much

stricter way. Therefore, in this paper, we propose a new code

reuse attack, named loop-oriented programming (LOP), aiming

to bypass both coarse-grained CFI and shadow stack. Quite

different from previous code reuse attacks, LOP collects entire

functions as basic building blocks (i.e., gadgets), and chains

these gadgets in a way that the control flows strictly follow the

process of call-ret-pairing. Specifically, LOP selects a

particular function with a loop statement, called loop gadget, to

chain all the available gadgets. To demonstrate the

effectiveness of LOP, we construct a proof-of-concept exploit

against Internet Explorer 8 on 32-bit x86 platform.

Keywords- Code Reuse Attack; Control Flow Integrity; Call-

Ret-Pairing; Loop-Oriented Programming

I. INTRODUCTION

In order to bypass traditional data execution protection

(DEP), code reuse attacks chain together a number of

instruction sequences, which are originally present in the

program’s address space, to conduct arbitrary operations.

The instruction sequence is commonly called gadget, and it

usually ends with an indirect branch. Generally speaking,

there are two steps to launch the attack: 1) searching for

gadgets, and 2) chaining gadgets via indirect branches. For

example, ROP [2] and SROP [28] choose short code

fragments inside functions as gadgets and chain them by ret

instructions, whereas the gadgets in JOP [4, 5] that consist of

short code fragments are chained by indirect jumps.

One of the most promising defense mechanisms against

code reuse attack is control-flow integrity (CFI) [23]. The

main idea of CFI is to derive an application’s control-flow

graph (CFG) prior to execution, and then monitor indirect

branches to ensure that the control flows follow a legitimate

path of the CFG. However, due to some limitations,

particularly the difficulty of obtaining a precise CFG without

source code and debugging symbols, most CFI solutions [16,

17, 18, 20, 21] have attempted to relax CFI policies by

applying it directly to binaries. Often, these loose policies

simply require that indirect call points to the beginning of a

function, and function should returns to any valid call site

(but not necessarily to the particular call site of the caller).

Recently, a number of proof-of-concept exploits have

been proposed to construct call-preceded-ROP attacks [7, 8,

10, 26] to bypass coarse-grained CFI. We refer to such

attacks as CPROP for short. Gadgets in CPROP begin right

after call instructions, and thus the control flow of ret

instruction can bypass the loose policies. As demonstrated in

CPROP, coarse-grained CFI solutions are ineffective and

weaker than generally thought.

In order to strengthen the security of coarse-grained CFI

solutions, defenders may further restrict the indirect branches

(indirect call, indirect jump, ret) in stricter way. First,

shadow stack [12] is a run-time defense to complement CFI

toward stricter protection for ret instruction. Second, there is,

however, no effective method to enforce strict policies for

indirect call and indirect jump since the difficulty to exactly

extract the target addresses in binaries. Although some works

[29] can guarantee the integrity of function pointers in a

program and thereby further restrict indirect call and indirect

jump, they are impractical as they need source code, which is

usually unavailable, particularly for commercial-off-the-shelf

(COTS). Therefore, strengthening coarse-grained CFI is

currently realized through shadow stack, which can defend

against CPROP and is usually considered as the most

restrictive protection for ret instruction.

Shadow stack [12] is a run-time mechanism for checking

that functions return to their caller. In the original CFI work,

Abadi et al. [23] utilize the shadow stack that is securely

maintained at runtime to harden CFI, and thus shadow stack

can complement coarse-grained CFI toward stricter

protection from code reuse attacks. The shadow stack usually

works that it keeps one copy for each return address in stack,

such that the ret instruction is forced to point to the

originally caller. Hence, shadow stack constrains the control

flows in a much stricter way by verifying the caller-callee

semantics, whereas CPROP violates this. Besides, some

works [19] have shown that the performance overhead of

shadow stack can be low. Hence, shadow stack is currently

an effective and practical defense that strengthens CFI

against code reuse attacks.

In this paper, our goal is to bypass the combination of

coarse-grained CFI and shadow stack, which we believe is

2015 IEEE Trustcom/BigDataSE/ISPA

DOI 10.1109/Trustcom-BigDataSe-ISPA.2015.374

190

下载后可阅读完整内容，剩余7页未读，立即下载

weixin_38562492

粉丝: 8
资源: 935

循环导向编程：突破粗粒度控制流防御的新攻击策略

riched20.dll

matlab面向对象编程.pdf

C#面向对象编程：封装与代码重用解析

面向对象编程：提升软件可扩展性和重用性

Java面向对象教程：继承与代码重用实例

Visual Studio C++入门教程：创建应用与代码重用

Vue3 Composition API：模块化与代码重用实践解析

ASP.NET用户控件：代码重用与面向对象编程的利器

面向对象编程：C++讲义概述

面向过程编程：基础与实践

最新资源