|
Joined: Jun 2005
Posts: 17
Pikka bird
|
OP
Pikka bird
Joined: Jun 2005
Posts: 17 |
OK, I know this is somewhat of an issue for some, but bear with me..
After having some weird problems with mIRC, I went back through my logs to look for any tale-tell traces of activities which might explain the problem I was having. One of the things I often look for is when someone joins a channel I am on and does a CTCP VERSION check of me or the entire channel, which may be a prelude to an attack (often, they searching for clients with known bugs/exploits in specific mIRC versions.) While looking for that, this idea hit me..
First, I know mIRC won't suppress showing it's version, and I am going under the single assumption that Khaled wants to "advertise" mIRC--Which is perfectly reasonable. Others, especially those who write and distribute complete scripts, also want to "advertise" their scripts. And still others, like myself, are simply concerned with security (I know IRC is not well-known for being very secure; However, that should not be justification against users trying to protect themselves, nor justification to make it any *less* secure.)
What about a compromise? Could mIRC give users some (limited) ability to customize the VERSION reply? Something like give them a choice if they want to display the actual version number, or simply display that it's mIRC without the specific version? What about allowing something like "UberScript for mIRC," as long as at some point, "mIRC" is prominently displayed?
Again, going under the assumption stated above, all mIRC really needs to do is make sure mIRC is shown somewhere in the text, and if not, add it. I, for one, really don't mind mIRC promoting itself--In fact, my own script let's mIRC send it's version reply, followed by my own custom one that gives the mIRC website URL (something the default reply doesn't do, heh), along with the URL for my own site (I don't really package a complete mIRC script, I just have some code snippets showing how I've done some things.) However, I would much prefer not showing that "6.3" (or whatever), since many exploits and attacks look for those versions which have known bugs that can be exploited.
Of course, since the majority of IRC clients in use these days is mIRC anyhow, the only major reason I see for version checks anymore are either those curious which script someone uses, or to find buggy clients to exploit. Likewise, those same reasons seem to be the main reasons for those who take steps to suppress the default version reply. Allowing some limited customization of the version reply would eliminate those reasons..
Cas
|
|
|
|
Joined: Jan 2003
Posts: 1,063
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 1,063 |
if you get into a channel where someone is versioning you and you suspect the person of hoarding data for possible future exploits, talk to an @ to have the person removed.
you don't want such a person in the channel so removing the person would be a much better way to counter the problem and saver for everyone in that channel.
If it ain't broken, don't fix it!
|
|
|
|
Joined: Oct 2006
Posts: 48
Ameglian cow
|
Ameglian cow
Joined: Oct 2006
Posts: 48 |
or just turn off / ignore ctcp's
|
|
|
|
Joined: Mar 2007
Posts: 218
Fjord artisan
|
Fjord artisan
Joined: Mar 2007
Posts: 218 |
One of the things I often look for is when someone joins a channel I am on and does a CTCP VERSION check of me or the entire channel, which may be a prelude to an attack (often, they searching for clients with known bugs/exploits in specific mIRC versions.) While looking for that, this idea hit me.. Your post to me indicates something totally different. Most of the clients out there for use are updated regularly such as mIRC. Unless you're using an old version, in which case that's your own fault. They aren't versioning you for that, a lot of networks don't mask ip's so they would just need to whois you. And most properly run networks don't want to run into trouble, they version you hoping to get back a reply of some description so they don't think you're a bot, or someone up to no good. Letting people customize their own reply would make this worse and you'd end up with more malicious users on networks. To sum this suggestion up, Terrible idea. Also, if people make scripts and don't like khaled's version reply next to theirs, tough.. use another client or make your own. You wouldn't start renaming your web browser or your email client when the opposite end tries to obtain the info, so why should his program be any different? It all points to dodgy dealings imo, a grey area.
|
|
|
|
Joined: Jun 2005
Posts: 17
Pikka bird
|
OP
Pikka bird
Joined: Jun 2005
Posts: 17 |
Addressing each counterpoint..
* Just because some software is the newest, latest, etc, does not make it bug/exploit-proof. Quite the contrary, many "hackers" seem to focus on the latest and newest because they can find new bugs to exploit that are not already fixed, and may take awhile before an updated and fixed version becomes available. It only takes one bad bug to be found and posted on some "hacker" site before the droves jump on the bandwagon to exploit it before it gets too old to be useful anymore. (Kind of the same logic that was presented; old clients need to be updated to remain useful.. Same for "hacks" and exploits. It's a constant game of cat-and-mouse.)
Edit: Besides, you also mentioned whois to get the IP.. You're actually reinforcing what I said: A whois and IP does not tell them *anything* about what computer or software is at that location, no more than "1234 Main street" tells you if it's a vacant lot, or the US Gov't Gold Reserve. But you can be sure the Gold Reserve would get a lot more attention if it had flashing neon signs advertising it's presence..
* Networks that do version checks will always have that problem, regardless. This is especially true when someone wants to write their own client from scratch. Or as others have suggested, ignore version checks, or use some other hack to bypass version replies, etc. How will a network respond any different to those situations? And most "bad" clients fake a reply to appear to be a legitimate client, anyhow. Consider eggdrop bots for example; There's many TCL scripts which make eggdrop bots appear to be regular mIRC clients. (I don't want to get into a network policy debate on the mIRC forum, but really, there's better and more reliable methods to validate clients, anyhow. You wouldn't leave your keys in the ignition of your car just to prove you are the owner because the key fits, would you? I hope not.. but it illustrates my point, the methods used are going about it the wrong way.)
* As far as the comment towards mail/web browsers.. Much the same applies, for many of the same reasons. They certainly can be custom configured (My FireFox presents itself as MSIE, for example), and I don't know many mailservers that challenge which mail client and version is being used, only that it properly authenticate that it has proper access to the server, such as a user account. The idea that a mailserver accept a connection merely because the client is Outlook Express seems pretty flaky to me. Likewise, Apache HTTPd can be configured to identify itself as nothing, just "Apache", the short version, the full version, etc. In any case, the legitimate clients/servers rarely need to fully identify their brand/name/version/etc., because they use other means to authenticate. While the malicious/bad users, spammers, etc., do everything in their power to appear to be a fully legitimate client/server in hopes that poorly designed security measures will let them right in (again, think if a mailserver gave you full access if all you had to do was claim to be OE.. You think spam is a problem now? heh..)
So this and the previous two points not only carry little weight, they are counter-intuitive; Networks which realize versioning alone won't solve the problem will find more reliable methods, making it more difficult for malicious/bad users to get in. While those who believe it protects them will just have more bad clients lurking under the guise of legitimate clients, which will be even harder to detect. (I won't even get into the ethical debate of "We hate Khaled at so-n-so network, so we'll ban you if your version is mIRC" type policy controls. Just be thankful that hasn't happened.. yet.)
* Turning off or ignoring CTCP's isn't really a solution, either. First off, those are all-or-nothing options, and much akin to "just script it!" Second, I can think of many ways around mIRC's version replies, and do so without even violating the license (in spirit/intent, I don't think it specifically forbids blocking version replies.. ?) But why do all that for something that could easily (in theory) be put right in the client?
* Reporting to the ops/irc-ops is also not really a solution. First, there are many legitimate reasons to version check. I would never assume a version check IS a prelude to an attack, only be more wary and on the lookout for one. Second, if it is an attack, it is possible it will happen too fast for me to report it, and/or the ops to respond before half the channel gets wiped out. Third, what if the ops really don't care? This may not be good channel policy, and I would suggest finding a better channel.. But it still happens. Lastly, if we could always get others in a group to cooperate without fuss, there would be little need for half the features already present in mIRC, or any IRC client. (Ever try telling the ops to use alphabetic nicknames and join the channel in a proper, organized manner, so they appear at the top of the list, while voices and regs use nicks further on down the alphabet just to make mIRC show a neat list? Try it. They'll laugh at you.)
Good thoughts and comments by all.. just they either fall outside the scope/purpose of the suggestion, or have problems/issues of their own. (But ultimately, it's up to Khaled to decide ;-))
Last edited by Casteele; 30/09/07 09:11 PM.
|
|
|
|
Joined: Mar 2006
Posts: 396
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Mar 2006
Posts: 396 |
Most of my scripts replys (VERSION CTCPREPLY) are:
My Scripts Name ( $+ mIRC $version on Win $+ $os $+ )
I think customizing the version reply should be allowed. Whilst I think that everyone using mIRC should show mIRC in the reply, customization would be great.
Its the newbie users who get exploited more commonly as most of the experienced guys (and girls) know how to modify the reply.
Perhaps this should be taken into consideration?
[02:16] * Titanic has quit IRC (Excess Flood)
|
|
|
|
Joined: Jan 2003
Posts: 20
Ameglian cow
|
Ameglian cow
Joined: Jan 2003
Posts: 20 |
Ummm.. You mean this? ctcp ^*:VERSION:*: {
.ctcpreply $nick VERSION I'm not using mIRC, really!
.haltdef
} OMG what have I done LOL. mIRC.chm - please, read!
Last edited by Tewl; 02/10/07 03:53 AM.
|
|
|
|
Joined: Jan 2003
Posts: 1,063
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 1,063 |
you can't haltdef the default version reply... you CAN haltdef all other CTCP's though
If it ain't broken, don't fix it!
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Gotta love it when people try to be cocky even when they don't know what they're talking about Edit: Infact.. Note: You can't prevent the standard version reply from being sent. Oh the irony
Last edited by hixxy; 02/10/07 11:35 AM.
|
|
|
|
Joined: Jan 2003
Posts: 20
Ameglian cow
|
Ameglian cow
Joined: Jan 2003
Posts: 20 |
Okay, my bad that doesn't work. But there are simple ways of preventing it. The most simple would be to create a small socket connection catch the replies before hand.
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
It's hardly "small" for the job it does, plus it's not very efficient. There are better ways, but since mIRC kinda has protections built in I won't bother mentioning them.
|
|
|
|
Joined: Dec 2002
Posts: 2,033
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,033 |
mIRC On The Fly Version Changer works great for me. ~ Edit ~
I don't use this to -change- the version reply, only to halt it without having to ignore CTCPs altogether. The same option should be built-in. Click
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Again, this is a non-issue if you keep your mirc up to date. mIRC hasn't had a known exploit since 6.11 which released in late 2003, making it almost 4 years old. It should be noted that when 6.11 was released on October 10th, and subsequently exploited, Khaled released a patch within 3 days, bringing the fix by October 13th. It should also be noted and stressed that a version number in your version reply is not what would get you in trouble in a situation like the days between October 10th to 13th. It actually doesn't even matter what your version reply is to anyone attempting an exploit in the end. Since most exploits are not costly to the exploiter at all, anyone exploiting mIRC in that time period won't care much about the version number and will probably just attempt the exploit on every client with "mIRC" in the reply... heck, they may not even look for the mIRC reply. In fact, versioning a channel and then wittling down the list is in most cases probably more costly than just running the exploit on the entire channel. The scenario for exploits in most cases is actually more like what I just described than what you proposed. I've been through all the major exploits for mIRC, and each time, the exploiter will blindly run his code on all clients in a channel. Your version reply would mean nothing. But again, this is not relevant, because mIRC has had no exploits for 4 years now, so this "issue" of yours really hasn't been a threat for a while, even if you say that a CTCP version will pre-empt an attack. If mIRC all of a sudden becomes dangerous from version to version, then maybe this might be something to consider.. until then, your reasoning sounds shallow, and I'm pretty sure you have ulterior motives for custom replies... one's that have nothing to do with the "security" FUD you just described.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jun 2003
Posts: 5,024
Hoopy frood
|
Hoopy frood
Joined: Jun 2003
Posts: 5,024 |
I agree.
And I doubt this will be incorporated no matter what.
Mentality/Chris
|
|
|
|
Joined: Mar 2006
Posts: 396
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Mar 2006
Posts: 396 |
Gotta love it when people try to be cocky even when they don't know what they're talking about Edit: Infact.. Note: You can't prevent the standard version reply from being sent. Oh the irony You do gotta love it. There are countless ways to change the reply, including but not limited to: mIRC DLL's. Socket Connections. mIRC's internal /debug alias External applications.
[02:16] * Titanic has quit IRC (Excess Flood)
|
|
|
|
Joined: Feb 2005
Posts: 342
Fjord artisan
|
Fjord artisan
Joined: Feb 2005
Posts: 342 |
hixxy is quite aware of the ways, I assure you. But, being that this is mIRC's forums, the users(us) should not be going into details of halting the version reply as it goes against Khaleds wishes. He wouldn't have made the version reply an exception to the /haltdef command if he did not care if it was displayed or not. However, more on topic, I wouldn't mind an option to remove just the Version number from the default reply. I'll always want "mIRC" to be in the version reply. As I've told many people who've asked how to hide the version reply in my prescence: Why hide it? Without mIRC, your scripts won't do anything. Khaled deserves credit for his work. If you really care that much about having your own version reply, I suggest you pick up C#/C/C++ and write your own IRC Client.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
But then the argument can be made, "if you're showing mIRC in the reply, what will removing the version number do for you?" And then we get back into this whole security argument again, which is not really a valid argument, as I pointed out.. so really, what is the point? This huge thread just to remove 4-5 characters from a version reply? I don't understand the fuss.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Dec 2002
Posts: 2,033
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,033 |
...as it goes against Khaleds wishes. He wouldn't have made the version reply an exception to the /haltdef command if he did not care if it was displayed or not.
Such circumventions had to have been expected with the addition of DLL support. Besides, what I do with it (the code) after I load the application into my memory is my business.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Such circumventions had to have been expected with the addition of DLL support.
That doesn't mean they should be supported here.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Feb 2005
Posts: 342
Fjord artisan
|
Fjord artisan
Joined: Feb 2005
Posts: 342 |
This huge thread just to remove 4-5 characters from a version reply? I don't understand the fuss. It gives people a false sense of security. I was just stating, I wouldn't -mind- the option to remove just the version number (while leaving everything else as is). I don't have a use for it myself.
|
|
|
|
|