Research :: Summary :: IRC3 :: Utilities :: Security
                            
                            Advisory 001 - mIRC Current Nickname overflow
Discovery
                            eSDee discovered the overflow in the "001" message
                            James Martin (uuuppz) discovered the "NICK" message overflow and researched the exploit of the two related bugs
                            Vulnerable
                            mIRC V5.91, V5.9 and all tested prior versions. This problem goes back a long way
                            Impact
                            High. This allows arbitary code to be executed on the victim's machine. Coupled with the issue detailed above (it requires the user to connect to a server) it is VERY exploitable.
                            Details
                            mIRC assumes the current nickname of the client as sent by the server is fewer than 100 characters long. mIRC stores the current and alternative nickname as a static array. Sending a nickname over 200 characters long allows overwriting of a key variable, the index to the current nickname.
                            The C code look something like this
                            
char nicks[2][100];
int  currentnick;
//blah blah
void setnick(char *newnick) {
  strcpy(nicks[currentnick], newnick);
} 
As you can overwrite currentnick, you can cause the strcpy to write to anywhere in memory to an 100 byte precision. And as mIRC allows us to send nearly 1000 bytes into the buffer, that's quite a lot of space to exploit.
                            The attacker does the following:
                            
                              - Gets the victim to connect to their server
- Sends a message changing the nick of the victim to a nick overwriting currentnick, to make it point to the stack.
- Sends a message changing the nick of the victim, this time overwriting EIP on the stack.
The attacker includes the shell code in either of the messages.
                            There are two ways I currently know of overflowing this buffer, the first is to send:
                            NICK oldnick longlongnewnick
But this has the problem that once it has been issued and currentnick made to point to the stack the current nickname is unknown. The way to solve this would be to kill the connection, let mIRC automatically reconnect then fire the exploit (mIRC would send you the nickname). But this would rely on autoreconnect. There may be another clever solution but I don't know it yet!
                            This method was discovered by me on the 24th of October 2001.
                            The other method was discovered by esDee of Hoepelkoe unfortuantly I cannot find contact details for him. The website they had has gone down. It was published on the 23rd of October (irconically!). However he did not think it was exploitable. To trigger this method send the following:
                            :anything 001 longlongnick :anything
This method is great! It can be repeated and each time mIRC will write to the nickbuffer, or where it thinks the nickbuffer is :P.
                            Mitigating factors
                            
                              - mIRC has to be connected to the exploiting server. However the irc:// vulnerability pretty much cancels this.
- The location of the stack varies throughout each Windows version. However if the irc:// vulnerability was being used, Internet Explorer at least sends the Windows version as a header!
- The victim's version of mIRC must be known to be successful, this could be obtained by issuing a CTCP version
Exploit
                            Proof of concept exploit is available to download here. Only works with version 5.91, the latest.
                            Vendor Response
                            Vendor was notified as to the existence of this issue on 24/10/2001. Was notified of the exploit on 15/12/2001.
                            mIRC 6.0 fixes this issue and is available from http://www.mirc.com
                            Solution
                            Download mIRC 6.0 from http://www.mirc.com
                            mIRC irc:// handling vulnerability
Discovery
                            James Martin (uuuppz)
                            Vunerable
                            mIRC V5.91, V5.9. Probably many many versions prior to this.
                            Only tested with Internet Explorer.
                            Impact
                            Low to high. It is not in itself dangerous from what I can see but it makes exploitation of server-side vulnerabilities much easier.
                            Description
                            An HTML page can cause mIRC to automatically launch. This includes HTML e-mail when read from within Outlook Express. Under some circurmstances mIRC will automatically connect to the server specified within the HTML page, other times mIRC will ask if the user wishes to open another copy of mIRC or use the current one.
                            Details
                            Just insert the following code into an HTML page or HTML e-mail.
                            
Exploit
                            Not really an exploit, just a demonstration
                            Click Here
                            Vendor Response
                            Vendor was notified as to the existence of this issue on 24/10/2001. And again during December 2001.
                            The vendor considers this to be an issue with Internet Explorer and Outlook Express. While to a large extent I agree, I also think that an option to disable this feature automatically would be a big improvement.
                            Solution
                            This is none currently.