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
Vunerable
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
Currently none.
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.
<iframe src="irc://irc.hackme.com:6666">
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.