Security Thoughts: Are you still running XML Core Services (MSXML) 4.0 with Service Pack 2 in your environment?

Security and practicality often clash, especially with legacy software in the mix. Legacy software is painful from a security point of view.

If you want to know how painful, keep on reading this blogpost. It features legacy functionality, unsupported software and security holes the size of Jupiter.

 

The situation

Consider a critical business application, that works with XML. Great! Now, also consider your business has bought this particular application a few years back. The company making the software has since gone bust or your organization didn’t have support, but the bottom line is you’re faced with three choices:

  • Make the application run.
  • Upgrade the application to a newer (supported) version.
  • Migrate to another (supported) application.

This is a critical business application, so the option to stop using it cannot be considered. In these financially unstable times, for many organizations options 2 and 3 are not feasible either, so you’re faced with making the application run.

Now, the thing I didn’t mention up to this point is that this application requires XML Core Services 4.0 with Service Pack 2. (Installation breaks when you try with XML Core Services 4.0 with SP3 or XML Core Services 6.0)

 

The problem

Because XML Services 4.0 with Service Pack 3 (MSXML4 SP3) replaces XML Services 4.0 with Service Pack 2 (MSXML4 SP2) during installation with a completely new installation, Microsoft has not made XML Services 4.0 with Service Pack 3 (MSXML4 SP3) available as a critical or important update and hasn’t forcibly started upgrading to either Windows Update or Windows Server Update Services (WSUS). MSXML4 SP2 is not automatically ‘upgraded’ to SP3 because this would cause unexpected results on the updated machine.

The problem with making XML Core Services 4.0 with Service Pack 2 (MSXML4 SP2) is that is unsupported for over three years now. You were urged to migrate to XML Services 6.0 or upgrade to XML Services 4.0 SP3 back then, but today, Microsoft doesn’t give you any clue that you’re running unsupported software, since XML Services 4.0 with Service Pack 2 (MSXML4 SP2) is no longer supported. In April 2013, Microsoft has deemed 3 years would be enough time to migrate off XML Services 4.0 with Service Pack 2 (MSXML4 SP2, so Windows Update and Windows Server Update Services no longer offer XML Services 4.0 with Service Pack 3 (MSXML4 SP3) to Windows installations with XML Services 4.0 with Service Pack 2 (MSXML4 SP2).

However, Microsoft has still been releasing security updates for replaces XML Services 4.0 with Service Pack 3 (MSXML4 SP3) in the past three years. The latest in these releases is tied to Microsoft KnowledgeBase article 2758694. The update is labeled as Critical. Since support ended for XML Services 4.0 with Service Pack 2, Microsoft has issued two superseding Security Bulletins for XML Core Services 4.0 (Microsoft Security Bulletin MS12-043 – Critical and Microsoft Security Bulletin MS13-002 – Critical)

Environments running XML Services 4.0 with Service Pack 2 (MSXML4 SP2) don’t receive these updates, as the KnowledgeBase article clearly states it only applies to XML Services 4.0 with Service Pack 3 (MSXML4 SP3).

Today, not only do you not receive the ability to upgrade your XML Services 4.0 with Service Pack 2 (MSXML4 SP2) to XML Services 4.0 with Service Pack 3 (MSXML4 SP3), but you also lack several Critical updates in your environment, that can lead to remote code execution.

So, how bad is it, really?

The situation has gone as bad as Secunia reporting XML Core Services (MSXML) as being the less patched Windows component in the first quarter of 2013. According to reports of the Secunia PSI tool, in the US, 57% of all MSXML installations (a 79% market share) in Q1 2013 were unpatched. MSXML beats the Java Runtime Environment and several Adobe products with these impressive, yet unsettling, scores.

 

The resolution

I strongly urge you to look up the version of the XML Core Services installed in your environment. You can quickly do that by looking at the availability and properties of msxml4.dll in the C:\Windows\System32 and the C:\Windows\SysWOW64 folder (only on x64 systems).

If the file exists, you have XML Core Services 4.0 (MSXML4) installed.

MSXML4SP2

If the properties of the file read MSXML 4.0 SP 2, like in the screenshot above on Windows XP with Service Pack 3, address the situation.

 

Concluding

When your Windows installations and Windows Server installations still run XML Core Services 4.0 with Service Pack 2 (MSXML4 SP2), you don’t get notified of the newer (still supported version (MSXML4 SP3) is available. As long as you don’t upgrade these systems, your environment is vulnerable to remote code execution.

Further reading

Microsoft Security Bulletin MS12-043 – Critical
Microsoft Security Bulletin MS13-002 – Critical
MSDN Blogs – MSXML4.0 SP2 is going out-of-support in April. 2010
Microsoft XML Core Services (MSXML) on Wikipedia
Download MSXML 4.0 Service Pack 3 (Microsoft XML Core Services)

Acknowledgements

This topic was brought to my attention by www.security.nl

2 Responses to Security Thoughts: Are you still running XML Core Services (MSXML) 4.0 with Service Pack 2 in your environment?

  1.  

    I have a whole raft of these msxml’s in my installed progs. Am wanting to cleanse my cluttered lap-top so what would be the downside of uninstalling these? To a Lay user what exactly do these things do?
    Peter Naylor

    • XML Core Services (MSXML) are add-ons to the Operating System. Each of the MSXML installations adds support for specific versions of XML, DOM, SAX, XSLT, XSD and XDR, as well as other XML-related technologies for applications and services. More information can be found on Wikipedia.

      Removing a specific version of the XML Core Services (MSXML) might break an application, when a developer has specified a dependency on a specific version, or when the developer uses a specific function, format or feature that is only available or only implemented in that specific way in a specific version.

       

leave your comment