php sqlsrv query MS15-083：Windows SMB内存损坏漏洞分析

php sqlsrv query MS15-083：Windows SMB内存损坏漏洞分析

2015年8月11日微软发布了14个安全补丁，其中就包括一个SMB服务器补丁。在本文我将解释我是如何触发该漏洞的。

微软安全公告MS15-083

在所有的修复补丁中，我对“服务器消息块中的漏洞可能允许远程执行代码”很感兴趣。

“当服务器信息块(SMB)不当处理某些日志记录活动，引发一个经过身份验证的远程代码执行漏洞，最终导致内存损坏。”

受影响的版本包括32位和64位的 Vista 和 2008，值得注意的是，这是自2011年以来微软发布的第一个SMB服务修复补丁。

安装补丁

下载“

.0–x86.msu”补丁之后，我试图进行安装，没想到出现了这个

对此我感到有些意外，因为当安装好一个内核补丁后，操作系统都会进行重启。但在这个例子中php sqlsrv query MS15-083：Windows SMB内存损坏漏洞分析，补丁安装程序并没有提示我进行重启。

在“c:\”中我发现“srv.sys”和“.sys”都被变更了。

另外，我还注意到新的“.sys”文件日期为2011年4月，新的“srv.sys”文件日期显示正常。

差异阶段–Part 1

将新的“srv.sys”版本(v6.0.6002.19438)与2011年发布的MS11-020版本(v6.0.6002.18407)进行对比，惊奇的发现代码根本就没有任何改动!要说有改动也就是编译的字符串改动了。

我寻找着有关该补丁的一些信息，最终在上找到Greg 发的一条有关“.sys”中代码变动的信息。

我联系上Greg之后确认了补丁安装程序的错误，同时感谢其指点，通过使用“.exe”命令手动解压了该补丁。

差异阶段–Part 2

补丁解压完成之后，我发现“srv.sys”和“.sys”的两个版本。将旧的.sys”版本(v6.0.6002.18462) 和新版本(v6.0.6002.23746)进行差异比较，两个版本都使用相同的补丁安装程序。

在其中我发现7个函数进行了重要改变，更多的则是改动很小：

face

ocket

通过微软安全公告的描述“某些日志记录活动”，所以我重点关注了下“”函数，以下为原始代码与新版本的差异比较：

可以清晰的看到修复了一个整数溢出。

关注“try”调用代码，可以看到这个修复防止了当日志消息大小大于255字节时“ size”被重新初始化为0。

如果这发生在未打补丁的版本上，没有足够的内存分配给日志消息记录就会产生一个堆溢出。出于某些原因，“ size”变量使用的无符号字符型传递参数是不正确的。在新版本代码中，该变量调整为无符号整型。

差异阶段–开盖有奖

检测“”函数在两个版本中的变化，我注意到在 7, 8, 8.1 and 10中这个漏洞依旧存在。

下图为“ 10” 64位中漏洞基本块图像，“.sys” v10.0.10240.16384部分：

另一方面要说的是，该问题在 2008 R2中被静默修复。

尽管在这些操作系统中重现漏洞是被禁止的，阐明“”函数通过“.sys”输出，以及当使用SMBv1建立SMB连接依旧调用“srv.sys”是非常重要的。

这也意味着，任何驱动(官方或者第三方)调用这个输出函数，这个漏洞将会重现。

利用该漏洞可能的方法

一旦检测到该漏洞，最大的挑战便是写exp找到正确的输出触发该漏洞，本例中我们借助SMB协议。

以下插图为所有的影响到“”函数的方法

在第六个论点中函数接收一个字符串列表进行记录，在第七个论点中其接收数字字符串进行记录。

顺着调用图表一直调用，我发现一个来自“”函数的十分有趣的调用，位于相同的库(.sys)

继续查找，发现该输出函数仅通过函数进行调用，出现在“srv.sys”和“srv2.sys”.

这也就意味着可以使用SMBv1和v2协议进行攻击。有趣的是，在MS11-020补丁中也调用了“”函数

触发阶段–Part 1

