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.
I can't even come up with a good joke for this. Seriously. It's just too good. Way, way too good.
My own pointless vanity vintage computing page
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.
Unfortunately, with this being an unofficial release, I don't see many people likely to utilize this until it is released by Microsoft. In the meantime, I am enjoying reading this in Mozilla :)
*
troll blacklist. Please mo
It's called Mozilla/Firebird.
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.
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...
A third party releasing a patch to a browser. How safe is this?
Yes the source code is there, but how do we know the executable doesn't have crap in there?
Even if everything is clean now, how about the next patch from another source?
(Not even saying anything about testing and how it can break something. They don't even have the source code of the original product.)
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
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
Does applying a third party patch violate the EULA for IE?
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.
I can tell you this: It doesn't surprise me that Microsoft isn't doing its job properly. It's a software company. It should produce a reliable product. But instead, it produces trouble.
Further, it doesn't surprise me that the open source community is fighting back, so to speak, by fixing this particular problem. I think that as time goes by, more patches for commercial software will be released by independant programmers in the open source community, because of frustration with the inability to get satisfaction from the "real" producer of the software.
I only hope that Microsoft won't pull some stupid DMCA bullshit to stop this. "Yeah, your honor, we believe it is detrimental to the best interests of our customers when bugs in our software are fixed. It should, instead, be illegal to discuss, fix, or exploit these bugs in any way, unless one is a member of the underground h4x0r community, in which case, exploiting the bugs is perfectly ok." (We all know Bill Gates is the leader of all these movements to steal credit card numbers through exploits in his own code. That's how he earned his zillions of dollars. Nobody actually buys stuff from Microsoft, you know.
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
While Microsoft has released an article providing details about the vulnerability, the company is yet to provide a patch.
I hope this become a trend and attitude among the Open Source community. I must admit that I've been a Microsoft-hater for years, but over time I found that people are really put off by anti-corporation sentiments. I suppose it makes sense in a way; If I invested thousands in a technology for my business, I wouldn't want people telling me "Aw man! You got totally taken! Windows is total crap!"
If the Open Source community begins patching Windows before Microsoft, not only does it help consumers deal with problems they can't solve, but it bring honor and respect to the Open Source community. Then when people consider Open Source, they're more likely to conclude that Open Source programmers are more competant than corporate programmers.
It's a win-win-lose. Open Source wins, Consumers win, and Microsoft loses. Which is what I wanted in the first place.
ESR's right in his article "How to Become a Hacker"
Q: Do I need to hate and bash Microsoft?
A: No, you don't. Not that Microsoft isn't loathsome, but there was a hacker culture long before Microsoft and there will still be one long after Microsoft is history. Any energy you spend hating Microsoft would be better spent on loving your craft. Write good code -- that will bash Microsoft quite sufficiently without polluting your karma.
Ruby on Rails Screencast
I don't have any idea why MS decided to wait until next year before fixing something which is otherwise a severe security issue. I guess everyone is just lead to believe that MS simply doesn't care if your PC gets hacked, because then they can go around and pass the buck to spammers and charge people for an upgrade or support.
I think this patch release makes more of a political statement, regardless of the issues surrounding whether an OSS company should be putting out patches for proprietary products.
READY.
PRINT ""+-0
when hell just froze over? Will microsoft actually have to acknowledge them? Thank them?
An open source firm issued the patch a while back -- It was called mozilla.
How does this affect IE, the MS EULA, and all the other wonderful legal stuff that could be dragged out simply because you modified software that wasn't meant to be modified outside the confines of One Microsoft Way?
Patch on, I guess...if you must. I sleep much more soundly with my RH9 and Firebird.
this is the whois record for that domain from whois.networksolutions.com:
Domain ID:D98313967-LROR
Domain Name:OPENWARES.ORG
Created On:03-Jul-2003 22:49:55 UTC
Last Updated On:02-Sep-2003 03:58:23 UTC
Expiration Date:03-Jul-2004 22:49:55 UTC
Sponsoring Registrar:R14-LROR
Status:OK
Registrant ID:WBMRD
Registrant Name:ori rejwan
Registrant Street1:52 Herbert Samuel St.
Registrant City:Tel Aviv
Registrant State/Province:NA
Registrant Postal Code:63304
Registrant Country:IL
Registrant Phone:+1.97250314892
Registrant Email:orejwan@yahoo.com
Admin ID:WBMRD
Admin Name:ori rejwan
Admin Street1:52 Herbert Samuel St.
Admin City:Tel Aviv
Admin State/Province:NA
Admin Postal Code:63304
Admin Country:IL
Admin Phone:+1.97250314892
Admin Email:orejwan@yahoo.com
Tech ID:AD384-ORG
Tech Name:Mohammed Zarqa
Tech Organization:Tri State Contracting
Tech Street1:POBox 455
Tech City:East Brunswick
Tech State/Province:NJ
Tech Postal Code:08816
Tech Country:US
Tech Phone:+1.7322383766
Tech Email:mzarqa@aol.com
Name Server:NS2.ABAC.COM
Name Server:NS1.ABAC.COM
It's up to you to decide whether you trust them or not.
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
That's not a link! This is a link:
http://www.openwares.org/downloads/IEpatch.EXE
P.S. I haven't actually tried the executable out, I just added the clickable goodness. I also couldn't pass up the chance to make a Crocodile Dundee joke.
In other news...
Today Micro$oft contributed code to the Linux kernel, and announced plans to help iron out differences between Mozilla and MSIE :-)
Poor MicroSoft!
Microsoft's biggest software threat gets a huge update, one of their own products gets a patch by a third party, Real Networks sues them for monopolistic activities, and Lord of the Rings - Return of the King (a movie made with cheap Linux boxes) is realeased. All this in a 48 hour period!
Man, it's been a rough couple of days.
Sm:)e.
I guess you don't invest in any stock then . . .
.
Being open is not for your benefit because you have any clue how things work. Being open allows objective 3rd parties who have a clue to give an opinion on the matter so that the clueless masses (though shrinking everyday) can make a decent decision. To benefit to you is indirect, but it is a real tangible benefit, nonetheless.
Now, objectivity and expertise to you might simply be synonymous with "MS," but if the financial market were that naive I doubt we would have ever recovered from the great depression . .
Hope my reality wasn't too harsh for your bubble.
Sdelat' Ameriku velikoy Snova!
This patch apparently intercepts the badly-formated URL and then forwards you to patch maker's website.
It would be more efficient, safer, and simpler (no need to do any patching) to implement a similar solution using a proxy like Privoxy. The proxy (installed on your local machine or LAN) would then be used to intercept the badly-formated URL, and replace it with its own locally generated warning page (again, similar to Privoxy).
I think Privoxy is OSS. Maybe someone could whip something up.
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!
(t'was easy, sorry)
We've always been at war with Eurasia.
Maybe they forgot to sign the EULA?
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!
This is the beginning of a really bad precedent. It is bad enough that M$ makes bad software and takes too long to fix it, but this just makes it okay to keep doing that. M$ will know that now they don't even HAVE to fix it. Just wait and let the open source community do it. THEN, when multiple patches start conflicting because of reasons already mentioned above, M$ can blame open source as the problem. Heck, they might even 'embrace' open source for a time, then use this as justification that it open source doesn't work.
Open source enthusiasts have TWICE paid to renew Microsoft's domain registries (once for hotmail, once for microsoft UK) when Microsoft forgot... so who should you trust with your data, the people that can't even remember to renew their own domain registrations, or the people that keep bailing them out?
"Freedom means freedom for everybody" -- Dick Cheney
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...
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.
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.
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.
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...
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.
If Microsoft employed better software design, IE wouldn't be entangled with the whole OS, and their testing workload wouldn't need to be so extensive.
I know damn well they haven't tested this as much as a corporation supporting 90% of the world's browser users would
Several times, 3rd party volunteers have demonstrated the ability to test Microsoft's software more thoroughly than the publisher ever did. (Server software though, which can be easily tested by software, not the browser)
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...
If your software is so tangled in intertwined components that a patch for an issue this simple would conceivably break something elsewhere on your system, then your terrible product design is the concern, not the QA.
If Microsoft employed better software design, IE wouldn't be entangled with the whole OS, and their testing workload wouldn't need to be so extensive
Even if IE wasn't entangled in the OS, there's still a shitload of testing to do. Also, MS TRIES to make sure that their patches don't break 3rd party apps. How many other companies do you know that do that? I'm not saying they always succeed at that, but they try, since it is in their own best interest. They don't need the whole world thinking their patch sucks because it broke some spyware/hotbar/whatever else IE add-in.
Several times, 3rd party volunteers have demonstrated the ability to test Microsoft's software more thoroughly than the publisher ever did. (Server software though, which can be easily tested by software, not the browser)
Yes, any one with an axe to grind with MS can spend the majority of their adult life testing MS software in order to break it and find flaws. In fact, many security companies make their living doing this. However, MS is a business. A business that likes money. As everyone knows, time is money, and if MS thinks it has put enough time into testing, it will release the patch, perhaps a bit prematurely. It happens. Hell, for all we know, MS may wait for someone else to find the bugs so that they don't waste time and money on it! It's unlikely, but it would be smart business. Also, if you are suggesting that software testing would catch all the problems, you'd be mistaken. Who is to say the software checking the software doesn't have a few bits loose? Adding to that, it is impossible (in hardware, software, or otherwise) to predict every interaction code will have due to all of the 3rd party apps out there.
Geek used to be a four letter word. Now it's a six-figure one.
Now if a benevolent open source firm would make a patch that gave IE PROPER PNG support, then I would be very grateful (I have been swearing at IE's lack of png support for the last hour for messing up my very cool website design)
History will be kind to me, for I intend to write it - Sir Winston Churchill
Umm...I don't know if you've ever done any patching, but usually you can tell by the broken code and the new code what areas to generally look at for incompatibilities. Most calls made shouldn't really be changed and the original code should be left untouched as much as possible. If so much of the code is a problem that you literally have to test the whole system, oh well thats sloppy coding and its their fault. On Debian, security patches are as much of the original code as possible and the rules on what can be changed in the code are fairly strict. Despite this, security patches are always released promptly and people can have the assurance that their systems will remain stable and won't be broken. MS doesn't really have an excuse. Hell, if they opened the code I'd do the patching for them. Just my 2 cents.
-Steve
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
This patch uses strcpy()/strcat() and 256 char buffers instead of dynamic buffers and strncpy()/strncat() in IETray.cpp.
FOR THE LOVE OF GOD/ALLAH/BUDHA DONT USE strcpy()/strcat()/gets() !!!
These functions ought to be made illegal. This is why buffer overflows exist, because amateur coders generally don't know what they're doing and because they dont grasp the security implications of design decisions. Be warned, users[ESC]bcwidiots herd together.
-- Naive C programming will get you everywhere, it appears, even if you don't have a clue.
The biggest trick the devil pulled was letting lawyers become politicians so they can write the laws.
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.
Then nobody would have noticed the stack vulnerability, unless you had either a machine vulnerable to the original exploit, or a machine vulnerable to a new exploit as per being patched
:-)
Since it is open-source, however, somebody can fix that bug nice and quick before it becomes another problem (gee, imagine that).
Lack of foresite on the behalf of the patch developer is a bit disturbing, but not a bad reflection on OS code at all
Microsoft, in it's efforts to steer people away from FoxPro to Access, many years ago, decided to not bother patching some serious issues with FoxPro. What happened was there was a very poor piece of code that tried to figure out how fast your processor was when FoxPro started up, I forget exactly what it was for, but the programmer(s) made a small bug where if the processor was extremely fast, the value would be set to -1, and FoxPro would promptly crash. Worked fine for years until some of the new processors came out.
Anyway, Microsoft stalled on fixing this timing issue bug, so some smart fellow tweaked the exe file to fix it. Yeah, not even assembler, we're talking hex. Pretty damn cool.
There's a saying for this: crap built upon crap.
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 ...[more scary windows stuff]
Seems like a combination of the lousy design of the Windows components coupled with using C. Long, long time since I've worried about destroy and the like, what with the availability of better languages like Java, etc. Granted once buffer overflows are a thing of the past, there will be new holes, but at least we will be moving forward.
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!
Good catch. So one security flaw fixed, opening up another flaw - a little embarrasing, except MSFT did the same thing a few weeks ago in their flurry of untested patches. But it does show the inherent advantage of open source in that *anyone* can review the code, and fix it, without resorting to messy hacks such as this.
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;
// 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.
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.
Uh... you may want to try and understand the code first, particular this conditional statement:
Only if that condition is matched -- the string contains bytes having the integer values 1, 2, or 218 -- do you get redirected to their server. Nice troll attempt though.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Is the "@-spoof" really a spoof? According to RFC2396, section 3.2.2 "Server-based Naming Authority", this is a feature of the URI and not a bug or a spoof.
Certainly it can be made to fool even an enlightened user, but isn't it wrong to cripple a browser's ability to adhere to the "Uniform Resource Identifiers (URI): Generic Syntax" RFC -- and even more so with spyware ;)
Browsing the "test page" at Openwares with my Konqueror gives me the spoof page. Good. That just means that Konqueror is RFC2396-compliant (but should i patch anyway? ;).
I first came across this "bug" about two years ago when i was forwarded an "authentic" page from Microsoft Support: Q209354 - HOWTO (mirror). It took me a while to realize that nobody at M$ was going to be fired for this type of creativity.
See The Reg for an article for some coverage -- although the host hwnd.net is off the net, so you can't really try to get spoofed.
On a related topic, did anyone else notice that chrome-free popups are to be terminated in XP SP2 (announced yesterday)? They're a great technique for the site spoofers since you can have the whole shebang - genuine looking URL *and* a nice little SSL padlock. Simply use a screenshot of a real online bank as the background and stick your own HTML form on top to capture the login details. JavaScript aficionados can even make the address bar and toolbar work like the real thing, if they see fit. Thankfully the Russian mafia aren't that sophisticated...yet.
When I am king, you will be first against the wall.
Well that's hardly in the spirit! I have a proposed fix for this "patch" that you can find here:
IETrap.cpp
Diffs
So I've patched their patch, and violated their license agreement after they violated the Microsoft EULA. That makes me feel so recursive.
You should use MyIE2 instead, http://www.myie2.com Fixed "IE URL Spoofing Vulnerability" problem. You also get the following: Tabbed Browsing Interface Mouse Gestures Super Drag&Drop Privacy Protection AD Hunter Google Bar Support External Utility Bar Skinning What else could you ask for?
I am against words getting a new meaning just because computers are involved. YES I am anal. Some of us need to be.
As for how this is done? Same way as all the IE plugins. All those bars you see and popup blockers? Same thing.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Uhh... MS al ready does on host not found errors, with their MSN search.
Not only do they redirect you to their servers, but their service packs have a nasty habit of resetting your IE preferences to doing this, even if you have chosen to NOT go to MSN.com in your settings. I don't like either company doing this, but MS is the worse about it. Symantec also is bad about this kind of violations. Try installing and uninstalling any Norton product, then go swimming into your registry and see. Adds half a meg of registry even when uninstalled.
Again, a major reason I keep looking toward Linux/MacOS/BSD.
Tequila: It's not just for breakfast anymore!
According to Heise Security www.heise.de this patch actually builds up bigger security holes than it repairs
0 02/
c k/ demos/ie/e5_18.shtml
In german:
http://www.heise.de/newsticker/data/dab-19.12.03-
Actually the have also a test for those who already patched their systems with this:
http://www.heise.de/security/dienste/browserche
So do not use this patch!
That said, I'm not real impressed with this "patch" - theres alot of use of c-style string work in a C++ file, which is silly, and more than that it's not even safe use of c-strings - the file concatenation of the URL together involves just using strcat() (not even strncat()) without any sort of length or sanity checking on the buffer.
Notice the total lack of sanity checking on the lengths of those buffers... This is especially bad because surl is a stack based buffer and theres no reason whatsoever to not use strncat() in this case.
So the old mantra of "Dos isn't done until Lotus won't run" has been completely wiped out of MS' corporate consciousness?
Yep, better string handling. Always good.
But I was wondering... buffer overflows are a problem because we have a descending stack - ie. as you add stuff, the stack pointer moves backwards through memory - so the return address and other data is always located just in front of any local data.
What is the reasoning behind the use of a descending stack? Is this a legacy from a hardware or software decision? Is there anything we would lose by having an ascending stack, which would make overflow exploits a lot more difficult? Anyone know?