Today we released MS10-042 to address CVE-2010-1885, a Critical severity security issue in the Help and Support Center. Windows XP is affected and we have seen limited attacks, so we encourage everyone to depoy the update right away. Windows Server 2003 also contains the vulnerable code; however, we have not identified a way for an attacker to exploit it. Uplevel versions of Windows do not contain Help and Support Center and as such are not vulnerable.
Background on Help and Support Center Vulnerabilities
Help and Support Center vulnerabilities, CVE-2010-1885 included, generally involve local content enabling injection of script into the Help and Support Center environment. In the case of CVE-2010-1885, the local content targeted was a file, “sysinfomain.htm.” This content references a helper library, “commonFunc.js,” which contains DOM-based XSS. Specifically, commonFunc.js enables an untrusted querystring parameter to be injected onto the page. This in turn enables the execution of attacker-controlled commands.
By design, Help and Support Center allows trusted Help content on Windows XP and Windows Server 2003 to execute privileged commands enabling Help related functionality. Given the presence of an injection issue, the powerful Help and Support Center environment can enable execution of arbitrary code.
A Note about Potential Mitigations
The attack scenario for this vulnerability involves navigation to an hcp:// protocol URL. Browsers including Internet Explorer 8 have recently begun to implement warning prompts before navigation to less-common URL schemes.
One example proof-of-concept exploit for CVE-2010-1885 demonstrated the use of Windows Media Player 9 to navigate to the hcp:// protocol and avoid the IE8 prompt. More recent versions of Windows Media Player prompt before loading arbitrary HTML content and thus do not enable this attack scenario.
Nevertheless, we view the newly introduced protocol prompting behavior in browsers to be at best defense-in-depth. We do not believe that these prompts provide sufficient mitigation for the identified Help and Support Center vulnerability in all cases. Thus they are not called out as mitigations in MS10-042.
Ruling out URL Decoding as the Primary Issue
Our analysis of the vulnerability is that it is due to a bug in the URL validation performed by Help Center, not due to a bug in URL decoding functionality within Help and Support Center.
As identified in the original vulnerability report, a malformed URL can result in failure of the Help and Support Center URL decoding routine. That in itself is expected, however Help and Support Center subsequently ignores the associated failure condition and thus the resulting decoded URL is left in an arguably invalid state. The report also made the assertion that the URL decoding could be held responsible for the security of the URL validation in Help and Support Center as a whole. However, it is possible to construct a _validly-encoded _URL that would decode to the same in-memory representation as the invalidly-decoded proof-of-concept URL. So, fixing the handling of URL decoding failure would not address the underlying vulnerability.
Digging Deeper
In the scenario identified as part of the vulnerability report, Help and Support Center validates URLs using a Jet database containing an index of locally installed Help content. This database is located in %windir%\PCHealth\Database\HCdata.EDB. A query is issued against the database looking for a particular piece of help content. If this content is indexed in the database, the local file is then authorized to load within Help and Support Center. In the case of the reported vulnerability, it was possible for an attacker to bypass validation and trigger navigation to sysinfomain.htm with a maliciously constructed URL.
CVE-2010-1885 leverages the fact that the query against the Jet database is not a true string comparison. In reality, it’s a comparison of keys generated by the LCMapString API. So the attacker-supplied input maps down to a string that improperly matches content contained within the Jet database. When the query is issued against the database, the database code identifies the malformed file name to exist (several times!) even though it is not present.
Minimal Risk on Windows Server 2003
As it turns out, the HCdata.EDB database file is significantly different between Windows XP and Windows Server 2003. On Windows Server 2003 the database file does not contain the base URLs necessary to match database queries for HCP:// protocol content. Because the vulnerable Help and Support Center code exists on Windows Server 2003, we were able swap in the EDB file from Windows XP and observe the exploit function. However, we were unable to construct an attack that would work with the standard Windows Server 2003 EDB file. Nevertheless, we are addressing the issue as a low severity vulnerability on Windows Server 2003.
- MSRC Engineering Team Bloggers