I wanted to share the response that I received from Microsoft and provide some of my own feedback. I must admit that I was initially floored by their response, which was:

"Thanks for bringing this to our attention. While I understand your concern, this is in fact expected functionality of the security update."

[removed discussion of issue]

There are important reasons why this path was chosen: it is not possible to tell legitimate WPAD entries from illegitimate ones that were loaded by attackers. Hence our need to accept an already "existent" entry as being valid.

They also pointed me to a KB that references this issue. What's interesting is that this KB wasn't referenced in the advisory release; it was added today as a 'Minor Update'

V1.1 (March 11, 2009): Clarified that CVE-2009-0093 does not apply to supported editions of Windows Server 2008. Added a link to Microsoft Knowledge Base Article 962238 under Known Issues in the Executive Summary. Clarified what systems are primarily at risk for CVE-2009-2033. Finally, updated a finder acknowledgment for CVE-2009-0233 and CVE-2009-0234.

I was then asked in future to wait for a response from them before having such discussions publicly. Anyone who knows me knows that I fully support contacting the vendor when you have a newly discovered vulnerability and I've always reported my findings to Microsoft first. In this case, however:

1. This was not a newly discovered vulnerability. How to exploit the vulnerability was already public knowledge.
2. This public discussion did not benefit malicious individuals. It did, however, raise some awareness with Microsoft's customers who may believe they are adequately protected when they are not.

So why was I floored by Microsoft's response? They didn't actually patch this vulnerability; instead they introduced a means of mitigation and deployed that mitigation in the update. That alone would be fine. The issue I have is that they have punted security altogether in the interest of functionality. The responsible thing to do would be to find a balance between the two.

There are a number of approaches that Microsoft could have taken here, that they chose not to take:

1. Provide a simple message during installation of the patch, notifying the user of existing wpad or isatap entries in the DNS server zones and informing them that the intended mitigation would not be applied.
2. Modify the way that dynamic updates work to provide a dynamic update block list, restricting wpad or isatap from being updated dynamically. As it stands right now you can still submit updates for these, they just wont be resolved if they exist in the global query block list.
3. Add both entries to the global query block list and allow users to go back and remove them if the functionality was required.
4. Bring this case to the public as part of the original Advisory if they already knew about it.

These are quick examples from a long list of alternative approaches that could have been taken - each of which would have provided more responsible guidance to their customers than the "don't ask; don't tell" method that they chose.

I'm probably the the biggest Microsoft supporter within VERT. I'm a huge fan of the work they've done to improve security across the board. That being said, I can't help but see this as a step backwards. I understand the need to preserve functionality, but not at the cost of sweeping security issues under the rug. Simply providing a comment within the original advisory would have been a step forward. Instead, no notification was provided to their customers until after I had brought the issue to their attention. Even then, the response was a single line linking to a KB. That KB contains a list of other KBs and one of those contains a single line indicating that this may occur. This suggests that Microsoft was aware of this issue and released their update with minimal concern for security. I believe their customers deserve more.

Earlier today, Larry Seltzer commented that "Microsoft updates don't undo exploits". This is 100% true; however undoing the exploit in this case would be reverting a configured wpad/isatap entry. I'm not asking Microsoft to undo exploits; I'm simply asking that they provide the mitigation that their advisory claims it will provide or proactively advise customers that a particular risk has been accepted on their behalf.

In this case, they provided neither guidance nor remediation.

Winner: functionality by technical knock out.