Who is Responsible for URL Security?

Note: This post is more technical in nature than most.

There’s has been a big debate this summer over who should fix a possible security flaw outlined in Security Advisory 943521. Most examples use of malformed “mailto” tags to show how Windows passes along info to the function ShellExecute based on registered url handlers.

In the past, Microsoft has voiced its opinion that it should be the applications responsibility to verify any URL before it’s passed to Windows. Many have encouraged Microsoft to somehow create a global fix with a security patch in Windows.

This was a case where I was on Microsoft’s side of the argument. Of course my reason was selfish because I fear any changes could break the functionality of WinPatrol PLUS requests. This week Microsoft announced it would look at a fix on their end.

“Our plan is to revise our URI handling code within ShellExecute() to be more strict”. For the tech savvy, here’s what happens.

“With IE6 installed, ShellExecute() passes the URI to IE which accepts it and inside IE determines it to be invalid. Navigation then fails harmlessly. With Internet Explorer 7 installed, the flow is a bit different. IE7 began to do more validation up front to reject malformed URI's. When this malformed URI with a % was rejected by IE7, ShellExecute() tries to “fix up” the URI to be usable. During this process, the URI is not safely handled. IE7 rejects the URI, and on Windows Vista ShellExecute() gracefully rejects the URI. That’s not the case on the older versions of Windows like Windows XP and Windows Server 2003 when IE7 is installed.

The % is a very special character. It can be used to hide and embed potentially dangerous code. It can also be used to represent characters which in my case, I want to pass in the parameters of an url. For instance, %20 represents a space character which is safer for me to send and easy to parse on our server. It’s also used so I can pass & and ? characters within the parameters of my URL request.

Microsoft has not announced a time frame for any fix so I’ll be keeping an eye on this one and my fingers crossed. I’m guessing I won’t be the only one affected by a major change in how ShellExecute handles an Url. If you read my previous post “Windows Versions Are Like SnowFlakes” you’ll see why these changes scare me.

Registry Tweaks Cause Unexpected Results

I recently wrote about the problems that can result from so many different files that make up Windows. This week I found out the hard way how simple registry tweaks generate unintended surprises.

A few years ago, a tweak started making the round that allow users to add “Move To” and “Copy To” to the Windows Explorer in XP. Just last September TechRepublic was promoting this registry hack which used some additions to the registry key…HKCR\AllFilesystemObjects\shellex\ContextMenuHandlers

Well, it turns out this tweak can cause some unexpected surprises. I can tell you I was surprised when my new friend Mark told me about the unexpected behavior he experienced. When he clicked on PLUS Info… he was greeted with a “Move Items” Dialog screen.

After doing some research I found many other unexpected surprises caused by this registry hack. This is just one of the registry changes which has caused problems since I’ve fixed a previous Windows quirk that impacted WinPatrol users.

Most of the registry flaws appear to be caused by 3^rd party browsers or other internet programs which made changes when they installed, but didn’t restore the original values when they were Uninstalled

When it comes to our newest WinPatrol (12.1.2007.0) I’ve narrowed most problems to the registry key HKCR\InternetShortcut\shell\open\command. If you experience problems getting PLUS Info visit http://www.winpatrol.com/faq.html for help. If this causes a problem in WinPatrol it will most likely cause problems to other programs.

If you’re one of those people who like the “Move To” / “Copy To” registry hack I can point you to the correct solution. MVP Ramesh Srinivasan provides an explanation and new method at http://windowsxp.mvps.org/movetocontext.htm