mIRC v5.91 and below has an exploitable bug which allows remote code execution. 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. Fix available here.
7be119c91ef0d3642fc205b923d39056b40a51bb3e468568211d9c3586fdc091<html>
<style>
<!--body,td,a,p,.h{font-family:arial,sans-serif;} .h{font-size: 20px;} .h{color:} .q{text-decoration:none; color:#0000cc;}//-->
</style>
<STYLE type=text/css>
A {TEXT-DECORATION: none}
BODY {FONT-FAMILY: arial,sans-serif}
TD {FONT-FAMILY: arial,sans-serif}
A {FONT-FAMILY: arial,sans-serif}
P {FONT-FAMILY: arial,sans-serif}
.h {FONT-FAMILY: arial,sans-serif}
.h {FONT-SIZE: 20px}
.h {}
.q {COLOR: #0000cc; TEXT-DECORATION: none}
</STYLE>
<head>
<title>Research - www.uuuppz.com (security)</title>
</head>
<body>
<center>
<TABLE width=520 bgColor=#9599b9 border=0><TBODY>
<TR><TD width=520><FONT face=arial color=#ffffff size=6>
<CENTER>U . U .
U . P . P
. Z <P>
<CENTER></FONT></TD></TR></TBODY></TABLE>
<TABLE width=520 bgColor=#9599b9 border=0><TBODY>
<TR>
<TD width=104><P align=center><A href="../index.htm"><FONT face=Arial color=#ffffff size=2>
INTRODUCTION</A></FONT></P></TD>
<TD width=104 bgColor=#ffffff><P align=center><A href="../consult/index.htm">
<FONT face=Arial color=#9599b9 size=2>CONSULTING</A></FONT></P></TD>
<TD width=104><P align=center><A href="../research/index.htm"><FONT face=Arial color=#000000 size=2>
RESEARCH</A></FONT></P></TD>
<TD width=104 bgColor=#ffffff><P align=center><A href="../cv.htm"><FONT face=Arial color=#9599b9 size=2>
CV</A></FONT></P></TD>
<TD width=104><P align=center><A href="../credits.htm"><FONT face=Arial color=#ffffff size=2>
CREDITS</A></FONT></P></TD></TR></TBODY></TABLE>
<TABLE width=520 border=0 bgcolor=#95b999><TBODY>
<tr>
<td width="130"><center><a href = "index.htm"><font face=Arial size=1 color="#ffffff">SUMMARY</font></a></center></td>
<td width="130" bgcolor="#FFFFFF"><center><a href = "nextgenirc.htm"><font face=Arial size=1 color="#95b999">IRC3</font></a></center></td>
<td width="130"><center><a href = "utils.htm"><font face=Arial size=1 color="#ffffff">UTILITIES</font></a></center></td>
<td width="130" bgcolor="#FFFFFF"><center><a href = "adv-001-mirc.htm"><font face=Arial size=1 color="#000000">SECURITY</font></a></center></td>
</tr></tbody></table>
<TABLE width=520 border=0><TBODY>
<TR><td>
<FONT color=#800000>
 <p><h3>Security</h3>
<h4>mIRC Nickname buffer overflow</h4>
<font size="-1">
<b>Discovery</b><br>
eSDee discovered the overflow in the "001" message<br>
James Martin (uuuppz) discovered the "NICK" message overflow
and researched the exploit of the two related bugs<p>
<b>Vunerable</b><br>
mIRC V5.91, V5.9 and all tested prior versions. This problem goes back a
long way<p>
<b>Impact</b><br>
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.<p>
<b>Details</b><br>
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.<br>
The C code look something like this
<pre>
char nicks[2][100];
int currentnick;
//blah blah
void setnick(char *newnick) {
strcpy(nicks[currentnick], newnick);
} </pre>
As you can overwrite <i>currentnick</i>, you can cause the <i>strcpy</i> 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.<p>
The attacker does the following:
<ul>
<li>Gets the victim to connect to their server</li>
<li>Sends a message changing the nick of the victim to a nick
overwriting <i>currentnick</i>, to make it point to the stack.</li>
<li>Sends a message changing the nick of the victim, this time overwriting
EIP on the stack.</li>
</ul><p>
The attacker includes the shell code in either of the messages.<br>
There are two ways I currently know of overflowing this buffer, the first
is to send:<pre>NICK oldnick longlongnewnick</pre>
But this has the problem that once it has been issued and <i>currentnick</i> 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!<p>
This method was discovered by me on the 24<sup>th</sup> of October 2001.<p>
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 23<sup>rd</sup> of October (irconically!).
However he did not think it was exploitable.
To trigger this method send the following: <pre>:anything 001 longlongnick :anything</pre>
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.<p>
<b>Mitigating factors</b>
<ul>
<li>mIRC has to be connected to the exploiting server. However the irc:// vulnerability pretty much cancels this.</li>
<li>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!</li>
<li>The victim's version of mIRC must be known to be successful, this could be obtained by issuing a
CTCP version</li>
</ul>
<p>
<b>Exploit</b><br>
Proof of concept exploit is available to download <a href="mircexploit-v591.c">here</a>.
Only works with version 5.91, the latest.<p>
<b>Vendor Response</b><br>
Vendor was notified as to the existence of this issue on 24/10/2001. Was notified of the exploit
on 15/12/2001.<br>
mIRC 6.0 fixes this issue and is available from <a href="https://www.mirc.com">https://www.mirc.com</a><p>
<b>Solution</b><br>
Currently none.
</font>
<h4>mIRC irc:// handling vulnerability</h4>
<font size="-1">
<b>Discovery</b><br>
James Martin (uuuppz)<p>
<b>Vunerable</b><br>
mIRC V5.91, V5.9. Probably many many versions prior to this.<br>
Only tested with Internet Explorer.<p>
<b>Impact</b><br>
Low to high. It is not in itself dangerous from what I can see
but it makes exploitation of server-side vulnerabilities much easier.<p>
<b>Description</b><br>
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.<p>
<b>Details</b><br>
Just insert the following code into an HTML page or HTML e-mail.
<pre>
<iframe src="irc://irc.hackme.com:6666"></pre>
<b>Exploit</b><br>
Not really an exploit, just a demonstration<br>
<a href="mircdemo.htm">Click Here</a><p>
<b>Vendor Response</b><br>
Vendor was notified as to the existence of this issue on 24/10/2001. And again
during December 2001.<br>
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.<p>
<b>Solution</b><br>
This is none currently.<p> <p>
</font>
<p> <p><font size="-2">Hosting provided by <a href="https://www.biznet-solutions.com">BizNet Solutions</a>. Powered by <a href="https://www.debian.org">Debian.</a><p></font>
</td></tr>
</table>
</center>
</body>
</html>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed