mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Sep 2011
Posts: 9
T
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Sep 2011
Posts: 9
Hello,

It appears that mIRC is especially vulnerable to the BEAST TLS attack due to the fact that any user on the IRC network can make mIRC generate an unlimited number of responses using the CTCP VERSION command (which is impossible to disable in mIRC). The CTCP VERSION command makes the mIRC user send a known plaintext encrypted though SSL which helps the BEAST attack.

This way, if the the attacker (Eve) is between the user (Alice) and the server (Bob) e.g. on the local network, then Eve will be able to decrypt all encrypted communications between Alice and Bob.

Suggestion for mitigation of this vulnerability: Make the response to CTCP version configurable user side, i.e. create a checkbox in mIRC configuration allowing the user to enable automatic response to CTCP version, and make this disabled by default.

Thank you.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
You can already halt all CTCP commands including version.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2011
Posts: 9
T
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Sep 2011
Posts: 9
AFAIK, it is impossible to stop the CTCP version command.

If you know how to stop it, please post it here - but make sure you test it before you post it here.

Joined: Feb 2003
Posts: 3,432
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Feb 2003
Posts: 3,432
type in any window..

/ignore -tw *!*@*

and if someone with 7000+ posts say it can be done, then it can be done wink dont think he will lie to you about it..

;--- Edit

If you want to know more about ignore..

/help /ignore

you can ignore many other "good to know" things smile

Last edited by sparta; 25/09/11 05:46 PM.

if ($me != tired) { return } | else { echo -a Get a pot of coffee now $+($me,.) }
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
mIRC uses OpenSSL, which supports the "empty fragment" feature (first introduced in 0.9.6d which was released way back in 2002). It is possible to disable this feature however, so we'd have to hear from Khaled whether this feature is left enabled or not.

You can read a little about this feature here: http://www.openssl.org/~bodo/tls-cbc.txt (item number 2)

In short, if the "empty fragment" feature is enabled (which it is by default), then SSL connections created by mIRC would NOT be vulnerable to the BEAST attack.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
It almost sounds as though you have an ulterior motive here; are you sure you're not just using this as an excuse to allow circumvention of the version reply? It should be fairly obvious that mIRC doesn't ALWAYS display the version, as this would make any client vulnerable to DOS attacks-- forget some new and obscure SSL attack vector.

Also note that VERSION isn't even the only problem here-- CTCP PING allows for arbitrary responses by filling the timestamp parameter with a constant value that is returned by the client. Many clients follow this protocol (all of them do, AFAIK), so this makes pretty much any client vulnerable to BEAST attacks-- mIRC is hardly alone here. You would, of course, plug this hole the same way you would plug the VERSION vector, and the same way in any client, by ignoring CTCPs.

It is clearly possible to ignore CTCPs, and, if you were being flooded with hundreds of requests, Flood control (if enabled through Alt+O -> Flood), or any flood script, should have already kicked in.

I don't think the version reply behaviour needs to change in order to patch this issue. That would be the backhanded way to solve a problem that has nothing to do with CTCP. Upgrading protocols to TLS 1.2 is likely to come soon because of this vulnerability, both from servers and mIRC-- it might take a little longer, but there are also other SSL related fixes that can be applied at the source of the problem.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Sep 2011
Posts: 9
T
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Sep 2011
Posts: 9
I was taking my information from "The Bible" (mirc.chm), where on the page "Ctcp Events" it says "Note: You cannot prevent the standard version reply from being sent."

What I would want is that mIRC does not send any reply from my computer without asking me for permission or giving me the option to disable it by default. Giving an easy to change option to all types of users is a good thing.

CTCP version (and others) can of course be circumvented (hex editing on multiple places, to edit the actual version reply and to edit the check that checks whether it has been tampered with) but that is not the preferable way since it voids warranty.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Okay, so you do have an ulterior motive. This doesn't seem to be about BEAST at all.

mIRC gives you the option to disable it, please read above.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Sep 2011
Posts: 9
T
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Sep 2011
Posts: 9
Originally Posted By: argv0
Okay, so you do have an ulterior motive. This doesn't seem to be about BEAST at all.

To clarify what I meant - I do not wish my mIRC to send unwanted text away from my computer, which is what BEAST can exploit.

Originally Posted By: argv0

mIRC gives you the option to disable it, please read above.

I have read above - what I was referring to is that the official documentation says that it is not possible.

Originally Posted By: sparta
type in any window..
/ignore -tw *!*@*

Thank you sparta, this solves the issue completely. Do you have any other suggestions as to what commands to issue so that mIRC does not send unnecessary replies to anything?

Last edited by theresa33; 25/09/11 07:40 PM.
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: theresa33
The CTCP VERSION command makes the mIRC user send a known plaintext encrypted though SSL which helps the BEAST attack.

This way, if the the attacker (Eve) is between the user (Alice) and the server (Bob) e.g. on the local network, then Eve will be able to decrypt all encrypted communications between Alice and Bob.

