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.
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.
See http://www.openwares.org/cgi-bin/exploit.cgi?slash dot.org&www.goatse.cx for instance.
It might log the addresses attempting to spoof webpages, but I'm all for that. And at least this explains clearly that a spoof was attempted through this exploit. I think it's better than just correcting the string, which would access a spoofed webpage anyways, even if showing the right address at the top... which of course would not work as well but many would still fall for it no matter, especially since it probably would look like http://www.paypal.com@paypal.something.net/ which would seem legitimate to the casual looker.
Wrong. :) The URL I found in the source code is http://www.openwares.org/cgi-bin/exploit.cgi? .. try it with http://www.openwares.org/cgi-bin/exploit.cgi?slash dot.org. It's the error page that the program displays when it hits a probable exploit. The program does the checking in your computer and when the link doesn't have %00 or %01, it just shows it normally. Only when it does see a %00 or %01, it sends the link to the above mentioned page.
If you ask me, maybe they want to have a record of which evil Paypal clone-sites are taking advantage of the exploit so they can tell the cops. Maybe they want to make it easy to tell the users that "MS has issued an update for this problem, please download it!", but of course maybe they want to display ads on that error page (Heh I would do the same).
But no, URLs that are okay are not being sent to that site.
What time is it/will be over there? Check with my iPhone app!
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.
From looking at the source it's not actually a patch so much as a 'wedge'. It creates a typelib (or COM object of some sort) that registers itself with the system. By doing this it hooks into the IE API, such that it is called every time a URL is visited. If it detects that the URL contains the spoof, it redirects you to their site, where a CGI script gives you an IE-error-like page: For example if the faked part of the URL was 'fake.com' and the real site was 'real.com' it would redirect you to http://www.openwares.org/cgi-bin/exploit.cgi?true. com&http://fake.com
So this is not so much a patch as a 'workaround'. It doesn't fix anything, it just intercepts those URLs and warns you about it.
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...