Earlier this month, Microsoft released MS16-035 that addresses issues I previously reported in SignedXml. They did not only fix the duplicate Id vulnerability I reported though, they also fixed a number of other issues – introducing some breaking changes. This post is an effort to document those and changes and the registry switches that can be used to revert back to the old behaviour.

These are the breaking changes I know about. If you know of any more issues, please leave a comment or drop a mail and I’ll try to update the post.

1. Duplicate Ids for reference elements no longer allowed (applies to both SignedXml and EncryptedXml)
2. Id values must be a well formed NCName (which is required by the XML standard, applies to both SignedXml and EncryptedXml)
3. External references disabled by default
4. XPath Transform disabled by default
5. XSLT Transform disabled by default

Duplicate Ids for Reference Elements not Allowed

This was the issue that I reported and that makes a signature wrapping attack possible. See my previous post for details. To disable the new behaviour, add a registry DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security@SignedXmlAllowAmbiguousReferenceTargets=1. Don’t do this unless you really know the consequences. Unless all applications on the system have applied workarounds to strengthen the reference checking this is a really bad idea.

Well formed Id values

According to the XML specification, the value of the Id attribute must follow the rules for an NCName. The standard has always been clear about that, but the .NET framework has not enforced it. Well behaved applications that need to communicate with systems on other platforms have of course already followed the rules. But .NET-only applications may of course have been ignorant and still worked. Until now.

To disable the NCName requirement, add a registry DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security@SignedXmlRequireNCNameIdentifier=0. I can’t imagine any attack vector related to non-NCNames, so it as far as I can tell it is safe to enable this setting.

External References Disabled by Default

XML DSig allows for a signature to verify data that is located somewhere else, e.g. a URL to a document. During signature validation that URL will be downloaded. Code that unexpectedly downloads external data is definitely a candidate for all kinds of nastiness. The obvious is denial of service, by using a URL that points to a huge document that fills the memory of the server. It is a good decision to turn this off by default, but for any application that actually uses this functionality it needs to be reenabled. To do that add a registry DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security@SignedXmlAllowDetachedSignature=1 or use the reg file from Microsoft’s knowledgebase article.

XPath Transform Disabled by Default

XML Dsig can use an XPath expression to select what parts of a document is protected by the signature. By crafting a special XML document that is very computationally expensive to apply the XPath expression to, a denial of service attack can de done. To mitigate that, the XPath Dsig transform is now disabled by default. For any application that actually uses this functionality it needs to be reenabled. To do that add a registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security\SafeTransformMethods@XmlDsigXPathTransform=http://www.w3.org/TR/1999/REC-xpath-19991116 or use the reg file from Microsoft’s knowledgebase article.

XSLT Transform Disabled by Default

XML Dsig can use an XSLT transform to select what parts of a document is protected by the signature. By crafting a special XML document that is very computationally expensive to apply the XSLT transform to, a denial of service attack can de done. To mitigate that the, XSLT Dsig transform is now disabled by default, but for any application that actually uses this functionality it needs to be reenabled. To do that add a registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security\SafeTransformMethods@XmlDsigXsltTransform=http://www.w3.org/TR/1999/REC-xslt-19991116 or use the reg file from Microsoft’s knowledgebase article.