If I understand the attack correctly, both these statements are wrong.

First of all, Eve will not be able to decrypt all communication. All Eve will be able to do, is check whether the data immediately preceding the plaintext she injects, is equal what she already had in mind. The BEAST attack bruteforces one byte at a time by repeatedly tesing for this equality against all of the possibly byte values after cleverly manipulating block boundaries. That is: it has to repeat the same attack 256 times on the same input to figure out one byte of that input. In terms of IRC, that makes it useful only for some data that is sent over the IRC connection repeatedly -- possibly for bruteforcing oper or service passwords over time, but not for actual conversation text which is usually sent only once.

This could still be a problem in certain situations, but that brings me to your other claim. It is also not enough to have just any known plaintext be sent, it has to be a piece of plaintext that is completely controlled by the attacker, because the attacker must ensure that her plaintext when XOR'd with the previous two messages' IVs equals what she thinks might be the previous message's plaintext, so that she can test for equality after encrytion. The bottom line? The version reply does not help Eve at all.

Of course it would be much easier to attack the communication from the server to the client rather than the other way around, because in that case Eve need not solicit replies from mIRC and can just stick to sending things to it. But it seems that the linear, ASCII-oriented, command-prefixing IRC protocol makes any attack like the BEAST attack pretty much infeasible by nature anyway.


Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
If CTCP is vulnerable to this issue then many other events on IRC would be as well. Every time you join/part/message a channel or query/message a user, you will be sending known plaintext. So blocking CTCP will make very little difference. All someone has to do is to send you a private a message and then wait for you to reply and they will know that the stream of data contains "PRIVMSG nickname". Or they can just wait for you to join and talk on a channel and they will know that the stream of data contains "JOIN #channel" or "PRIVMSG #channel". This of course applies equally to all protocols that use known, repeated plaintext, not only IRC.

As mentioned in a previous post, if a client uses OpenSSL's "empty fragment" feature, which is enabled by default in OpenSSL, this mitigates the vulnerability. I have just checked the settings mIRC uses in the SSL_CTX_set_options() command, which a client can use to change the way OpenSSL behaves. mIRC uses the recommended SSL_OP_ALL option which includes SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS. Many applications use SSL_OP_ALL for compatibility reasons to ensure that a client can connect to different SSL server implementations.

I could remove the SSL_OP_ALL option from the next version of mIRC but this could result in it no longer being able to connect to some SSL servers. I would guess that most public IRC servers use OpenSSL, so they should not be affected. However mIRC is used by many different types of users and organizations, some of whom may use SSL server implementations that cannot handle the "empty fragment" feature.

That said, I have been reading through a large number of sites that discuss the BEAST exploit, which is browser-based, uses java/javascript, and seems to require a combination of other technologies (see here for a technical explanation) and I honestly can't tell whether it can be extended to IRC. There is a lot going on there.

Does anyone actually know whether the exploit extends to secure IRC connections? ie. connections other than the specific exploit context that BEAST uses?

Joined: Sep 2011
Posts: 9
T
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
T
Joined: Sep 2011
Posts: 9
Would it be possible to make it user configurable whether mIRC uses SSL_OP_ALL or not? That way, users who use standard compliant IRC servers would have more protection, and those who use other servers would still be able to connect to them.

Even if SSL_OP_ALL were no longer issued for anyone, which is more secure, there is nothing forcing users with non-standards-compliant servers to upgrade to a newer version of mIRC - just like with UTF-8.

Last edited by theresa33; 26/09/11 01:23 PM.
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
This is all a storm in a teacup as far as I can tell. Besides being a MITM the attacker also needs to be able to control a message going out of either the client or server precisely and in its entirety. It's not enough to simply know what mIRC (or the server) is sending and when, it needs to be able to tell mIRC/server exactly what to send. As Sat said, in a protocol like IRC this just isn't feasible. The IRC server obviously requires that parts of the message be valid in both format and content that would be impossible for the attacker to maintain (we're talking about XOR'ing encrypted data with a regular IRC message and having the result still be a valid IRC message that the server will accept and deliver to the correct recipient [the attackee]).

In short neither the original TLS 1.0 attack nor the improved "BEAST" attack pose any legitimate threat to secure IRC connections.

Note that I'm saying all this on the basis of the attack as described in the link you provided. I haven't read any of the original papers.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I have been following the discussions on this topic on the Mozilla/Chrome development blogs/bugtrackers. The solutions they are implementing are similar to but not identical to the OpenSSL solution. Unfortunately, it looks like they are seeing compatibility issues with some SSL servers, just like the OpenSSL solution, so we will need to see what solution they finally settle on.

In any case, it looks like the BEAST exploit only applies to web browsers in a very specific context, so it does not seem to be applicable to secure IRC connections. That said, I will start testing mIRC with the SSL_OP_ALL removed and will release a public beta at some point for wider testing to ensure that this change doesn't have any other side-effects.


Link Copied to Clipboard