MSXML 4.0 SP3 Release Notes

Note: If you have previously installed MSXML 4.0 SP3 BETA, you MUST uninstall the BETA package before installing MSXML 4.0 SP3 RTM. Windows Vista/Windows Server 2008 customers, please refer to section 2.

MSXML 4.0 SP3 is a complete replacement of MSXML 4.0, MSXML 4.0 SP1, and MSXML 4.0 SP2. This service pack provides a number of security enhancements and reliability improvements.

MSXML 4.0 was released to the web about nine years ago. MSXML 4.0 has been superseded by MSXML 6.0, and is only intended to support legacy applications. Both MSXML 4.0 SP2 and SP3 are entering maintenance mode now, therefore no new functionality and performance improvement will be made in MSXML 4.0, servicing will be restricted to high impact security issues. There are no plans for future MSXML 4.0 service packs.

Support will end for MSXML 4.0 SP2 in 4/13/2010.

Users should upgrade from MSXML 4.0 to MSXML 6.0. MSXML 6.0 will continue to be developed. MSXML 6.0 provides improved W3C compliance and increased compatibility with System.XML in the .NET framework. Key changes introduced between MSXML4 and MSXML6 and their migration are described in Upgrading to MSXML 6.0.

MSXML6 is now available for all supported down-level platforms. It is either shipped with Windows (e.g. Windows XP SP3 and Windows Vista) or can be downloaded from Microsoft Download Center.

1         Upgrading to the MSXML 4.0 SP3

The following are important notes about proper installation of MSXML 4.0 SP3:

·         MSXML 4.0 SP3 is not installed or upgraded by default.

·         To properly install or upgrade to MSXML 4.0 SP3, download and run the setup package.

·         The SDK is not shipped alongside the setup package since the interfaces are not changed. Developers can use the header files from the MSXML6 SDK and refer to MSDN for documentation.

In order to rolling back from MSXML 4.0 SP3 to MSXML 4.0 SP2, a customer can download MSXML 4.0 SP2 MSI package and

·         Uninstall all MSXML 4.0 products in the system, then re-install MSXML 4.0 SP2, or

·         Use command line “msiexec msxml4sp2.msi /fdmus” in the same folder of the MSI package.

2         Customers who have previously installed MSXML 4.0 SP3 BETA

If you have previously installed MSXML 4.0 SP3 BETA, you MUST uninstall the BETA package before installing MSXML 4.0 SP3 RTM.

Windows Vista/Windows Server 2008 customers that have installed MSXML4 SP3 BETA, please follow these steps to ensure successful installation of MSXML4 SP3 RTM:

1.       Uninstall MSXML 4.0 SP3 BETA.

2.       Click Start, and then type cmd in the Start Search box.

3.       In the search results list, right-click cmd, and then select Run as Administrator.

4.       When you are prompted for confirmation by User Account Control, click Continue.

5.       From the command prompt, type:
reg delete HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\x86_microsoft.msxml2r_6bd6b9abf345378f_4.30.2100.0_none_03d8af9e7277524d
and press return. Press Y and return when the system asks if you want to delete the registry key. Then the operation shall complete successfully.

6.       Install MSXML 4.0 SP3 RTM.

3         Supported Operating Systems

MSXML 4.0 SP3 is supported on the following operating systems:

·         Windows 2000

·         Windows Server 2003

·         Windows XP

·         Windows Vista

·         Windows Server 2008

Support will follow the policy for Windows service packs listed at http://support.microsoft.com/default.aspx?pr=lifesupsps#Windows.

4         Redistributing MSXML

Microsoft is not shipping a merge module redistribution package for MSXML4.0 SP3. Applications that need to use MSXML4 SP3 will need to install the MSXML4 SP3 MSI package first.

5         List of Known Changes in MSXML 4.0 SP3

Disclaimer This following section describes changes made in MSXML 4.0 SP3 that may break compatibility with earlier versions of MSXML 4.0. While the list has been reviewed for technical accuracy, it should not be interpreted as a complete or final list of any such changes. Potentially, additional changes might exist in some usage cases. If you find a breaking change in MSXML 4.0 that is not documented here, please contact Microsoft Customer Support Services (CSS) to report it and receive further technical support.

