Last week, I wrote about how the installation of KB954459 broke our usage of the ServerXMLHttpRequest objects. After putting together a test case, I e-mailed it to Microsoft's XML Team, glad to have found the bug and hoping for a fix to come soon. While Microsoft was quite quickly able to confirm my bug, they don't plan to fix it.

From: Samuel Zhang ****@microsoft.com To: "Craig, Jeff" ******@wsu.edu, Xml Team Bloggers xmlblogs@microsoft.com Date: Thu, 25 Dec 2008 22:49:12 +0800 Subject: RE: (Microsoft XML Team's WebLog) : KB954459

Hi Jeff,

Thanks for the sample. We have verified that this is due to a security fix in KB954459, as described in bulletin MS08-069, especially in section MSXML Header Request Vulnerability - CVE-2008-4033. MSXML no longer supports modifying referer header, so we suggest you to apply KB954459 and change your design. Thank you for your understanding.

Samuel

Now, I'd been over that particular security bulliten backwards and forwards prior to e-mail Samuel's team, and I hadn't seen anything regarding problems with the "referer" header, only the "transfer-encoding" header. My gut reaction, and this may be really unfair to the Microsoft XML Team, is that dropping the referer header was a gut reaction, and an unnecessary one. The gist of the exploit, is that the MSXML objects could have been used to make a remote request that violated the "Same Origin" policy used on the web, resulting in unintended information disclosure. And since Outlook uses the same rendering engine as IE for it's HTML e-mail, this exploit would work equally well with HTML e-mail as a crafted web page.

At this time, I am unable to find any information about the research that went into uncovering this vulnerability. Microsoft reported it was reported from outside their organization using "responsible disclosure", and I really hope that now that the fix is available, the researchers will publish their research. But still, I am left thinking that the object was overly neutered in order to correct the issue. For one thing, the "ServerXMLHttpRequest" object should never have been available in the scope of Internet Explorer, and it doesn't make sense to reduce the scope of the ServerXMLHttpRequest just because the scope of the XMLHttpRequest object needed to be (rightly) reduced.

Luckily, there is a solution. Microsoft also has available the "WinHttp.WinHttpRequest.5.1" object, which exposes a nearly identical interface as the ServerXMLHTTPRequest object. I suspect that the return of WinHttp would require a few more steps to be usable in the MSXML library, so working with XML data as a data source using WinHttp may be more difficult, but it wasn't really an issue for what we're trying to do.

The good news is that we can now apply KB954459 to our web servers and continue to function as normal. However, I still greatly disagree with the methods Microsoft used to implement this fix, as they reduced functionality in an object that shouldn't have been affected by the attack vector described in the security bulletin. If I can get a better justification as to why the Server object was affected, I may change my story, but until then, I'm going to remain unhappy with this solution.