BH_US_08_Sotirov_Dowd_Bypassing_Memory_Protections.pdf资源-CSDN文库

需积分: 3 58 浏览量 2010-12-12 22:11:55 上传评论收藏 234KB PDF 举报

### 绕过浏览器内存保护机制 #### 概述本文档《BH_US_08_Sotirov_Dowd_Bypassing_Memory_Protections.pdf》由Alexander Sotirov和Mark Dowd撰写，旨在探讨如何绕过浏览器中的内存保护机制。在过去的几年里，微软在Windows平台上实施了一系列内存保护机制，如GS、SafeSEH、DEP(数据执行保护)和ASLR(地址空间布局随机化)，以防止常见软件漏洞被可靠地利用。这些保护机制使得许多内存破坏性漏洞难以被利用，看似为开发攻击者设下了难以逾越的障碍。然而，本文档深入分析了这些保护机制的局限性，并介绍了一些可以用来绕过这些保护的技术。 #### 论文结构 - **第一部分**：详细介绍将在文档后续部分讨论的所有保护机制。这一节包含了所有关于Windows Vista上可用保护机制的必要背景信息，包括它们的行为、任何可能修改其功能性的配置参数以及它们内部工作原理的相关细节。 - **第二部分**：探讨了第一部分中提到的保护机制的局限性，并讨论了可以用来帮助绕过各自保护的技术。 - **第三部分**：讨论了现实世界中的浏览器漏洞利用。这部分将展示如何将第二部分中概述的理论技术应用到实践中，以产生强大且可靠的远程代码执行漏洞。由于实际利用通常需要绕过多个内存保护机制，因此这部分将展示几种技术结合的方式以实现远程执行。此外，还将介绍一些传统技术的创新变化以及其他策略。 #### 内存保护机制及其局限性 - **GS保护**：这是一种用于检测和阻止栈溢出的技术。它通过在函数调用栈上插入特殊的“canary”值来检测栈溢出尝试。尽管GS可以有效地阻止一些栈溢出攻击，但攻击者可以通过控制流劫持技术（如ROP链）来绕过这种保护。 - **SafeSEH**：该机制用于保护结构化异常处理器免受篡改，防止攻击者通过重写异常处理程序来控制程序流程。然而，SafeSEH的保护效果有限，因为它只保护静态链接库，而许多动态加载的库不受保护。 - **DEP (Data Execution Prevention)**：这是一种防止非执行内存区域被利用的技术。DEP标记某些内存页为不可执行，从而阻止攻击者在这些区域内执行恶意代码。虽然DEP提高了安全性，但它并不能完全阻止所有类型的攻击，因为仍然存在一些方法可以将代码注入可执行内存区域。 - **ASLR (Address Space Layout Randomization)**：ASLR通过随机化程序的地址空间来增加攻击者的难度，使其难以预测特定库或代码段的确切位置。然而，通过泄漏信息和其他技术，攻击者仍有可能定位目标地址。 #### 浏览器漏洞利用实践在实际操作中，攻击者通常需要结合多种技术来克服上述保护机制，例如： - **ROP (Return-Oriented Programming)**：利用现有代码片段来构建有效负载，避免触发DEP。 - **Heap Spraying**：预先填充内存堆，以提高找到可执行内存的机会，尽管这种方法现在已被ASLR等机制所削弱。 - **Information Leakage**：通过各种手段获取内存地址或其他关键信息，以便精确地定位目标地址。 - **Bundling Multiple Exploits**：组合多个漏洞利用技巧来增加成功的机会。《BH_US_08_Sotirov_Dowd_Bypassing_Memory_Protections.pdf》提供了对浏览器内存保护机制的深入洞察，并探讨了如何绕过这些机制的具体方法。这对于安全研究人员和防御者来说是非常宝贵的资源，可以帮助他们更好地理解现代攻击技术和防御策略。

资源推荐

资源详情

资源评论

Bypassing Browser Memory Protections

Alexander Sotirov <alex@sotirov.net>

Mark Dowd <markdowd@au1.ibm.com>

Introduction

Over the past several years, Microsoft has implemented a number of memory protection

mechanisms with the goal of preventing the reliable exploitation of common software

vulnerabilities on the Windows platform. Protection mechanisms such as GS, SafeSEH, DEP and

ASLR complicate the exploitation of many memory corruption vulnerabilities and at first sight

present an insurmountable obstacle for exploit developers.

In this paper we will discuss the limitations of all aforementioned protection mechanisms and will

describe the circumstances in which they can fail. We aim to show that the protection

mechanisms in Windows Vista are particularly ineffective for preventing the exploitation of

memory corruption vulnerabilities in browsers. This will be demonstrated with a variety of

exploitation techniques that can be used to bypass the protections and achieve reliable remote

code execution in many different circumstances.

Organization of this paper

This paper is divided into three parts. Part 1 is concerned with describing the protection

mechanisms that will be addressed in the remainder of the paper. This section contains all the

necessary background information about the available protection mechanisms on Vista. It

describes their behaviour, any configuration parameters that modify the functionality of the

mechanism, and where relevant, some of the internals of how they work. Part 2 will then address

the limitations of the protection mechanisms presented in Part 1. Here, techniques will be

discussed that can be employed to help bypass each of the respective protections. Finally, Part 3

of the paper will discuss browser exploitation in the real world. Essentially, it will show how the

theoretical techniques outlined in Part 2 can be utilized to produce robust and reliable exploits

that work effectively in the wild. Since real-world exploitation requires bypassing of multiple

memory protections, Part 3 will present several ways in which techniques can be combined to

achieve remote execution. Furthermore, some interesting twists on these traditional techniques

