Unofficial Patch For Windows URI Hole

dg2fer writes "For more than two months, the vulnerability of parsing URIs has been known for a number of Windows programs, including Outlook, Adobe Reader, IRC clients, and many more. Microsoft admitted the vulnerability only last week. The latest Microsoft patches published on October's Patch Tuesday did not include a solution, so hackers have taken on the problem themselves. One, KJK::Hyperion, has published (as open source) an unofficial patch that cleans up the critical parameters of URI system calls before calling the vulnerable Windows system function."

Comments

Re:Well...

[gQuigs]

Yup. http://www.reactos.org/en/index.html

Re:Well...

[Xtravar]

I would mod this up, but I think I should explain why it's not off-topic instead.
The guy who wrote this patch actually works on ReactOS. http://www.reactos.org/wiki/index.php/KJK::Hyperion

I knew I remembered the name from somewhere.

Hole in the Patch for the Windows URI Hole

[dg2fer]

The author of the Patch for the Windows URI Hole, KJK::Hyperion, found a big bug in his patch for the Windows URI hole. "I just found a gruesome memory leak in it. A silly bug, brown paperbag-grade shame."

According to the article on heise security he did already publish a bugfix version of his patch -- hoping the best it's not buggy again.

Re:I don't understand the logic

[KJKHyperion]

It's a memory-only patch, and it hooks the vulnerable function using a standard, documented method (that was made obsolescent in Vista, but Vista isn't vulnerable in the first place). Apart from the horrible bugs that are entirely my own damn fault, nobody will care or know that my patch is installed on a system (unless they go look for it). It doesn't even address the vulnerability directly, it just prevents the vulnerable function from ever seeing an abnormal URL. Basically, I did it because I could, and because I wanted to: I knew how to hook in ShellExecuteEx, but I needed some hands-on experience with it

Aside: I'm not even 100% sure of where the vulnerability is, yet, but I think the single bad choice that breaks the camel's back is an error handling function believing an error of "invalid argument" (returned by Internet Explorer 7 for malformed URLs) is not a critical error, allowing the URL to be misidentified as a non-normalized file path. The bug has been sleeping there since, I think, Internet Explorer 6, but it wasn't until Internet Explorer 7 that URL handling for execution purposes was moved from shdocvw.dll (and, I presume, the ParseURL routine, which is very liberal and only really serves to carve the scheme out of an URL) to ieframe.dll (and either the InternetCrackUrl or CoInternetParseUrl routine, which are a lot more finicky about URL syntax)

Lastly: for developers, I have made a little snippet of code that demonstrates how to safely and unambiguously execute an URL with ShellExecute(Ex) without risking its interpretation as something else (yes, it would have prevented this mess), and documents a few other subtleties. For now it's just another post on Full Disclosure, I will give it a better home one day. I wish Mozilla used something like this instead of the messy code they have now