5.1       Max Element Depth

MSXML4.0 SP3 supports using MaxElementDepth to limit the element depth of an XML document to be loaded into a DOM object. A zero (0) value means no limits on the element depth of an XML document. A non-zero value specifies the maximum depth. The default value for MSXML4.0 SP3 is 5000.

This property helps to avoid denial of service attacks in which a document is submitted that has excessive element depth. Failure to limit the element depth leaves you vulnerable to the exploit where a relatively small XML document can cause denial of service. The MaxElementDepth property mitigates this threat.

If you are concerned about denial of service, you should set this property to a value that allows you to load your documents yet limits depth to a reasonable level.

Example

When you try to use the following JScript code to load data.xml, you will receive the following error message:

System error: MaxElementDepth.

You receive the error message because the max element depth of data.xml is 4.

JScript File (testdom.js)

var doc = new ActiveXObject("Msxml2.DOMDocument.4.0");

doc.async = false;

doc.setProperty("MaxElementDepth", 3);

doc.load("data.xml");

if (doc.parseError.errorCode != 0)

    WScript.Echo(doc.parseError.reason);

else

    WScript.Echo("Data loaded successfully");

XML File (data.xml)

<?xml version='1.0'?>

<book-review>

   <book>

      <title>A Good Book</title>

      <author>The Good Writer</author>

      <publisher>The Publisher</publisher>

      <date>A Good Day</date>

      <Review>

          <title>A Good Book</title> by <author>The Good Writer</author>,

          published by <publisher>The Publisher</publisher> on <date>A

          Good Day</date>, is indeed a good book.

      </Review>

   </book>

</book-review>

A SAX object can use max-element-depth property to limit the element depth.

When you try to use the following JScript code to load data.xml, you receive the following error message:

Operation aborted

JScript File (testdom.js)

var reader = new ActiveXObject("Msxml2.SAXXMLReader.4.0");

var writer = new ActiveXObject("Msxml2.MXXMLWriter.4.0");

try

{

    reader.contentHandler = writer;

    reader.errorHandler = writer;

    reader.putProperty("max-element-depth", 3);

    reader.parseURL("data.xml");

    WScript.Echo(writer.output);

}

catch(e)

{

    WScript.Echo(e.description);

}

5.2       AllowXsltScript Property for XSLT

AllowXsltScript property is used to enable or disable the <msxsl:script> element functionality in XLST. This property has security implications. The default value is set to true.

If this property is set to false, attempts to use a stylesheet with scripting will result in a "Security settings do not allow the execution of script code within this stylesheet" error.

Example

When you try to use the following JScript code, you will receive the following error message since AllowXsltScript property is disabled:

Security settings do not allow the execution of script code within this stylesheet.

XML File (test.xml)

<doc>content</doc>

XSLT File (test.xsl)

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ms="urn:schemas-microsoft-com:xslt" xmlns:user="user" xmlns="http://www.w3.org/1999/xhtml" exclude-result-prefixes="ms user">

<xsl:output encoding="utf-8" method="html" />

 

<ms:script implements-prefix="user" language="jscript">

function func()

{

    return "msxml";

}

</ms:script>

 

<xsl:template match="/">

    <xsl:value-of select="user:func()" />

    </xsl:template>

</xsl:stylesheet>

JScript File (test.js)

var dom = new ActiveXObject("MSXML2.DOMDocument.4.0");

dom.async = false;

dom.load ("test.xml");

 

var xsl = new ActiveXObject("MSXML2.DOMDocument.4.0");

xsl.async = false;

xsl.setProperty("AllowXsltScript", false);

xsl.load ("test.xsl");

 

try

{

    WScript.Echo(dom.transformNode(xsl));

}

catch(e)

{

    WScript.Echo(e.number + "*" + e.message);

}

5.3       AllowDocumentFunction and MaxXMLSize properties are propagated when cloning a node

