Slashdot Mirror
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."
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?
My wild guess is that they're testing the patch. Remember that it's going to be deployed to many thousands, tens of thousands, however many systems, so they gotta make sure it works. Otherwise, there'll be a lot hosed boxes.
Of course, that could indeed not be the case at all...
"Beware of he who would deny you access to information, for in his heart he dreams himself your master."
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
There are two types of people in the world: Those who crave closure
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.
But unofficial patches for closed source software have a worse track record. I recall some other case where IE had a tiny little information leak. Somebody then released a "patch" for that, which not only was an ugly hack, but at the same time introduced a buffer overflow which was a lot worse than the original bug. The "patch" came with source, but AFAIR the license did not permit you to fix the bug in the "patch".
Introducing a much worse security hole when fixing a minor security hole is the kind of thing that can happen when you write code without getting it reviewed. Any decent code review would have caught that bug. And that is not the real reason third party "patches" for closed source software is a bad idea.
The correct way to fix a bug in any piece of software is to take the source, fix the bug, and recompile. No third party can do that for a closed source product, which is why that approach is never going to be good for the users.
Do you care about the security of your wireless mouse?
To Microsoft, apps are marketing. People know Windows isn't that great. Even most people with little clue that there are alternatives know that Windows sucks. What they don't know is how to do the things on other systems they can do on Windows. The apps are different. They're sometimes harder to install (but sometimes, IMO, easier) on some of the alternatives. Sometimes you can't find a suitable alternative at all. There are training issues and issues with re-acquiring things already bought. There's data transfer problems with incompatible file types, undocumented file formats, and insufficient export from the Windows apps and insufficient import on the OS X, Solaris, or Linux apps. There's not a cardboard-box market for most non-Windows applications.
Quite simply, when Steve Ballmer yells, "Developers, developers, developers!", it's because that's Microsoft's ticket to keeping its huge installed base. If you get the application developers in a company won over to your OS exclusively, the applications from that company will be written for your OS exclusively. When people find enough of those applications that are Windows-only difficult to cut loose, how in the world are they going to cut Windows loose?
There are great applications for OS X, Linux, and Solaris. Likewise for the BSDs, MorphOS, Amiga OS3, Plan9, AIX, OS/2, and more. The application stacks for all these systems are strong and deep. What they're not is broad. Final Cut Pro rocks. Apache is wonderful. Ardour is great. Blender and Lightwave are really nice. There are some killer games on Linux and OS X. There's just not much. There's great stuff, but there's just not enough of it to compare to what you can get for Windows. If you're running servers or doing narrowly defined work, that's great. If it's for a hobby or for a second or third computer, that's great. If, however, you need the broadest possible access to strange, non-portable or unported, shrink-wrapped random crap, at least one desktop needs to be Windows. That situation may change, and I hope it will. That's just the truth right now, though.