Today Microsoft released a security update, MS08-075, that fixes a vulnerability in Windows Explorer in Vista and Server 2008 that was exposed through the search-ms protocol handler. This is a remote unauthenticated vulnerability that requires user interaction, so we wanted to give you a bit more information about protocol handlers and how you can reduce your attack surface by turning off any protocol handlers you don’t intend to use.
Quick introduction to protocol handlers
A protocol handler is a way to extend the functionality of your web browser. The well known mailto:// protocol is a great example. Instead of the familiar http:// or https:// protocols, mailto:// links start your e-mail application and tell it to create a new e-mail message to a particular e-mail address, and optionally with a particular subject.
You can see how the mailto:// protocol handler is associated to your e-mail application on your computer by examining the registry key HKEY_CLASSES_ROOT\mailto\shell\open\command. In the default value of that registry key you will see the command line that is executed when you click on a mailto:// link, or when a web page references mailto:// in a URL that is automatically retrieved, like in the src value of an <iframe>. The %1 value in the registry key is replaced with the rest of the URL that follows the ://.
If the application that is associated with a protocol contains a vulnerability that can be triggered by the data passed to it on the command line, this can be a serious attack vector. A malicious web page could pass specially crafted data to that application as soon as you visit the web page, by putting a URL containing the vulnerable protocol in something like the src value of an <iframe>.
If you use Vista or Server 2008, and you have User Account Control and Protected Mode Internet Explorer turned on (the default) , then Internet Explorer 7 provides protection against this attack by warning the user before processing a protocol handler by displaying a dialog like this one:
There are two different ways to add a protocol handler to Internet Explorer. One is by associating a protocol (e.g. search-ms://) with an application, where the remaining portion of the URL is passed as a command line argument. That is the method we discuss in this post. There is another method for registering a CLSID with a protocol which involves writing code that implements specific interfaces. We are not covering these handlers in this blog post, but you can read more about them here: http://msdn.microsoft.com/en-us/library/aa767916(VS.85).aspx
A quick note about PowerShell
Since protocol handlers are configured in the registry, PowerShell is a great choice for working with them. In this post we provide several PowerShell scripts to help you work with protocol handlers. It’s important to note that by default, PowerShell won’t let you run scripts. For more information on this policy and for information how to change it refer to: http://technet.microsoft.com/en-us/library/cc764242.aspx.
Warning: If you do modify your execution policy, it may be easier to unintentionally execute a malicious PowerShell script. If you alter your execution policy to run these scripts, the safest option is to restore the execution policy to the default “Restricted” value once they have completed.
How to enumerate all of the protocol handlers on your system
To do this, look for all of the subkeys of HKEY_CLASSES_ROOT that have an empty string value named “URL Protocol” and a subkey structure of “shell\open\command”. Here is our script to do just that, and return the results to you in a hash table (name, value pairs):
$Results = @{}
foreach ($Key in Get-ChildItem Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT)
{
$Path = $Key.PSPath + ‘\shell\open\command’
$HasURLProtocol = $Key.Property -contains ‘URL Protocol’
if (($HasURLProtocol) -and (Test-Path $Path))
{
$CommandKey = Get-Item $Path
$Results.Add($Key.Name.SubString($Key.Name.IndexOf(’\’) + 1), $CommandKey.GetValue(’’))
}
}
$Results
How to enable or disable a protocol handler
To disable a protocol handler, our PowerShell script (attached at the end of this post) removes the “URL Protocol” string from the registry key and puts a “Disabled URL Protocol” string in its place, so we know that we purposefully disabled it. We have also included a script to reverse the process, re-enabling the protocol handler again.
Related Posts
- Additional Details and Background on Security Advisory 943521**
- MS08-015: Protocol Handler and its Default Security Zone**
- Enriching the Web Safely: How to Create Application Protocol Handlers**
Conclusion
If you want to reduce your attack surface (your exposure to possible future vulnerabilities), you can use this information and these scripts to disable protocol handlers that you don’t need to use. We hope that you found this post helpful in defending your systems!
Kevin Brown, SVRD Blogger
*Postings are provided “AS IS” with no warranties, and confers no rights.*