AllowDocumentFunction and MaxXMLSize are security related properties. MSXML4.0 SP3 propagates the two properties when cloneNode() is called.

Example

When you try to use the following JScript code, you will receive the following information:

Source:

AllowDocumentFunction: false

MaxXMLSize: 1000

 

Destination:

AllowDocumentFunction: false

MaxXMLSize: 1000

JScript File (test.js)

var doc = new ActiveXObject("Msxml2.DOMDocument.4.0");

doc.async = false;

doc.setProperty("AllowDocumentFunction", false);

doc.setProperty("MaxXMLSize", 1000);

doc.loadXML("<root/>");

 

var node = doc.cloneNode(true);

 

WScript.echo("Source: " +

             "\nAllowDocumentFunction: " + doc.getProperty("AllowDocumentFunction") +

             "\nMaxXMLSize: " + doc.getProperty("MaxXMLSize"));

WScript.echo("\nDestination: " +

             "\nAllowDocumentFunction: " + node.getProperty("AllowDocumentFunction") +

             "\nMaxXMLSize: " + node.getProperty("MaxXMLSize"));

5.4       ProhibitDTD and MaxXmlSize properties are propagated to the included and imported Style Sheets

MSXML4.0 SP3 starts to propagate ProhibitDTD and MaxXmlSize settings from the main stylesheet to the included and imported style sheets. The same settings will be used on the XSL document and internal documents when resolving includes/imports and document() function during transformation.

Example

When you try to use the following JScript code, you will receive the following error message:

Invalid at the top level of the document.

This is because ProhibitDTD will be propagated to the internal document during the transformation.

XML File (test.xml)

<doc/>

XSLT File (test.xsl)

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:include href="include.xsl"/>

</xsl:stylesheet>

XSLT File (include.xsl)

<?xml version='1.0'?>

<!DOCTYPE xsl:stylesheet SYSTEM "include.dtd" [

  <!ATTLIST xsl:stylesheet

    xmlns:xsl CDATA #FIXED "http://www.w3.org/1999/XSL/Transform"

    version CDATA "1.0" >

]>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

</xsl:stylesheet>

JScript File (test.js)

var xsl = new ActiveXObject("MSXML2.DOMDocument.4.0");

var xml = new ActiveXObject("MSXML2.DOMDocument.4.0");

xml.validateOnParse = false;

xml.async = false;

xml.load("test.xml");

 

xsl.async = false;

xsl.setProperty ("ProhibitDTD", true);

xsl.load("test.xsl");

 

try

{

    WScript.Echo (xml.transformNode(xsl));

}

catch(err)

{

    WScript.Echo ("Transformation Error : " + err.number + "*" + err.description);

}

5.5       line/linepos Error Information for Duplicate Attribute May Change

The line/linepos error report for duplicate attribute may change while the error code remains the same.

Example

When you try to use the following JScript code to load data.xml with MSXML4.0 SP3, you will receive the following output:

line/pos: 2/36

With MSXML4 SP2 you will get:

line/pos: 2/23

JScript File (test.js)

var doc = new ActiveXObject("Msxml2.DOMDocument.4.0");

doc.async = false;

doc.load("data.xml");

if (doc.parseError.errorCode != 0)

{

    WScript.Echo("line/pos: " + doc.parseError.line + "/" + doc.parseError.linepos);

}

XML File (data.xml)

<?xml version='1.0'?>

<order number="12162" number="334">

5.6       line/linepos Information Changed for Well-known Entities

The reported line/linepos information for well-known entities like &amp; may change. Previously the Characters items produced as a result of such entity reference always had the same line/linepos, because they were treated as a separate source file. In MSXML4.0 SP3 these will be reported correctly.

5.7       Validate the nonNegativeInteger for schema

MSXML4.0 SP3 will check the validity of large value in attributes of type nonNegativeInteger. This will mitigate Denial of Service attacks when malicious XML source has attributes of type nonNegativeInteger containing large values.

You will receive

Errors Found:Error parsing '1123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123...' as decimal datatype.

when validating the following schema:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:element name="Root" type="xs:decimal" default="112345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678"/>

