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

What is Microsoft's reason for silence?

[jkrise]

They have admitted belatedly that IE7 on XP is broken; and that it is a very serious threat to security. So what prevents them from releasing a patch right away?

Is this vulnerability used / proposed to be used to make non-genuine Windows XP machines running IE7 unusable? Remember the unapproved, illegal stealth update that broke patching after a 'system restore'? Microsoft's continued silence is very intriguing.

Re:What is Microsoft's reason for silence?

[jkrise]

Millions of dollars in research takes time.

But the problem is peculiar to IE7 and XP, NOT IE7 under Vista. This means that the billion dollar research has actually been completed, and that Vista includes the protection mechanism. Since IE7 was released after XP, it clearly indicates that this flaw has been on purpose; with some possible ulterior motive.

Already, trust has been lost with the stealth update of XP; now with IE7 being forced as a Critical Patch despite the broken security model; the mistrust is complete.

What Microsoft considers to be a critical patch is actually a cripppling security hazard! How ironic!!

Re:What is Microsoft's reason for silence?

[BitZtream]

Just because you can tell it effects one OS and not the other doesn't mean they know why or even intentionally fixed it in the new OS.

The function with the problem is now considered part of the core OS in XP and not really part of IE anymore, even though IE updates often included updates to it, its more port of a common set of Internet related libraries which many applications use.

Because MANY applications use this library, making changes to it without evaluating what will happen to the many applications that use it could result in a lot of broken applications. Microsoft doesn't want to piss off a bunch of users by fixing a security flaw that will effectively break a lot of stupid apps that were also not written properly. As the open source patch page says, apps will break with they way it is done, so MS will take some more time and try to fix the problem in a way that doesn't bork everybody.

This is in contrast to the way the open source community would typically handle a problem such as this. Someone would patch the offending library, and any app that broke along the way (which is also likely to be open source since the user is already using open source applications/OSes) can also be patched as needed. The original authors typically would spend less time worrying about backwards compatibility issues and just break those apps in favor of security.

When you are dealing with an arena where most of the users A) use closed source apps B) don't watch for updates to their applications, let alone install them as soon as they come out. C) generally don't care about such issues until it effects them, D) get rather pissed off when a subtle change applied in an automatic update they automatically installed breaks applications when they see no relationship with. Then it makes sense to take your time and fix the problem and maintain as much backwards compatibility as possible, so users don't experience issues. I wish more open source developers would learn this. Any project with some age to it generally understands it, but plenty of new/small OSS libraries have no concept of backwards compatibility and/or the fact that fixing bugs should not break compatibility if there is any possible way to avoid it.

Its ignorant to think the core libraries which contain the ShellExecute function are the same in Vista and XP for so many reasons its not even funny. They are rather tightly linked into many parts of the OS, the main one that comes to mind is the registry. The simple fact that registry permissions are a lot different in Vista compared to XP probably resulted in a major refactoring of the function. If you understood how the function actually achieved its goals in the first place, you'd understand that its likely to have changed drastically in Vista and as such problem doesn't actually fix the problem directly, but as a side effect of other changes. Or, it could just be that the problem is different in Vista in such a way that it manifests itself differently.

I have no love for many of the things MS with Windows for a multitude of reasons. However, you're logic for bashing them here is ignorant at best. You have no concept of large scale software development or you would probably understand how this could show up in major OS revision and not in the next, and no understanding of where the function belongs in the system as a whole.

As a final thought though, by this point in time, the should have come up with a way to fix it with as little pain as possible, or admit defeat and break the apps that don't handle URLS properly anyway.

Re:What is Microsoft's reason for silence?

[xlsior]

Since IE7 was released after XP, it clearly indicates that this flaw has been on purpose; with some possible ulterior motive.

Never ascribe to malice, that which can be explained by incompetence.

Since the sytem core is different on XP vs. Vista, it's quite likely that there are differences in how IE7 interacts with XP than it does with Vista. It's not impossible that a genuine bug only affects the XP interaction but not Vista.

Re:Well...

[gQuigs]

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

I don't understand the logic

[BadAnalogyGuy]

I understand patching holes in Linux. There's no one out there who is going to hold you responsible if you release the patch for free and say install at your own risk. However, if you put out a patch for a closed source system, you run the risk of not only breaking some unexpected functionality, but also make your users susceptible to having their systems determined to be WGA-noncompliant. You run the risk of essentially breaking peoples' computers for what?

Yes, the risk is real and it sucks. But it's not your responsibility to fix Microsoft's holes. Once you do take on that responsibility, are you also willing to face the consequences when your users blame you for their license revocation?

Sure it won't happen this time, and maybe you'll dodge the bullet a few more times, but when the day comes that you've crossed over the line too far, will having fixed Microsoft's problems really been all that great?

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.

WHY?

[MBHkewl]

Why should ANYONE release a patch for Microsoft (regardless of their application)?
You ARE a paying user, and you SHOULD get the "quality" service you deserve. Isn't why the OS costs money?

I applaud those who have taken action & even more released the code as open source; it only shows the good hearts of the open source community, but as others mentioned, you may break something, in this very unstable OS, and you'll be the ones to blame, rather being thanked for saving the users' money, identity & privacy.

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.

Fingers in my ears

[Mikey-San]

I really don't want to hear about anyone's URI hole. Ew.