Bypassing Browser Memory Protections读后笔记 || 中国X黑客小组


	您现在的位置：中国X黑客小组 >> 技术文章 >> 黑客技术 >> 黑客教学 >> 文章正文	用户登录新用户注册

Bypassing Browser Memory Protections读后笔记

★★★

【字体：小大】

Bypassing Browser Memory Protections读后笔记

作者：刺文章来源：http://hi.baidu.com/aullik5 点击数：更新时间：2008-8-12

Alexander Sotirov 和 Mark Dowd 这次在BlackHat的paper果然内容很丰富，链接就不加了， google一下应该就有。

这次paper里没啥新的东西，基本上是关于绕过GS/SAFESEH/HEAP/DEP/ASLR等技巧的一些总结。不过文章非常具有系统性，很多细节的地方讲的都很清楚。

比如关于GS保护，原来和编译器的关系如此紧密，而vs2005为了修补一些编译器里遗漏的地方而增强了安全性:

Since the C language has no native string type, the compiler defines a string buffer as an array
of 1 or 2 byte elements with a total size of at least 5 bytes. The GS protection is applied to all
functions with arrays that match this description.

......

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.

而SafeSEH有一个细节：

By default, in processes with DEP enabled there are only two types of exception handlers that
are considered valid by the exception dispatcher:
1. handler found in the SafeSEH table of an image without the NO_SEH flag
2. handler on an executable page in an image without the NO_SEH flag, without a SafeSEH
table and without the .NET ILonly flag
In processes with DEP disabled there are have three valid cases:
1. handler found in the SafeSEH table of an image without the NO_SEH flag
2. handler in an image without the NO_SEH flag, without a SafeSEH table and without the
.NET ILonly flag
3. handler on a non-image page, but not on the stack of the current thread

这两种情况让我想起来了我在前段时间调试dir溢出时候遇到的那个RPWT，在我的xpsp2上死活不跳转，如果根据这里的说法，应该就是我当时开了DEP有关。

原来safeseh的跳转和DEP还有关系，这是void在分析safeseh的tips里没有提到的。

绕过DEP还是用的uniform里的skape的文章，以前我也写过文章来验证。
[Tips]Bypass Hardware DEP Tips

而关于ASLR，原来还有这么个注册表项来控制开关：
This behaviour is controlled using the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\MoveImages, which by default does not exist. The following behaviour is defined
for this key:
1 If the value is set to 0, never randomize image bases in memory, always honour the base
address
2 If set to -1, randomize any image regardless of whether they have elected to take part in
ASLR or not (providing they are relocatable).
3 If set to any other value, randomize only images that have elected to take part in
randomization. This is the default behaviour.

那这个开关就和Redhat下的 /proc/sys/kernel/randomize_va_space 这个参数差不多了,可以控制ASLR

第二部分是关于一些介绍保护机制缺陷的内容。都是在写exploit的时候可以用到的一些高级技巧。

比如绕过GS的时候，选择部分覆盖（Partial Overwrites），以前我在写一个mail方面的exp的时候就曾经用过这种技巧，结果就是写出来的exp非常之通用，与平台和语言都无关了。

而infoleaks 这种漏洞在绕过ASLR的时候是最爽快的。以前写imail exp的时候，就曾经用到过这种技巧，把当前栈的基址读了出来，然后再去写精确定位的exp。另外一个例子就是在the Month of PHP Bugs 的时候出过一个读PHP内存里内容的bug，结果后来Stefan Esser就以这个bug为基础，写了一系列exploit来精确定位返回地址，覆盖ret，溢出其他的php bugs。如果没有这种读infomation的bug，他写其他exploit的时候可能会在ASLR上遇到极大的困难。

作者在第二部分里提到的在JVM中使用heap spray, 很奇怪为啥在第三部分中没有出现了，难道是作者忘了？

虽然作者忘了，可是我却没有忘，因为早在2007年3月幻影就提出了在JVM中使用heap spray技术，我记得很清楚，当时是为了溢出一个jre的漏洞，是由luoluo poc实现的，由于这个家伙懒，所以最终是由我整理的paper。[Paper]Advanced Heap Spray Technique -- Heap Spray in Java

最后才是dowd这个paper的精华之处。为啥这么说呢？因为前面都是别人的东西，最后才是作者自己的东西。他们利用flash来绕过ASLR/DEP/GS/SAFESEH，估计flash里的那些地址都是 dowd在研究上次那个 exploit flash reliable的paper里附带发现的。

flash这个控件居然没有safeseh标记，还是固定加载地址，实在是无语了。

不过我听说好像flash新版本是有安全更新的，已经开始ASLR了，难道我记错了，或者是我产生了幻觉？

不管怎么样，估计flash里的这个地址用不久了。

有人也许会说，倒下一个flash，还有千千万万的xxxxlash，可是，还有谁有flash这么高的覆盖率呢~~~？ #_#

文章录入：空虚浪子心责任编辑：空虚浪子心

上一篇文章： Java applet 安全性探究

下一篇文章：没有了

【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口】

最新热点		最新推荐		相关文章
				没有相关文章

　网友评论：（只显示最新5条。评论内容只代表网友观点，与本站立场无关！）


关于我们 - 版权声明 - 帮助(？) - 广告服务 - 联系我们 - 友情链接 - 用户注册 -	Powered by ICE RIVER - STUDIO

» CnXHacker.CoM