</xs:schema>

5.8       Path information is suppressed in XSD error messages

Prior to MSXML4 SP3, an XSD error message contained path information about the files processed. This might lead to a security problem. In MSXML4.0 SP3, path information is suppressed.

Example

Notice PurchaseOrderType  is not defined in po.xsd.

XML Schema File (po.xsd)

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

  xmlns="www.example.microsoft.com/po" elementFormDefault="qualified"

  finalDefault="restriction">

    <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

</xsd:schema>

If the schema is loaded with SchemaCache you will receive:

po.xsd#/schema[1]/element[position() = 1 and @name = 'purchaseOrder']

Undeclared XSD type : '{www.example.microsoft.com/po}PurchaseOrderType'.

The path information of po.xsd is suppressed.

JScript File (test.js)

var cache = new ActiveXObject("Msxml2.XMLSchemaCache.4.0");

cache.add("http://www.example.microsoft.com/po", "po.xsd");

5.9       Error message may point to any ID attribute if there are multiple IE attributes

When validating the following XSD schema:

<?xml version="1.0"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

       <xsd:simpleType name="myType">

              <xsd:restriction base="xsd:string"/>

       </xsd:simpleType>

       <xsd:complexType name="fooType">

              <xsd:simpleContent>

                     <xsd:extension base="myType">

                           <xsd:attribute name="attrTest1" type="xsd:ID" use="required"/>

                           <xsd:attribute name="attrTest2" type="xsd:ID" use="required"/>

                     </xsd:extension>

              </xsd:simpleContent>

       </xsd:complexType>

</xsd:schema>

In MSXML4.0 SP3 you will get:

test.xsd#/schema[1]/complexType[position() = 1 and @name = 'fooType']/simpleContent[1]/extension[1]/attribute[position()

 = 2 and @name = 'attrTest2']

Two distinct members of the {attribute uses} must not have {type definition}s which are or are derived from ID.

<attribute> : 'attrTest2'.

Instead of the following result in MSXML4 SP2:

test.xsd#/schema[1]/complexType[position() = 1 and @name = 'fooType']/simpleContent[1]/extension[1]/attribute[position()

 = 1 and @name = 'attrTest1']

Two distinct members of the {attribute uses} must not have {type definition}s which are or are derived from ID.

<attribute> : 'attrTest1'.

In MSXML4.0 SP3, the iteration is based on a sequential order.

5.10  The order of SAX output changed when traversing a DTD

The DTD elements parse sequence may be affected by internal changes.

Example

When you run test.js with MSXML4.0 SP3, you will get:

