在上个月，我们为方程式组织被泄漏的ESTEEMAUDIT漏洞撰写了一个简要的分析，并且直到我们发现这一漏洞攻击只适用于加入Windows域的计算机前，我们都在试图去重现这个问题，不过相对来说编写补丁还是相当简单的。下图显示了当检测到并阻止ESTEEMAUDIT攻击时显示的源代码和“Exploit Attempt Blocked”对话框。

我们的补丁很简单：我们先去检查从远程智能卡收到的数据（由ESTEEMAUDIT模拟）是否大于80h，这是gpkcsp.dll中目标缓冲区的大小。如果接收到的数据较大，并且使用ESTEEMAUDIT，则我们首先警告我们本地运行的0patch代理（弹出警报），然后将接收到的数据的大小减小到80h，以防止缓冲区溢出。通过在原始代码中引入4个机器指令，可以有效地阻止攻击而不会中断那些合法功能。

而在大约一个月后，微软公布了ESTEEMAUDIT和其它漏洞的官方更新，并且表示会向客户提供更多的支持。这是非常好的，因为官方的供应商更新是修复漏洞的首选方法，我们的目标是为那些还未修复的问题在修复前提供尽可能的服务，或者在安全更新时间差中为一些客户组织提供对关键漏洞的保护。

当然，我们对微软如何修复这个漏洞非常感兴趣，并将其修复方案与我们的进行了比较。输入IDA Pro和BinDiff，几分钟后，我们就可以并列的去比较两者了。

在左边的固定代码和右边的易受攻击的代码上，微软的补丁在完全相同的位置也引入了同样的检查。我们修复方案的主要区别在于，尽管我们将接收到的数据切割为有效长度，但如果数据太长，则仍然会产生错误，并放弃连接。

这是非常有道理的，因为官方补丁就是应该提供故障排除信息，微软应该尽量用最小的代码关闭漏洞。

当然我们也发现了非常惊喜的地方——BinDiff展现了了另一个变化。

在代码中的其他地方，微软也添加了类似的检查——检查接收到的数据长度超过80h，如果是，则返回错误。

他们显然审计了他们的代码，并注意到在另一个DoSCardTransmit调用之后存在类似的错误，并修复它。请注意，这个第二个错误并没有被ESTEEMAUDIT利用，但是很有可能会由第一个bug 进而被发现。微软和其他类似的软件供应商经常在他们的代码中搜索那些类似已发现的漏洞（内部或外部），并主动修复它们。

毫无疑问，这个被发现的第二个问题也给我们带来了新的问题：还有其他类似的问题吗？

在gpkcsp.dll中有66次对DoSCardTransmt调用，我们来简要地看看他们。事实上，我们对接收到的缓冲区将被复制到其他缓冲区的情况很感兴趣。实际上还有一个这样的情况，除了微软修补的问题，如下图所示：

同样，最新的gpkcsp.dll还是位于左侧，但显然这里没有添加任何数据长度检查。该代码与易受攻击的代码存在相似的嫌疑，但它实际上取决于ds上的目标缓冲区的大小：[edx + ebx]。我们没有时间进一步了解这一点，但是我们希望微软去进行尝试并确认它是不可利用的。

最后顺便说一下，ESTEEMAUDIT漏洞被分配了代号CVE-2017-9073，但微软将其修复与CVE-2017-0176进行了相互的关联。这很容易会引起一些混乱，让人们想知道两个CVE是否是重复的。基于对Microsoft的修复的上述分析，似乎可以准确的说一点，CVE-2017-9073其实是CVE-2017-0176的一个子集，前者只是ESTEEMAUDIT漏洞，而后者还包括上文中所述的第二个类似的问题，微软也进行了修补。