What you need to know about the Windows HCP flaw

Anyone running Windows XP or Windows Server 2003 needs to update their registry ASAP.  

A critical bug in the Help and Support center was made public recently and Microsoft has neither a fix nor an estimate as to when a fix might be available. Worse still, sample code to exploit the bug is readily available, along with a detailed explanation of the flaw,  making it especially easy for bad guys to exploit the vulnerability.

The problem has to do with the way HCP:// links are processed. Normal website links, of course, use HTTP, HCP links are used by the Help and Support Center (helpctr.exe).

You might therefore think that someone would have to click on a link, be it in a web page or an email message, to get infected. But no, simply viewing a web page is all it takes. Microsoft's Security Advisory (2219475) warns "This vulnerability could allow remote code execution if a user views a specially crafted Web page using a Web browser ... "

If the bug is exploited, a bad guy can run software or commands on your computer, as if they were you. The last phrase is important but hasn't been stressed in the articles I've seen on the subject.

Anyone logged on to Windows as an administrator is as vulnerable as a naked newborn baby. Running as a restricted user ("limited" being the term used by Windows XP) does not protect you from the HCP flaw, but it does limit what the malicious software or commands can do on your computer.

Simply put, bad guys can't exploit this bug to install software when you're logged on as a restricted user. They can run malicious software, but the software can't be permanently installed and there are severe limits on what the software can do. That, of course, is the whole idea behind restricted users.

But hardly anyone runs as a limited user.

<soapbox>

Huge mistake.

</soapbox>

THE CURRENT FIX

Needless to say, it's best to prevent anything malicious from running at all, and that's where the registry update comes in. Until Microsoft fixes the underlying problem, the workaround they suggest involves telling Windows not to process any HCP links at all.

At first, the registry update to ignore HCP links had to be done manually, but Microsoft has since offered a somewhat automated Fix it tool (more below).

Regardless of how the registry is updated, it should be backed up first. Under Windows XP, click Start -> Programs -> Accessories -> System Tools -> System Restore. Click on the option to "Create a restore point" and name it something like "before disabling the HCP protocol".*

I have seen two different suggested approaches for the manual registry updating - one involves deleting data from the registry, the other involves the less-destructive renaming.

My preference is for the renaming. Steve Gibson did an excellent job documenting this approach in his blog HCP 0-Day Quick Fix.

In a nutshell, run regedit, do a Find for "HCP" as a key (not also as a value or data) and match only the whole string. When you find it, rename it and you're done. The Find command is not case sensitive. You need to be logged on as an administrator to modify the registry.

If directly dealing with the registry is daunting, then you can use Microsoft's somewhat automated Fix it solution.  

This involves downloading a file, MicrosoftFixit50459.msi to your computer and running it. One advantage to this approach is that you can download the file once and use it to fix multiple computers.

Not that it matters much, but the Microsoft Fix it program does not rename the HCP registry key, nor does it delete it. Instead it deletes the sub-keys under HCP in the registry. 

You'll notice that the Microsoft Fix it page has links to both enable and disable the workaround. Don't be confused - "enable" (a.k.a. Microsoft Fix it 50459) refers to disabling the HCP protocol. The "disable" option (a.k.a. Microsoft Fix it 50460) will be needed in the future after Microsoft fixes the underlying problem.

Then again, many XP users don't use the Help and Support center at all. If that's you, you can leave the HCP protocol disabled forever. It has been abused in the past.

TESTING

The person who found this bug provided a couple sample exploits. You can verify that disabling the HCP protocol prevents the problem by running these tests before and after. 

Windows XP users running Internet Explorer version 7 can click on the link below to test the vulnerability.

http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/starthelp.html

If the Windows calculator starts, the computer is vulnerable.

Windows XP users running Internet Explorer 8 and Windows Media Player 9 can click on the link below to test the vulnerability.

http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/launchurl.html

Again, if the Windows calculator starts, the computer is vulnerable. If a later version of Media Player is installed, this is not a valid test.

According to the developer

Some minor modifications will be required to target other configurations, this is simply an attempt to demonstrate the problem ... Additionally, my demonstration is not intended to be stealthy, a real attack would barely be noticeable to the victim ... Browsers are useful to demonstrate the problem, but there are certainly other attack vectors, such as MUAs, documents, etc. Protocol handlers are designed to be used across applications.

One point here, bears repeating. The flaw is not tied to a particular web browser or to any browser at all. It is an operating system issue. 

Also note that while antivirus/anti-malware software on your computer may detect these particular examples as malicious, that does not necessarily mean that it offers full protection.

To insure that the registry update to disable the HCP protocol is really doing its job, you may want to disable your antivirus software, run the test to see the Calculator being invoked, run the fix, then run the test again to insure the Calculator does not run. 

DISABLING THE UNDERLYING SERVICE

Finally, there is yet another way to work around this problem, prior to Microsoft's offering a fix - disable the underlying Help and Support service.

I ran across this on a computer of mine while running one of the above tests, before disabling HCP. On that machine, I had already disabled the service since I rarely use the Help and Support Center. IE7 warned that the service needed to be started and the Calculator never ran.

This solution is not suggested by Microsoft, so it's not appropriate as your only defense. But, it makes a good second defensive tactic.

Interestingly, while having the service disabled did prevent the test exploit, merely stopping the service did not. That is, with the service configured for a manual startup, the exploit test was able to start the service and run the Calculator. But even disabling the Help and Support service may not be a rock solid defense, I have seen software start a service that was disabled.

To be clear, if the HCP protocol is disabled, the computer is protected even if the Help and Support service is running.

As with updating the registry, modifying the state of a service requires administrator level authority.

Again, anyone running Windows 7,  Vista, 2000 or Server 2008 is fine. The problem with the HCP protocol only affects Windows XP and Server 2003.

*The semi-automated Fix it solution from Microsoft does make a restore point called "Installed Microsoft Fix it 50459." However, the Fix it program will update the registry even if there is a problem with System Restore, thus I feel it's best to manually make a Restore Point so you can verify that all went well prior to updating the registry.

Update June 18, 2010: Added extra clarification that the flaw is not tied to a web browser, but instead, is an operating system issue. 

Update July 14, 2010: The Microsoft KB article 2219475, linked to above, no longer contains links to their Fix it utility to disable and re-enable the HPC protocol. You can now find the Fixit utility in KB article 2229593. After installing the latest round of Windows bug fixes, you may want to re-enable the HCP protocol. Or not. 

Join the discussion
Be the first to comment on this article. Our Commenting Policies