使用 7通过执行类似“\192.168.60.60”命令指向到 2008，可以看到通过SMBv2当SMB服务接收到一个“ Setup ”包以及“”选项时，“srv2!uffer”就被调用了。

以下为影响漏洞函数的第一个要求

”变量的值不同于0php sqlsrv query，这个值我们可以在注册表“\\\

”中查看，该值为“ SPN name level”策略相关的设定，也是“SMB ”的一部分。

触发阶段–Part 2

将值设置完毕之后，新的问题又出现了

“”函数返回错误代码：，这也意味着，如果这个值不为0，就不能调用记录函数。

阅读msdn文档，我意识到返回值得意思为“”

“”函数接收“esW”函数的输出作为参数，位于“.sys”

在第二份文档中，我意识到“”参数的值应该设置为0x1b，意思与“

”相同。

以下为这个常数的描述：

分析“!esW”函数的代码，我确认已经不支持该常数了。

这里就矛盾了，因为补丁修复“ Vista”和“ 2008”中的漏洞php sqlsrv query，但是这些能够影响到漏洞函数的方法却无法在这些系统中实现!

触发阶段–Part 3

再次浏览微软公告页面，发现了一个参考链接“ for ” (EPA).

为了寻找更多有价值的信息，我在“ and Blog”中发现一篇名为 for 的文章。

部分阅读：

“微软发布了几个非安全的更新实现身份验证保护延长的机制，用以维护在平台上的身份认证凭证….”

从第一个博客链接中我下载并安装了EPA for 2008：

触发阶段–Part 4

EPA安装完成之后，“

”注册表键设置为1或者2，启用“File ”选项并关闭“ ”选项。“esW”函数返回0(“”)

当“esW”函数的“”参数返回这个值，就变得更加有趣了

使用进行嗅探，我意识到“”参数返回“ Name”的属性“ ”结构，包含在“ Setup AndX ”包中。

基于连接的SMB版本，这是第三个或者第四个SMB客户端发送的数据包

当我意识到这点，我开始构建和发送“ Setup AndX ”数据包，就象这样：

再然后就这样了

利用阶段

微软标记的该漏洞的可利用性分数

现在，我们来看看触发这个漏洞之后到底发生了什么

当尝试释放 “try”函数分配的当前块( CHUNK)，“nt!”产生了一个内核异常错误。

最重要的是注意到的是产生堆溢出的池类型()，这里给出一个完整的池类型列表

再细看下

“nt!”函数检测到下一个头为。在本例中，我们看到当前块为，下一个为php sqlsrv query，这就说明下一个头为“41 41 41 41 41 41 41 41”

当前块的头为有效值会发生什么？

分析当前块的头，不难发现以下规律：

9 bits ( chunk size / 8) + 7 bits (misc) + 9 bits ( chunk size / 8) + 7 bits (|free|misc) + 4 bytes (TAG)

我控制着写入的所有数据，所以我可以设置下一个块第一个字段为有效值。

比如，如果“try”函数分配256 bytes给块(0×100的16进制值)，那么“ chunk size”的下一个块的头为0×100 / 8 = 0×20

事实上，如果我设置一个正确的值覆盖“ chunk size”当释放当前块，那么也就不会触发漏洞了，目标也就不会崩溃了。

当我们知道如何绕过第一个BSoD，就可以通过使用各类堆技术实现远程利用的艺术。

利用想法

为了利用这个漏洞，我可以使用一个比较老套的技术“堆合并”。

此外，如果我能够准确控制远程配置php sqlsrv query MS15-083：Windows SMB内存损坏漏洞分析，我可以覆盖一个内存对象，这样就获得多个写入的机会。

还有一个选择就是覆盖函数指针的低部分。

我可以覆盖的最大内存大小超过了分配的块，接近

在这个漏洞，最重要的利用过程就是利用失效或者内核崩溃，目标将会自动重启。

很明显，利用很棘手。但是我不确定微软给出的漏洞利用性是否正确。

后记

2015年9月8日再次更新了这个漏洞补丁

目前补丁安装程序正常运行

但是，进修复了“”函数

另一方面 XP和 2003由于停止维护，漏洞依旧存在