Open Source Firm Releases Patch for IE Bug [UPDATED]
An anonymous reader writes "An open source and freeware software development web site has released a patch to fix the URL spoofing vulnerability in Internet Explorer, which can be exploited by scammers who try to trick people into revealing details of online banking accounts or other private information." Naturally, the source for the patch is available as well. Update: 12/19 15:06 GMT by M : Sadly, the patch appears to contain a buffer overflow and some possibly-malicious code - see an analysis and news story, and this comment which suggests the patch author is trying to figure out who is taking advantage of the original vulnerability. Caveat patcher.
In other news....M$ slams a DMCA lawsuit for "hacking".
Life is not for the lazy.
I'm not downloading anything that isn't part of a MS plan. Sounds like a trojan attempt to me.
Without the original source to IE?
This patch fixes a security bug in Internet Explorer that could allow someone who actually knows what they're doing to repair buggy programs on your computer.
So, there is an open source patch for a browser that the people that would have heard of the patch wouldn't use, the /. readers ought to be using mozilla and they know it, if they aren't using mozilla they probably will not install the patch either.
the people that would likely be fooled by this haven't heard of mozilla and haven't heard of open source and will not hear of this patch.
so this patch is pointless
(cool that it can be done though)
What the article doesn't say is that the "patch" just removes IE and installs Mozilla. :)
Ahem you cant see the source code of IE but you trust that? okay then
- meta language used, please apply your own spelling and gramma
Sorry, but its going to be a cold day in hell when I run something from a website named "openwarez.org".
It's only "open source" in the very loosest sense. From the patch:
Internet Explorer URL Spoofing Security Patch
Developed by Opensoft Corporation, Vanuatu
Contact: opensoft@openwares.org
Opensoft Corporation, Vanuatu
Copyright 2003 All rights reserved.
Terms of Agreement:
By using this source code, you agree to the
following terms:
1) You may use the source code, resource
files for educational purposes only.
2) You MAY NOT redistribute this source code
without written permission. Failure to do
so is a violation of copyright laws.
3) The author of this code may have retained
certain "additional copyright rights".
If so, this is indicated in the author's
description.
Pretty sure this makes Microsoft look really inept. I mean, if the largest and richest software company in the world can't patch their own products before a group of volunteer coders can figure out a fix ... seems to me that makes M$ look like fools.
My US$0.02, unadjusted for inflation of course.
In other news...
Today Micro$oft contributed code to the Linux kernel, and announced plans to help iron out differences between Mozilla and MSIE :-)
Yes, of course! The subpoena will mention them by name.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Judging from the source it's a quite simple COM object, which hooks into IE and checks URLs before IE actually starts "processing" them (opening connections, parsing...)
If it finds anything out of the ordinary (like an exploit) it just redirects IE to their own site. Specifically to http://www.openwares.org/cgi-bin/exploit.cgi. It adds a few paramters (the fake url among other), so I guess they will be building a database of exploiters...
It's no patch, IE stays as it is. It's more a workaround. I'm not sure whether these hooks are documented (allthough being a windows system programmer I never liked IE and stayed as far away from it as possible), but if yes, Microsoft might actually have nothing on openwaves...
If this patch gets the press coverage that it deserves, maybe people will learn to take Microsoft's claims of better security response rates than those open-source folk, with a grain of salt.
Or maybe Microsoft will actually start working harder to keep their software secure in a timely manner?
</fingers_crossed>The time it takes to patch the problem is miniscule compared to the regression testing done to make sure the patch fucks up as little as possible. They test EXTENSIVELY and even so you still get the occasional patch that interacts with other software and ways you can't predict and breaks something. It happens. Any code monkey could hack out a patch, but I know damn well they haven't tested this as much as a corporation supporting 90% of the world's browser users would. That's where the time is, so quit bitching about how long it takes to release a patch. Now, the time it takes to ACKNOWLEDGE a bug is a different story....
Geek used to be a four letter word. Now it's a six-figure one.
Doesn't this mean that nobody else is allowed to distribute it? I mean, MS could still get in a whole lot of trouble for inclusing this code in its patch, but they wouldn't risk losing source code.
Yeah, patch Q824145. In my case, it turned out to be a blessing. I got so pissed off that MSFT broke standard UI scrolling behavior that I switched to Firebird. I don't understand how a large, successful software company can do such sloppy QA and think that nobody will notice. But then, there are many things that I don't understand.
A list of the bad things about this "patch", just at first glance:
1. Leaks 256 bytes on every URL navigation
2. Leaks 512 additional bytes if it finds an exploit URL
3. Creates a string with the \1 char in it on every call, but does nothing with it
4. Will overwrite stuff on the stack if the URL has the exploit and is very close to 256 chars in length.
It's a good thing these guys aren't on the real IE dev team.
if you'd have taken a few minutes (or seconds w/broadband) to get the source and look at the code, you'd see this:
By using this source code, you agree to the following terms: 1) You may use the source code, resource files for educational purposes only. 2) You MAY NOT redistribute this source code without written permission. Failure to do so is a violation of copyright laws. 3) The author of this code may have retained certain "additional copyright rights". If so, this is indicated in the author's description.
since i doubt there'd be anything educational about IE source code...and by the way, i don't think this qualifies as an open source license.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
On top of that, it's buggy. It has a memory leak in its BeforeNavigatorEvent() IE callback function which gets triggered before a loading of each new page. There they allocate a string of 256 bytes, but never even bother to clean it up!
I'm not even sure if that memory is going to be cleaned up when you close all the IE windows, since it's really a Windows system component and this DLL may not be unloaded even with the closing of IE. But I may wrong that point...
But even that's not the worst thing. Their code actually contains a buffer overflow, allowing the attacker to execute code on your machine with the privileges of the IE process just by crafting an invalid URL link and getting you to click on it!
Basically, they use WideCharToMultiByte() to convert the unicode URL string to that allocated 256-byte ASCII character array. They tell the function the size of their array, but if the URL string exceed 256 characters in length, it will not overwrite that buffer and cause an immediate buffer overflow. Instead it will fail and tell you to increase your buffer. Well, guess what? They don't check for that failure condition (and, incidentally, it may fail for many other reasons during the Unicode->ASCII conversion) and happily proceed to use it in a strcpy() later on, overwriting another 256-byte character array which is now located on the stack. A nasty buffer overflow just waiting to be exploited...
So to summarize, they took a relatively minor problem (URL spoofing) and made it a hundred times worse with their 'solution'. Great job, guys!
Offending code:
Eh. Just realized that since WideCharToMultiByte() will fail, it will not actually copy the URL to the dest[] array and thus, you probably can't overwrite the return address with a legitimate value and get it to point at your shellcode. It's still easy to overwrite it with a random value (with whatever is sitting at the time in the uninitialized dest[] array) and cause a crash, but executing malicious code may be a little harder to pull off...
Why would Microsoft use this code in their patch ? This patch code is based upon readily available IE com interfaces which allow addon IE programs to interact with browser operations. In fact, this patch simply checks the url for the vulnerability every time you navigate to the page. If the vulnerability is found it instead naviagtes to: http://www.openwares.org/cgi-bin/exploit.cgi?A& ;B where A is the spoofed url and B is the actual url. Microsoft would fix this vulnerability in the actual IE code, not in a bolted on module like this.
hmm... ::BeforeNavigateEvent (IETray.cpp)
In
It copies the string to a MBCS buffer, and scans for %01, %02, and %DA. If none of these exist, the rest of the function is skipped. Don't see how this phones home.
Of course, the strings is malloc()ed but never free()ed... But that's another matter. That and for some reason they don't just use all-unicode (use wcsstr() etc.)... What if I wanted to surf to a site with a character that is not in the current code page? (e.g., search for Japanese text on Google using an English O/S) (Note that IE has the option of always sending the URL in UTF-8, so it has to be able to deal with characters not in the ACP)