[10768] in bugtraq
mIRC 5.6 automatic URL loading
daemon@ATHENA.MIT.EDU (Rich Lafferty)
Wed Jun 9 14:56:37 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <19990608224935.A22938@alcor.concordia.ca>
Date: Tue, 8 Jun 1999 22:49:35 -0400
Reply-To: Rich Lafferty <rich@ALCOR.CONCORDIA.CA>
From: Rich Lafferty <rich@ALCOR.CONCORDIA.CA>
To: BUGTRAQ@NETSPACE.ORG
[This one stunned me. I triple-checked and tested more than I'd
usually test because I can't believe anyone would implement something
so ridiculous. Perhaps I'm just optimistic. Anyhow, moving on:]
\begin{vulnerability}
About a week ago, mIRC 5.6 was released. Amongst other new features,
it includes the following (from the changelog, versions.txt):
40.Added "Track Urls" switch to System menu in Channel/Query windows,
auto-opens websites as they are mentioned in a window.
With the cooperation of an mIRC user (thanks Lindy_!), I found that it
does exactly as it says -- when it's enabled, mIRC happily tells
Netscape (and presumably IE, if that's the Default Browser) to open
any URLs that it sees.
Now, I don't actively pay attention to the various Windows-browser
exploits that appear here, so I suspect the diligent bugtraq reader
will come up with ickier things to do with this than I, but just off
the top of my head:
* linking to /dev/zero and letting the mIRC user's hard drive fill
* Banners, banners, banners.
* Trojan or virus-infected things, especially if the browser
autoexecutes them.
* http://some.host.name:19/
* flood an IRC channel with URLs, causing the browser to try to
load them up sequentially
Anyhow, wide open. Whatever you can put in a URL, mIRC will devotedly
tell your default browser to load up.
\end{vulnerability}
\begin{soapbox}
It's basically reached the point now where any release of mIRC which
isn't a patchlevel increment contains a significant vulnerability,
which is then patched in a patchlevel-increment release between a week
and a month later. That is, 5.5's dcc-server bug brought a quick 5.51,
5.4's $calc bug, 5.3 and hanson.c, and 5.2's "mIRC worm", which takes
us back to the beginning of the bugtraq archive on geek-girl.com.
Looking at versions.txt, it seems that nearly every mIRC release x.x
has been followed up by an x.x1 or x.x2 bugfix within a few weeks of
its release all the way back to 3.92. (Prior to 3.92, the release
schedule seemed to be characteristic of known-beta-quality software; I
recall 3.92 being basically when mIRC hit the "big time", too.)
Obviously, these non-bugfix releases are being consistently released
prematurely. Just take a look at the release dates at
http://www.mircscripts.com/old/ -- something is *certainly* awry.
mIRC is beta-tested by a small, closed group. It's also the most
popular IRC client in the world. History seems to indicate that
whatever testing takes place isn't anywhere near sufficient. Users
are conditioned to rush for the newest release as soon as it's
available. Perhaps the rush to get that release out is being
prioritized, intentionally or accidentally, over making sure that
the program is reasonably secure?
Certainly, no-one's reviewing code; it seems that they're not even
thinking through the implementations of newly-introduced
*concepts*. Perhaps it's time to revise the testing procedures --
drastically, even? -- to catch these problems before letting them
loose on the huge, dedicated userbase?
\end{soapbox}
-Rich
--
Rich Lafferty ---------------------------------------------------------
IITS/Computing Services | "How should I know if it works? That's what
Concordia University | beta testers are for. I only coded it" -LT
rich@alcor.concordia.ca ----------------------------------------[McQ]--
