Slashdot Mirror
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.
trust OS people to fix what M$ can't find profit for!
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?
Why is the group releasing this on their own?
To quote the wise sages of the Quake 3 voiceover...
HUMILIATION!
My own pointless vanity vintage computing page
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.
Good to know that while Microsoft is leaving its users hanging out to dry patch-wise, the community still cares enough to fix the problems. Who knows -- maybe we'll see more effective (i.e., fixing more problems than they cause) patches from here forward.
What if the hokey-pokey really is what it's all about?
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. :)
For the adventurous among you.
http://www.openwares.org/downloads/IEpatch.EXE
If you wanna get rich, you know that payback is a bitch
If you check the code, all it appears to do is redirect the browser to http://www.openwares.org/cgi-bin/exploit.cgi?URL if someone clicks on a bogus URL.
The overpresence of "strcpy" is a bit unsettling, too.
While it's a nice step, it's no replacement for an official Microsoft patch.
How do you patch closed source code?
By violating the EULA by disassembling IE?
Lovely. I want Bill Gates poking around my sock drawer because I installed an unauthorized patch...
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 didn't ask me to reboot afterwards!!!
Someone start knitting a sweater for Satan...
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.
Sounds like you're in a no-win situation. You won't install a patch without the MS seal of approval but the patch (allegedly) repairs a known flaw in a product that HAD the MS seal of approval. So that begs the question: What is the value of the MS seal of approval if they're wrong? You'll never be able to install anything!!!
--Atlantix
when hell just froze over? Will microsoft actually have to acknowledge them? Thank them?
That's not the point. The point is that MS has ignored patching this vulnerability for far too long. It put its promise of "no patches for December" above the real and critical need to update the most common browser running on the worlds computers from hack attacks. Whether you install it or not is your business, and further more, if the patch was truly buggy everyone would be screaming about it by now.
READY.
PRINT ""+-0
In other news...
Today Micro$oft contributed code to the Linux kernel, and announced plans to help iron out differences between Mozilla and MSIE :-)
If people are doing open source IE patches, would somebody please fix this sucker? Thousands of people are complaining about this bug online, yet MS hasn't even officially admitted its existence. Now that's inept!
Found a wonderful fix it is called cfdisk! and slackware 9.1 setup, works great and no IE security issues!
OH THE SHAME I fell off the wagon and use sigs again!
If i am correct all microsoft applications do have allow access to APIs (Application Programming interfaces). I have written a simple application in Visual Basic once that used the API of MSN instant messenger to listen to the messages sent to me and do a custom auto reply saying things like "i will be back in a few mins".
Once someone has a grip of IE's API, this shouldnt have been too difficult - after all they just check if the URL requested for(which should be triggering an event in the API) has a particular type of input. If so they redirect it to a different URL (their own website).
If the patch has been done this way it is more reason not to apply it - it is not exactly the cleanest way to fix it.
Siggy Say, Siggy Do
M$ picks up an open source bug fix off the net, rolls it into IE and releases it real fast ..... 2 weeks later the FSF comes a knocking wanting to know where the source for IE is and "didn't you say in court your browser is so highly integrated into your OS it can't be removed ... we'll have the source to that too please" ....
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>From a cursory look at the source code, it looks to me as though there are at least two memory leaks. To be more specific, in function BeforeNavigateEvent(), there are two calls to malloc(), but no calls to free(), and the pointers that malloc() returns are stored in local variables, so there is no possibility that a parent function free()s them. Having said this, I haven't written any code under Windows, so maybe there is some kind of garbage collection in the Windows memory model that I am ignorant of?
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.
How do we know the executable doesn't have crap in there?
You know, the same could be asked of Internet Explorer.
Mikey-San
Karma: +Eleventy billion (mostly affected by watching Celebrity Jeopardy)
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...
Opera7.23- not only is it not vulnerable to this exploit, it pops up a dialog box to advise you're being redirected to a user@ address (and shows the real address in the bar).
--10scjed IANAL,AFAIK
Second, it's a horrible precedent for closed source software. Let close source fixed close source. This may seem like a good thing(tm) for the OSS communtity, but you know damn well that not-so-good-intentioned 'patches' will soon follow. Post some source on a site, provide an EXE(that of course didn't come from the source) and you've fished in countless joe users before the real word is out that a copy cat has duped you. Too late for some.
I can only see bad things(tm) coming from this idea. Geeks know who and what to trust, but Joe User doesn't. And when joe user screws up it screws us all.
The sum: This may have a greater negative impact in the long run then the good one it was intended to have.
Well, this is hilarious. I guess I should never assume anything until I try it out myself. Apparently when WideCharToMultiByte() fails, it DOES overwrite your string until but presumably does not go over the specified bounds. So their code is still vulnerable to remote code execution since you can fill the dest[] array with the shellcode and a new return address that would point to it. You only have 256 bytes to work with (in reality even less, since they have some other stuff on the stack that you need to get over before you get to the return address), but if you are good with assembly, that should be enough to do some fun stuff... In comparison, Slammer was 306 bytes in size, but of course did quite a bit too...
I think mozilla misrepresents the url in the status line while the address line shows the url correctly.
MSIE, on the other hand, fails completly.
In fact, on some versions of mozilla you even can spot a control char in the status line, too. But real spoofing depends on the address line.
heise (German)
As a test:
http://www.mozilla.org%00@www.heisec.de
is shown as http://www.heisec.de in mozilla, while msie puts http://www.mozilla.org into the address line.
605413? Yes, it's a prime.
Or maybe Microsoft will figure it doesn't need to provide patches in a timely manner, because the user community will do it for them.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
It seems you've got a good handle on this, so when can Openwares expect your patch for the vulnerability in thier patch?
Read, L
SCO Group of Lindon Utah announces that it has filed suit against Microsoft for including Unix/Linux code in Microsoft's Internet Explorer. Darl McBride says "There's no way these burger flipping losers could fix IE without our help. Microsoft couldn't even fix it without our lawyers."
Shrewd investors continue to laugh at the SCO Group's activities and have the following comments:
"The funniest thing I've seen since the Paris Hilton tapes!" - MSN
"A gut buster worthy of John Belushi - but SCO does more drugs" - Timothy Leary
SCO also announced that Caldera Linux licences still outpace all other SCO products - excluding lawsuits - by a 2:1 margin. Darl announced that they expect to make that 3 to 1 by next summer before they are purchased outright by IBM for $1.50 and a can of Red Bull.
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)
You do realize this patch phones home, don't you? Slashdot just advertised a piece of spyware. It phones home to validate every URL. Read the website.
The patch is open source. I don't even know if you are right in your statement but if you are, then download the source and change the way it works! Or live in fear...
Check the code again.
The only URLs that get sent to their servers are the ones that it's filtering out, ones that would normally exploit the bug. At the other end (granted, at least for now) is an IE-lookalike error message saying that the exploit was caught.
The first line before all that stuff involving redirection through their servers:
if (NULL != strstr(dest,"\2") || NULL != strstr(dest,"\1") || NULL != strstr(dest,"\218"))
It only matches URLs containing %01, %02, or %8F, which doesn't really "fix" the problem, but it's at least a workaround.
If you want to really reduce buffer overflow problems I suggest you visit the following two web pages:
The Better String Library
and
Getting user Input
I personally guarantee that buffer overflows in your code will dramatically decrease if you use the ideas spoken of and the source code on those pages.