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.
For the adventurous among you.
http://www.openwares.org/downloads/IEpatch.EXE
If you wanna get rich, you know that payback is a bitch
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.
Off-hand- I'd probably stick a debugger on it, viewing the code at assembler level, and trace the carriage return in from the OS; or something like that. I mean the OS has to call or return to IE when the carriage return is hit; there can't be that many places in the code where it is waiting for input- stick a breakpoint on all of them, and whichever one gets hit after you click on the carriage return is starting to process the code. Run it multiple times with different input and pretty soon you should start to see the patterns.
It's not especially easy, but it's doable, I've done stuff like that before. It's easier if you have the source code, but it's just slower if you don't.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Actually, Mozilla/Firebird is partially vulnerable to this bug too. At the moment, the patches are Opera and Safari.;)
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
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?
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.
It seems like they made an add-on to IE (it's been done before, e.g. GoogleBar, various pop-up stoppers, Gator/Claria), that probably monitors all URLs, and removes %00's and %01's out of it before giving it back to IE.
:P
Funny stuff, it's mostly a band-aid solution IMO, but a nice slap in the face for MS.
What time is it/will be over there? Check with my iPhone app!
Out of curiosity I took a quick look at the code. Right off the bat I see what MAY be new problems introduced by this code (I'm not a Windows programmer or user so I can't be sure), but I see what looks like a memory leak for every URL. In CIETray::BeforeNavigateEvent a new destination string gets allocated via malloc.
1. *dest is not verified to be non-NULL.
2. *dest does not appear to be freed, resulting in a 256 byte memory leak per URL.
3. URLs greater than 255 characters in size might have problems since the length 256 is hard-coded into the code.
4. It may be a similar problem for *url.
Granted, I only spent 5 minutes glancing at the code, but I don't like what I see, and the cure might be worse than the disease. I'd like to see a serious audit of this code before trusting it.
I'm not sure if these are actual problems or not since I don't have the time to learn all the Windows APIs and programming, but it looks highly suspect to me. I do embedded C and Unix programming, not Windows programming.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
MyIE2, which uses the IE engine but adds a lot of features (including tabbed browsing), released an update on Dec.14 to fix this bug.
http://www.myie2.com/html_en/update.htm
Wow. That's great! You mean, somewhere, there's a group of people who have reviewed this code and pronounced it safe for my enterprise? Kool and the gang, man! Where's the url for that? Better yet, give me a phone number I can call so I can talk to them. I'm sure that I've met most of them and can personally attest to the fact that they know shit over shinola about development AND my environment.
Sorry Skippy...I've got better things to do with my time than potentially fuck the enterprise that my employer has entrusted to me and my team.
Who's to say that my onsite TAM isn't going to spontaeneously combust when he sees that I rolled out a patch from some group o' yayhoos who genned it up for shitz n grinz? What happens when my support contract gets nullified on 10,000+ desktops? You think my boss is going to give a tin-plated rat's ass that some Slashdot folks think it's cool that there's an open source patch for a proprietary app?
Microsoft may not be the best dog, and it may not have the fewest fleas. But when the guy signing your paycheck says that you're a Microsoft shop and you're gonna support it by their rules, then you by-God are gonna do it. Or find yourself a new line of work.
where is the "I feel for ya, but that's some funny ass shit" moderation?
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!
It is more like a crutch. Their DLL uses the Browser Helper Objects COM hook to synch events from IE. They examine the url and take you to their website instead when you try to navigate to a spoofed url.
Can I bum a sig?
How many times did you decide to post this same comment? It does not become you, especially since the other two were anonymous.
Here's the first anonymous duplicate posting.
And here's the other anonymous duplicate posting!
"It's a very tangled subsystem." --Windows kernel guru
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.
dear moron: The patch only redirects URLs that it has already verified are being spoofed. The only time a request is redirected is if you've tried to access a spoofed page.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
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...
Notice the parts in bold. Is it not apparent that 'surl' can easily be overflowed if strlen(sFake) + strlen(sTrue) + strlen("http://www.openwares.org/cgi-bin/exploit.
Why would they do the analysis on the server? Checking for an invalid character can be done in one line of C code (a few more to check for all possible invalid chars). No programmer with an IQ above freezing would go to all the extra trouble to implement a special server to run that code when it works much better in the client. All the server is is one CGI script that dresses up and echos back the parameters it was sent.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
AM I THE ONLY ONE TO WHICH THIS SCREAMS PRIVACY INVASION?
I think Slashdot just posted a link to a trojan on the front page. To all who just installed this: you have been pwn3d.
I do not believe that is entirely correct. It's only giving it 256 bytes to store the redirected-to URL. It then gives 256 bytes for the fake URL and the true URL. Nothing, that I see in here, is preventing strcat/strcpy from pushing data beyond 256 bytes.
To quote: "MS TRIES to make sure that their patches don't break 3rd party apps."
Bullshit ! MS only tests for apps that have parent companies they get along with (also known has, they haven't tried to start a monopoly in that market yet.). As a matter of fact they were convicted in court of releasing patches that BROKE third party functionality on PURPOSE.
Who ever modded you as insightful was an ass.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
is not that freaking hard, people!
At least this simple type with C-style strings (char*) and fixed-size buffers.
Here's the rule:
Instead of using any of
strcat()
strcpy()
sprintf()
gets()
you use
strncat()
strncpy()
snprintf()
fgets()
The second set of functions all take a length parameter which is the maximum number of bytes that the function will copy. You don't have to worry about your source not being null-terminated, or being unusually long, because the function will not copy more bytes than you say it can. snprintf() (in C99) is especially cool because it returns the number of bytes it would have written if the length parameter were larger.
strncat() is still kinda annoying, because it copies N bytes, as opposed to using N as the overall size of the target buffer. So whereas in the other functions you just pass it the size of the destination buffer, with strcat you pass size of buffer - strlen(buffer). Still pretty easy.
Do not use strcpy, strcat, or sprintf with user-supplied input! And especially don't use gets()!
It really isn't that hard!
The enemies of Democracy are
You do know that the "patch" is a spyware style CGI script to log your browsing habits?
Wrong. Try actually reading the source, and you'll see that's not what it is at all. I don't even use IE, so my reading through the source was very quick, yet I was even able to pick up on how it actually works.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
Better link
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.
No, the GPL isn't the only way for distributing source code. The code could be in the public domain (or no license), allowing anyone to use/distribute it, it could well be under a BSD style license which would allow anyone to do whatever with the code. And no, whichever way the code is licensed Microsoft couldn't lose source code. As this is a standalone fix using the IE COM interface the code doesn't link to any Microsoft object code. Therefore the GPL doesn't apply.
Except that, in fact, it's not any of those OTHER options either. No, nobody besides the author is permitted to distribute the patch code (RTFLicense). The GPL not applying has nothing to do with it being a IE COM help object, the GPL doesn't apply because the code isn't under the GPL. Simple as that.
It's also a really crappy implementation thats full of it's own security and coding issues - it's cool that they did it and all but I kinda wish that they'd spent some more time checking the code, because this is exactly the sort of shit that MS is talking about when it brings up it's FUD about "it takes a long time because we have to test the patches".
So the old mantra of "Dos isn't done until Lotus won't run" has been completely wiped out of MS' corporate consciousness?
I applied Win2K patches (via Windows Update) and it rendered my system unbootable. Something about path expansion(?) and msgina.dll... Not worth investigating when Ghost is so handy.
Luckily it was only the spare computer, but still...