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.)
Don't miss SearchSOA's tutorial on XML security and learn best practices on how to implement XML security.
Dig Deeper on Web application and API security best practices
Related Q&A from Michael Cobb
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading