For the sake of historic justice, I have to mention that first publication, extensively covering the dangers of HTML-capable email clients, was in my Internet column, Evening Internet, on December 29, 1997.

The column runs in Russian, therefore it wasn't noticed abroad, but locally it received an extensive coverage, including articles in MK daily (circulation ~1M copies), Izvestia, and Moscow computer press. A local MS representative gave an official response to those issues (dated Jan 13, 1998), which was also in Russian.

But the historical aspects are not essential here. This story needs to be publicised widely, since it requires amendment to all HTML-capable email clients on the market, especially Netscape Messenger, Microsoft Outlook, and Eudora Pro 4.0.

Now to specifics:

The dangers of mandatory HTML tag support in email clients fall into two categories:

• Those you can avoid by turning some browser features off
• Those you can not avoid, without giving up your email client completely

All exploits of JavaScript (infinite window creation, calls to remote sites, etc) can be disabled by simply turning JavaScript off in your browser. An MS representative in his response pointed to this opportunity citing it as a universal remedy.

But email exploits, based on HTML commands, such as IMG and META Refresh can not be disabled in any browser known to humanity.

The IMG tag is good for:

1. Overloading targeted networks and local computers with traffic and data. You include something like <IMG SRC="http://www.nasa.gov/3Mbyte-heavy image.jpg" WIDTH=1 HEIGHT=1>, ten times in a row, mail this letter to all clients of one specific provider -- and his bandwidth is noticeably reduced

2. Spamming people with banner ads. Opening an email causes an ad to load, generating a "view," for which a banner exchange network (or the advertiser) is supposed to pay cash.

The redirect technique is also good both for hacking and spamming purposes:

1. You can redirect any Netscape or Explorer user to a site, where any sort of ping attack is exploited (LAND, IP Fragmentation, OOB, NUKE, you name it). Browser security is highly irrelevant in this case, since the attacker only needs to obtain an IP of its target via REMOTE_ADDR variable, to send the deadly data.

2. Instead of spamming people with invitations to visit a specific page, you can send out a ton of REFRESH invitations, that can not be ignored and refused, once opened.

Special points to take into consideration:

1. If a message contains harmful HTML code, you can not even delete it. To delete you have to select it, and once you select, the commands within this message are processed for execution once again.

2. The difference between email and WWW sites renders the entire Microsoft "trusted/untrusted address" ideology futile. When you direct your browser to www.microsoft.com, you may or may not trust this site. But receiving a message with admin@microsoft.com in its header, you cannot judge its authenticity before opening it.

3. Microsoft knows all about this threat, and has known since at least spring 1996. There is one simple experiment that proves their full awareness of this effect:
   • open MS Outlook Express
   • open Inbox, open the last message
   • press Reset

   The next time you start Windows 95/98/NT and open this same message in MS Outlook Express, a warning is displayed in red letters. This warning says that the system crashed when this message was last opened. Therefore the message will not be displayed, just in case it was the effective reason of the crash.

   Admitting to such a possibility, it's strange that Microsoft avoids really warning people, or providing means to disable automatic HTML support in its Outlook Express mail client.

4. There is one way to confront all threats associated with the above exploits. Just close the message preview panel, and use View Message Source for reading whatever you've selected. This is an alternative -- a rather clumsy, but inevitable one -- to the "disable HTML support in messages" command, which is absent in all HTML-capable clients these days.

The first JavaScript exploit of HTML mail capabilities was developed by Andrew Maltsev in December 1997. Dmitry Touretsky, publisher of SOFT Weekly Digest in Russian (a bulletin like TBTF, but leaning heavily on particular 32-bit Windoze programs) has published a special report on HTML and other email threats, late in January this year. Says Dmitry in a personal letter to yours truly:

Wherever I happened to work as an Intranet security advisor, I kept warning managers from installing HTML-capable email software, since it was first introduced. IMHO, those risks are quite obvious to anyone familiar with HTML.

I hope this clarification is useful, regarding the extent of the email HTML treat and the available means of its avoidance.

With best regards - Dr. Anton Nossik <anton at cityline dot ru> http://www.cityline.ru/vi/current.htm