as well as alternative strategies will be presented by utilizing various popular or natively

available technologies.

char a[5]; // protected, 5 byte array of elements of size 1

short b[3]; // protected, 6 byte array of elements of size 2

struct {

char a;

} c[5]; // protected, 5 byte array of elements of size 1

struct {

char a[5];

} d; // protected because the structure contains a string buffer

Functions that don't use _alloca and don't contain variables considered to be string buffers are

not protected by GS. For example, the variables below will not trigger the GS heuristic:

char e[4]; // not protected, total size is less than 5 bytes

int f[10]; // not protected, array element size greater than 2

char* g[10]; // not protected, array element size greater than 2

struct {

char a;

short b;

} h[5]; // not protected, array element size greater than 2

struct {

char a1;

char a2;

char a3;

char a4;

char a5;

} i; // not protected because the structure does not contain a string

buffer

Visual Studio 2005 SP1 introduced a new compiler directive that enables more aggressive GS

heuristics. If #pragma strict_gs_check is turned on, the compiler adds a GS cookie to all

functions that use arrays, dereference data through pointer arithmetic or pass the address of any

local variable to another function. This results in a much more complete protection at the

expense of runtime performance.

Variable reordering

The main limitation of the GS protection is that it detects buffer overflows only when the function

with the overwritten stack cookie returns. If any other overwritten data on the stack is used by

the function, the attacker might be able to take control of the execution before the GS cookie is

checked.

To prevent the attacker from overwriting local variables or arguments used by the function, the

compiler modifies the layout of the stack frame. It reorders the local variables, placing string

buffers after all other variables. This ensures that a string buffer overflow cannot overwrite any

other local variables. Function arguments that contain pointers or string buffers (called

vulnerable arguments in the compiler documentation) are protected by allocating extra space on

the stack and copying their values below the local variables. The original argument values

located after the return address are not used in the rest of the code.

The following diagram shows the stack frame layout of a vulnerable function with and without GS

protection:

vuln.c

standard stack frame

stack frame with /GS

void vuln(char* arg)

{

char buf[100];

int i;

strcpy(buf, arg);

...

}

buf

return address

arg

copy of arg

buf

stack cookie

return address

arg

Without GS a buffer overflow of the buf variable will allow the attacker to overwrite i, the return

address and the arg argument. Enabling GS adds a stack cookie, moves i out of the way and

creates a copy of arg. The original argument can still be overwritten, but it is no longer used by

the function. The attacker has no way of taking control of the execution before the cookie check

detects the overflow and terminates the program.

SafeSEH

SEH handler validation

The SafeSEH protection mechanism is designed to prevent attackers from taking control of the

program execution by overwriting an exception handler record on the stack. If a binary is linked

with the /SafeSEH linker option, its header will contain a table of all valid exception handlers

within that module. When an exception occurs, the exception dispatcher code in NTDLL.DLL

verifies that the exception handler record on the stack points to one of the valid handlers in the

table. If the attacker overwrites the exception handler record and points it somewhere else, the

exception dispatcher will detect this and terminate the program.

The validation of the exception handler record begins in the RtlDispatchException function. Its

first task is to make sure that the exception record is located on the stack of the current thread

and is 4 byte aligned. This prevents the attacker from overwriting the Next field of a record and

pointing it to a fake record on the heap. The function also verifies that the exception handler

address is not located on the stack. This check prevents the attacker from jumping directly to

shellcode on the stack.

The exception handler address is validated further by the RtlIsValidHandler function. The

pseudocode of this function in Vista SP1 is shown below:

BOOL RtlIsValidHandler(handler)

{

if (handler is in an image) {

if (image has the IMAGE_DLLCHARACTERISTICS_NO_SEH flag set)

return FALSE;

if (image has a SafeSEH table)

if (handler found in the table)

return TRUE;

else

return FALSE;

if (image is a .NET assembly with the ILonly flag set)

剩余27页未读，继续阅读

评论收藏

内容反馈

wellcome_zhu

粉丝: 0
资源: 8

BH_US_08_Sotirov_Dowd_Bypassing_Memory_Protections.pdf

sotirov-bg.net:sotirov-bg.net资料来源

WinRing0.zip

Heap Feng Shui in JavaScript.doc

slackpack:松弛包

SHA-3竞赛第三轮算法（BLAKE,Grotl，Skein，JH，Kecca）

ASPack加壳工具

javascript堆栈风水

Heap Overflow Exploits

JavaScript中的堆风水

重庆邮电大学国际学院通信工程专业-大一~大三各科目笔记汇总

群晖DS918+ dsm7.0.1 集成8125b网卡驱动 引导文件 镜像

DS918.zip DS918.zip DS918.zip

syno_search_fullpack.zip

csv文件下载（人员信息.txt)

RePKG.rar文件

CBM2199E量产工具

VisionMaster4.0.0

ocr-zh-cn.rar主打一个免费

tools.zip tools.zip

DSM7.X套件.zip

Webyog SQLyog Ultimate

PPSSPP全套金手指分享 99%游戏都会有 中文，英文双套整合版

群晖NAS系列教程.zip

Unity TextMeshPro中文字体20000个字符微软雅黑_亲测可用

山东大学 软件学院 软件工程 最优化 往年题汇总

M3U8下载器，用于根据M3U8地址下载文件

DS3617.zip DS3617.zip

HD-百度网盘扩容软件

DS3617(6.17引导与系统安装包).zip

最新资源

群晖DS918+ dsm7.0.1 集成8125b网卡驱动引导文件镜像

PPSSPP全套金手指分享 99%游戏都会有中文，英文双套整合版

山东大学软件学院软件工程最优化往年题汇总