Secunia recently reported that Microsoft XML Core Services vulnerabilities are still one of the biggest risks to...
PC users, with more than 43% of users running vulnerable versions of the software. Can you please explain why these issues still exist and ways to best mitigate them?
Secunia's second quarter report on vulnerable software for 2014 lists Microsoft XML Core Services 4.0 (MSXML) as the biggest risk to PC users in the U.S. There are multiple versions of MSXML -- this is one of the reasons why version 4.0 remains such a risk. MSXML 3.0 and MSXML 6.0 are essentially part of Windows and Internet Explorer, while MSXML 5.0 is installed with Office 2003 and 2007. However, MSXML 4.0 is for developers who are building XML-centered applications. These applications silently install MSXML 4.0 as a dependency, but after April 2014 it was no longer supported by Microsoft and does not receive any further security updates.
In the U.S., 79% of PC users have MSXML 4.0 installed. Of those, 43% are still running the vulnerable MSXML 4.0 Service Pack 2. Why? Well, unlike other MSXML versions that were shipped with Microsoft products, MSXML 4.0 was shipped out of band and is defined as a "tool" -- a utility or feature that aids in accomplishing a discrete task or a limited set of tasks -- so has a different support lifecycle than regular Microsoft products. Microsoft deemed MSXML 4.0 SP3 to be a completely different product than SP2, and it was never released to automated channels -- meaning that Windows Update, WSUS and SCCM never auto-updated users or organizations from SP2 to SP3.
Although no new vulnerabilities have been publicly disclosed in recent times, there are unpatched ones in SP2. MSXML 4.0 SP2 went out of support in 2010, so the critical security update MS12-043 released in July 2012 for SP3 to fix a publicly reported remote code execution vulnerability was not released as an update for MSXML 4.0 SP2, leaving users unpatched and vulnerable.
The best way to mitigate the risk of MSXML 4.0 is to check whether any installed applications still need it; if not, then uninstall it. If any older applications do require this particular version, contact the vendor to see if there is an upgrade path, as running unsupported software or dependencies is never a good practice.
At a minimum, ensure that you upgrade from MSXML 4.0 SP2 to SP3; note that this requires a manual update. Then be sure to check that patches MS13-002 and MS12-043 are installed after the next auto-update. Enterprises with legacy software that require MSXML 4.0 should use Microsoft's Enhanced Mitigation Experience Toolkit 5.0 to mitigate possible attacks attempting to exploit the unpatched vulnerabilities in SP2 by blocking MSXML 4.0 from running in Internet Explorer and in websites not belonging to the Trusted Sites or Intranet zones.
Ask the Expert!
Have a question about application security? Send it via email today! (All questions are anonymous.)
Dig Deeper on Web application and API security best practices
Related Q&A from Michael Cobb
A recently discovered Drupal vulnerability in its open source CMS allowed attackers to control websites. Learn how almost one million sites were ... Continue Reading
Google instituted an aggressive ban on all cryptomining extensions for Chrome after cryptojacking attacks started to become more common. Learn how ... Continue Reading
With enterprises testing DNS over HTTPS to encrypt domain name traffic, some fear the potential privacy issues. Discover the challenges and benefits ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.