<!DOCTYPE ROOT [

<!ELEMENT Z ANY>

<!ELEMENT A ANY>

<!ELEMENT B ANY>

<!ELEMENT C ANY>

<!ELEMENT D ANY>

<!ELEMENT bar4 ((A|(B,C)|D))>

<!ELEMENT BODY ANY>

<!ELEMENT bar6 (#PCDATA|B|C)*>

<!ELEMENT bar7 ((B|C))>

<!ELEMENT bar8 (BODY,((A|B))?)>

<!ELEMENT bar (((A|B))*)>

<!ELEMENT bar2 ((A|B))>

<!ELEMENT bar5 ANY>

<!ELEMENT bar3 ((Z|A|(B,C)))>

<!ELEMENT ROOT ANY>

]>

<ROOT/>

While running the script with MSXML4 SP2, you will get:

<!DOCTYPE ROOT [

<!ELEMENT bar6 (#PCDATA|B|C)*>

<!ELEMENT bar7 ((B|C))>

<!ELEMENT bar8 (BODY,((A|B))?)>

<!ELEMENT D ANY>

<!ELEMENT BODY ANY>

<!ELEMENT Z ANY>

<!ELEMENT bar (((A|B))*)>

<!ELEMENT C ANY>

<!ELEMENT ROOT ANY>

<!ELEMENT bar3 ((Z|A|(B,C)))>

<!ELEMENT bar4 ((A|(B,C)|D))>

<!ELEMENT bar5 ANY>

<!ELEMENT B ANY>

<!ELEMENT A ANY>

<!ELEMENT bar2 ((A|B))>

]>

<ROOT/>

The order of traversing DTD elements is changed.

XML File (test.xml)

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ROOT [

<!ELEMENT ROOT ANY>

<!ELEMENT bar (A|B)*>

<!ELEMENT bar2 (A|B)>

<!ELEMENT bar3 (Z|A|(B,C))>

<!ELEMENT bar4 (A|(B,C)|D)>

<!ELEMENT bar5 ANY>

<!ELEMENT bar6 (#PCDATA|B|C)*>

<!ELEMENT bar7 (B|C)>

<!ELEMENT bar8 (BODY,(A|B)?)>

<!ELEMENT A ANY>

<!ELEMENT B ANY>

<!ELEMENT C ANY>

<!ELEMENT D ANY>

<!ELEMENT Z ANY>

<!ELEMENT BODY ANY>

]>

<ROOT>

</ROOT>

JScript File (test.js)

var xmlDoc = new ActiveXObject("Msxml2.DOMDocument.4.0");

var rdr = new ActiveXObject("Msxml2.SAXXMLReader.4.0");

var wrt = new ActiveXObject("Msxml2.MXXMLWriter.4.0");

 

xmlDoc.async = false;

xmlDoc.validateOnParse = false;

xmlDoc.load("test.xml");

 

wrt.byteOrderMark = true;

wrt.omitXMLDeclaration = true;

wrt.indent = true;

 

rdr.contentHandler = wrt;

rdr.dtdHandler = wrt;

rdr.errorHandler = wrt;

rdr.putProperty("http://xml.org/sax/properties/lexical-handler", wrt);

rdr.putProperty("http://xml.org/sax/properties/declaration-handler", wrt);

 

rdr.parse(xmlDoc);

WScript.Echo("Out:\n" + wrt.output + "\n")

5.11  Access Denied error when a schema location redirects from internet zone to access a local file

This issue only happens on Windows 2003 due to defect in external components.

When a local HTML file containing a script is opened, Internet Explorer tries to parse a local XML file containing a schemaLocation attribute. If the location points to an ASP page on the internet that redirects back to a local XSD file, the access will be denied.

Example

Access will be denied if rd-localInvalidXSD.asp redirects to a local XSD file.

<b:b b:b-att1="b1" b:b-att2="a"

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

       xmlns:b="b"

       xsi:schemaLocation="b http://xmlworld/security/schemaSecurity/rd-localInvalidXSD.asp"

></b:b>

5.12  prohibit-dtd on the SAX reader is used to parse schema locations and inline schemas

Prior to MSXML4.0 SP3, prohibit-dtd was not propagated while parsing schema locations and inline schemas in the SAX Reader. All schemas are parsed even though prohibit-dtd is set to true. In MSXML4.0 SP3, prohibit-dtd will be propagated when parsing schema locations and inline schemas in the SAX Reader. An unspecified error will be returned if any schema contains DTD when prohibit-dtd is on.

Example

You will receive the following error message since prohibit-dtd is on and it is propagated to ta.xsd.

ERROR: Unspecified error

JScript File (test.js)

var reader = new ActiveXObject("MSXML2.SAXXMLReader.4.0");

var writer = new ActiveXObject("MSXML2.MXXMLWriter.4.0");

 

reader.contentHandler = writer;

reader.putFeature("schema-validation", true);

reader.putFeature("use-schema-location", true);

reader.putFeature("prohibit-dtd", true);

 

try{

    reader.parseURL("test.xml");

    WScript.Echo(writer.output);

}

catch(e)

{

    WScript.Echo("ERROR:" + e.description);

}

XML File (test.xml)

<doc xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation="t.xsd">

</doc>

Schema File (t.xsd)

<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'>

<xsd:import namespace="a" schemaLocation="ta.xsd"/>

<xsd:element name="doc"/>

</xsd:schema>

Schema File (ta.xsd)

<!DOCTYPE blah[ ] >

<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema' targetNamespace="a" xmlns="a">

</xsd:schema>