据MSRC（微软安全响应中心）艾德里安.斯通（Adrian Stone） 表示，这个问题他仍在整理当中，是个好问题。正如4月26日他在一篇博客中写道的："坦白地讲，这是一个合理的问题，而且作为曾负责这个案例的产品开发经理，我在整个调查过程中也一直在思索这个问题。"
而且，这个漏洞曝露时恰逢微软的SDL小组刚着手建立了一个博客，SDL小组是专门负责追踪安全问题并从中吸取教训来完善未来产品开发，而"从ANI漏洞中吸取的教训"也就成为此博客的第一篇文章内容。例如：从这些教训中，微软考虑到至少要将在第一轮去除行动中漏网的老代码（SDL之前）中调用去除。此外，该公司由此还替换了缓冲区堆栈检测并升级了其模糊工具。
对于此次微软可从中吸取的教训，微软安全工程组安全产品开发高级经理兼SDL架构师迈克尔.霍华德（Michael Howard）作了如下很好的阐述。他表示："SDL并不是完美无缺的，也永远不会达到完美无缺。摆在我们面前仍有工作要做，这个bug的出现也正很好表明了这一点。"
他还表示：ANI代码是一个相当老的代码，至少比SDL本身要'老'。在开发Vista时，有14万个调用被改为更安全的调用，甚至直接禁用某些APIs。Memcpy是用于在两个内存位置间拷贝数据的一个函数，并不在被禁止调用的初始列表中，但不久之后可能也逃不出这一命运。
而且现在，霍华德的团队正在调查禁用内存处理函数会在新代码上产生怎样的影响。他表示："我们将密切关注那些能掩饰安全漏洞的异常处理程序，而且memcpy的禁用对新代码的影响也将是我们要调查的内容。"
事实上，memcpy正是微软的静态分析工具未能及时发现.ANI bug的核心原因所在。Memcpy的问题在于：当它被用于一个调用时，它使得这一代码不会显式地展现出一个有错误位置的内存堆，因而不会被认定为缓冲区溢出漏洞。
而对于这个问题，不论是微软内部还是在微软外部似乎都束手无策。对此，霍华德表示，他的小组正考虑使用这一调用的一个变量memcpy_s来替代，这要求开发商要插入其目的地缓冲区尺寸。不过，具体实施还有待商榷。
此外，甚至有些深层防御措施也未起到阻挡ANI漏洞的作用，例如，/GS（缓冲区安全性检查）。微软已替换了-GS指令，并且由于原始-GS的某些问题，该公司还重新考虑启发编译器在处理-GS上的使用。
当然，这一切不会在一夜间发生。霍华德表示："…改变编译器是一项长期计划。至于短期内，我们有一个新的编译器指令，即强制编译器的防御更积极些。而且我们将开始在新代码上使用这个新的编译器指令。"
微软还将考虑将代码限制于用于捕获代码错误的异常处理程序中，霍华德称此为'代码的一个有趣的安全副作用'。他表示，一般情况下这一举措从安全性上来说是好的，但Vista包括有ASLR（地址空间布局随机化）功能可使得攻击者更难以找到关键函数的地址，从而增加了其入侵代码正常运作的难度。
"如果这个有漏洞的代码是位于一个处理许多错误的异常处理程序中的话，攻击者的攻击尝试失败的话就不会导致程序崩溃，从而使他可以用另一套地址进行再次尝试。"他表示。"值得注意的是这种能够'捕获所有错误'功能本身并不是一个安全bug，而且如果这异常处理程序中包含了带有漏洞的代码的话，甚至会帮助到攻击者进行攻击。"
微软还发现：通常许多bugs都会被SAL发现，而.ANI攻击正是通过不使用其SAL（标准注释语言）进行注解而避过一劫的。它是通过采用一个PVOID缓冲区而做到的，同时它在通过引用传递的一块代码边隐藏了其长度。对此，霍华德表示："如果SAL能读取这缓冲区长度，就会产生有关其可读取尺寸以及一个可能的堆栈型的缓冲区溢位的警报。"
同时，作为对.ANI攻击的回应，微软已强化其模糊工具来。由于它们中没有一个有充足的"anih"记录，模糊测试并未能在一开始就发现.ANI漏洞代码。霍华德表示："现在这个问题解决了，并且我们将继续强化我们的模糊工具来确保他们所添加操作能更好复制专用对象元素。"
当然，这次.ANI bug所带来的也不全是坏消息。霍华德就指出，由于有NAC和保护模式下的IE，恶意攻击可能算是走到头了，尽管这些攻击经专门编写可能偶尔会攻击到这些保护机制。
不过还是希望，微软会在这些攻击被编写时就快速作出响应。"我们的目标将是写好代码、抓出bugs、减少新bugs进入代码的机会。"霍华德最后说道。"我们备有一套适当的功能可补充这一流程的不足。我们从未预期过代码是完美无缺的，学习流程和深层防护层都是我们的必备措施。"
TAG: 微软