Boy, that's a long subject line - but it's the title of Microsoft's KB
Microsoft details (a bit) its changes to URL, more correctly URI,
handling in IE 7 on WinXP and Windows 2003.
The problem is that IE 7 code "tries to fix up" malformed URIs, then
passes the fixed-up URI to the ShellExecute procedure (on XP and Win2003).
With IE6 installed, ShellExecute() passes the URI to IE which accepts it
and inside IE determines it to be invalid. Navigation then fails
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.
This phraseology struck me as odd: "IE7 began to do more validation up
front to reject malformed URI's."
"Began to"? It sounds like the design of IE 7 was not completed before
it was shipped.
What exactly does "IE7 began to" mean?
This is the root cause behind the Adobe Acrobat family of mishandling of
URIs in PDFs.
Adobe had not expected the introduction of IE 7 onto existing XP
computers to change the handling of URIs. [ "Nobody expects the Spanish
Inquisition!" :-) ]
"a zero-day vulnerability in Adobe Inc.'s pervasive PDF files could be
exploited to snatch control of Windows XP systems."
Thus the problem exists for any application not written by Microsoft
that handles URIs where IE 7 is installed on XP or Win2003.
Isn't that special?