August 25, 1998
Microsoft, Netscape, Qualcomm, and Sun,
Over the past couple of years there has been the move
to use HTML in Email messages. HTML provides both graphics
and rich text in Email messages. HTML rendering of Email
messages basically comes for "free" by using a Web browser
to display HTML Email messages.
However, the rapid move to HTML Email has created many
new security and privacy problems. Most of these problems
are due to the fact that most HTML Email readers automatically
execute JavaScript programs, Java applets, and ActiveX embedded
in Email messages.
In this message I have outlined nineteen different security problems
that I have seen or believe exist in Outlook Express, Netscape
Messenger, and Eudora. I hope by bringing these problems to
light that they can be fixed in short order. I am sending
the problem descriptions to all four vendors because many of the
security holes are the result of interaction between different
software products (Email readers, Browsers, JVM's, and ActiveX
controls).
The Email security holes I found run the gamut of simply being
annoying to the ability to silently steal files from a user's
hard drive.
I worked with the following Email software packages:
OE Microsoft's Outlook Express, version 4.71.1712.1
NSM Netscape Messenger, version 4.05
EUD4 Eudora, version 4.0
EUD402 Eudora, version 4.02
For Web Browsers, I used:
IE4 Microsoft's Internet Explorer 4
NAV Netscape Navigator, version 4.05
All products were tested running under Windows 95.
Here is a list of security problems that I have identified:
1. In both OE and EUD402, an HTML page attached to an
Email message can be used to steal private files on
the hard disk and send them out as an Email message.
The security hole requires IE4 to be the default Web browser.
The HTML page attachment must be clicked on by a user to activate
the security hole. EUD402 immediate executes the HTML page.
OE does bring up a security dialog pointed out that
the file might be dangerous. However almost no one
considers HTML pages to be dangerous and still may
display the page. Also OE can be configured to never
warn about HTML files.
The security hole is created by the TDC ActiveX
control which is automatically installed with the Internet
Explorer 4 browser. It can be easily tricked into reading
any text file from the hard disk into a JavaScript variable.
Once JavaScript has the file contents, the text can be silently
sent as an Email message or posted as a newsgroup
message. Descriptions on how JavaScript can send Email or
post a newsgroup message are given below.
In EUD4, this same security hole can be exploited in the HTML
Email message itself and automatically executed when a message is
read.
2. In OE, EUD, and EUD402, an HTML page attached to an Email
message can get a listing of any directory on the hard disk.
This security hole requires Netscape Navigator to be
the default browser for HTML pages. This security hole
uses JavaScript to do the snooping. Like the previous
hack, the directory listing can be sent out as Email message
or posted to a newsgroup.
3. In EUD4 and EUD402, an HTML page and Java applet can be used to
steal the contents of private files in the Eudora attach
directory. The security hole exists if either IE4
and NAV is the default browser for Web pages.
This security hole requires a user to click on the
attached HTML file.
This security hole exists because a Java applet sent
with an Email message is placed into the Eudora attach
directory along with the attached HTML file. The HTML
page can run the run the applet from the attach directory
where it is allowed to do disk I/O because it is loaded from
the hard disk and not a Web site.
4. In OE, NSM, and EUD4, a JavaScript program embedded
in an Email message can automatically send out
another Email message. The JavaScript program
has complete control of the message subject line
and message contents. The trick is to have a hidden
form embedded in the message and JavaScript code
which does an auto-submit on the form. The form
is sent to a feedback page on a Web site. The
CGI scripts for many feedback pages convert the form contents
to an Email message. The destination Email address
is regularity stored in the form as a hidden field.
A JavaScript program can set this hidden field to
any value. There literally ten's of thousands of
Web sites which can be used to send Email with
this technique.
5. In OE, NSM, and EUD4, a JavaScript program embedded
Email message can automatically post a message to
a USENET newsgroup. The JavaScript program has
complete control over the return Email address,
subject line, and message text of the newsgroup
message. The security hole exists because a
hidden form can be created in an Email message
and JavaScript can auto-submit the form to a Web-to-news
gateway.
This security hole can be used to post private files
to a newsgroup or to put embarrassing or inflammatory
messages in a newsgroups.
6. In OE, NSM, and EUD4, the same security hole can be
used to send threatening messages to the feedback page
at US White House:
http://www.whitehouse.gov/WH/Mail/html/Mail_President.html
Web site server logs will give the IP address of the victim's
computer allowing for easy tracing of the threat. Proving
that it was an Email message that sent the threat and not
the victim, will be very difficult to explain to the US Secret
Service agents that coming knock at the door.
7. In OE and NSM, HTML newsgroup messages can contain embedded
JavaScript code which tracks who has read a newsgroup message.
This information can be silently Emailed back to someone else
or posted to a newsgroup. This security hole means that reading
newsgroup messages is no longer private. Non-HTML based news
readers do not have this problem.
8. The hostile Java applet at http://users.tmok.com/~dr_bulge/smt1/
can be embedded in an HTML Email message. In OE, NSM, and EUD4,
this applet can automatically executed with an HTML <applet>
tag and crashes Windows 95 by spawning an infinite number of
threads. Besides being annoying, this applet has the potential
for corrupting files on the hard drive if another application
is doing disk I/O while Windows 95 is crashing.
Also in NSM and EUD4, if the preview pane is turned on,
the applet is rerun everytime the Email reader is started
up again. Basically Email becomes unusable until the malicious
message is manually deleted from the Email reader "in" box
file. Fixing a broken mailbox file takes a
very technically astute user or system administrator.
9. In OE and EUD4, the NetShow ActiveX control embedded in an
Email message will automatically crash Windows 95 if the
control is instructed to play a movie from the DOS "AUX"
device. Apparently the Windows 95 AUX device
driver is buggy and crashes the operating system if it
is ever accessed. This bug presents the same danger
as the hostile Java applet in that file system corruption
is possible if disk I/O is being done as the operating
system is crashing.
10. The following HTML Email message will hang OE, NSM, and
EUD4 when it is read:
<html>
<script>
while(1) alert("Boom!");
</script>
</html>
Even though this is a rather silly bug, it becomes
a larger problem if the "bad guys" were to use a
bulk Emailer to send out millions of copies of the
message. For a $100 investment and an Internet
connection, anyone could Email Letter Bomb millions of
people all over the world in the less than 24 hours.
This Email message also will permanently lock up
NSM and EUD4 if the preview pane is turned on.
11. In OE and EUD4, the following JavaScript will create a
"White Screen of Death":
<html>
<head>
</head>
<body>
<script>
mywin = window.open("", "fullwin",
"fullscreen=yes location=no menubar=no " +
"resizable=no scrollbars=no toolbar=no");
</script>
</body>
</html>
This security hole is quite harmless, but pretty scarey when
it happens. The screen goes complete white except for
a disabled scroll bar on the right hand of the screen.
There is no close box to shutdown the page or any
explanation of what has gone wrong.
12. People thought that Email spam was bad. SuperSpam(tm)
is even worse. This HTML Email message illustrates
the problem in OE, NSM, and EUD4:
<html>
<script>
mywin = window.open("ht" + "tp://www.ronco.com/products/glh/",
"fullwin",
"fullscreen=yes location=no menubar=no " +
"resizable=no scrollbars=no toolbar=no");
</script>
</html>
In IE4, SuperSpam is quite obnoxious because there is no
apparent way of getting rid of it.
13. In both EUD4 and OE, a JavaScript program can be used to
"bully" someone into running an unsafe ActiveX control.
The unsafe ActiveX control to be executed is referenced
by a Web page that is downloaded from a Web site.
The bullying is done by a JavaScript program in the Web page.
When the Web page is downloaded, IE4 will bring up a security
warning saying that there is unsafe ActiveX control on the
Web page. If the answer is to not run the control,
JavaScript on the page detects this choice and reloads the page.
The reload causes the security warning to be again presented
to the user. The bullying code will continue to reload
the page until the user answers "Yes". Once the user
answers "Yes", the ActiveX control has free run of the
user's computer. Two especially dangerous controls are
Microsoft's FileSystemObject control which allows file I/O and
the WSH shell control which allows Windows programs to be
executed. These two controls are installed with the
Windows Scripting Host in Windows 95. I believe the controls
are installed by default in Windows 98.
The "bullying" Web page can be automatically executed
by a simple embedded JavaScript program in an Email
message.
The correct way for the user to deal with this problem is
to shutdown the IE4 browser by doing an "End Task" after
doing a CTRL-ALT-DEL. However, this is only an option
if user is technically savvy. I haven't tested this
yet, but the CTRL-ALT-DEL solution may not work. What
might be possible for the JavaScript in the Email message
to notice that the Web page window has been closed, and simply
open it again.
Ironically, I learned about this bully technique from
http://www.msnbc.com. This site contains some sort of ActiveX
news control. I tried to refuse it, but everytime
I go to another page on the site, the control is downloaded
yet again and I asked once more if I want the control or not.
This behavior seems to me to be a very big flaw in
the Authenticode system. It is not really possible to
refuse an ActiveX control with the current design
of Authenticode.
The following problems may also exist, but I haven't had the
time to investigate them yet:
14. In OE and EUD4, Microsoft Word .DOC files are marked
as safe for downloading. This means that a JavaScript
program embedded an Email message can auto-launch a .DOC file
when the message is read. Doesn't this feature create
the possibility of automatically spreading macro viruses
via Email messages?
15. In OE, NSM, and EUD4, JavaScript embedded in an Email
message can access HTML files on a Web server that is
running on the same machine as the Email reader. All
that is required is to ask for pages at http://localhost domain.
If the "bad guys" know what Web server is running on
the local system, they can send commands to Web server
via URL's to open up the entire hard disk for remote
viewing. This would be possible if the Web server is
configured from a Web browser. In particular, this problem
may exist with the Microsoft Personal Web Server that
ships with FrontPage 98 and Windows 98.
16. In EUD4 it might be possible for embedded JavaScript
to automatically execute a Java applet in the Eudora
attach directory that fills up the hard disk with garbage.
Windows 95 and Windows application become unstable and
crash easily when there is less than a few megabytes
of free disk space remaining. This problem may exist
in both the IE4 and NAV browsers.
17. All security settings for Windows 95 are stored in
plain sight in the registry. A very simple .REG file
could be built which turns off all security checking
by IE4 and OE. If this .REG file can be run by
malicious code, then the system is total vulnerable
to future attacks without any security warnings
in place. More worrisome is the fact that settings
for the "My Computer" zone do not appear in the
Windows Internet Security panel. Therefore a
user would never even notice there is a problem
with security settings in this zone and there is no way
to fix the problem short of running REGEDIT.
It should also be possible to turn off security
checking by changing registry settings from a Word
or Excel VBA macro or from a WSH script.
18. The bullying technique present with Authenticode, may also
work with in NAV with the Java function
netscape.security.PrivilegeManager.enablePrivilege().
The bullying tactic could allow a malicious HTML
page attached to a EMAIL message to gain access
to a user's hard drive to read and write files and to
run programs. This security hole would exist in
OE, EUD4, and EUD402.
19. A simple form of financial fraud is possible with
HTML Email messages in OE, EUD4, EUD402, and NSM.
The crooks create an Email message which looks
like an order form for Amazon.com. The pitch is
to purchase a book from a best selling author. The
book is about to be released and the Email message
offers the book at a substantial discount.
The Email message includes an order form where
a victim types in their name, address, and
credit card number. However, when the submit
button is pushed, the order doesn't go to Amazon.com
but instead is sent off to the bad guys. Unlike
with a Web site, an unsolicted Email message has
absolutely no assurances that the order is will
go to the right place in spite of the nice logo's
on the Email message.
Many of these securities problems have straight-forward
fixes for them. Here are my suggestions:
- All Email readers need to have an option for turning off
automatic execution of embedded JavaScript programs,
Java applets, and ActiveX controls. These options
need to be separate from the Web browser settings.
My strong recommendation is that automatic execution
of programs in Email messages is turned off by default
regardless of the claims for safety of JavaScript,
Java, and ActiveX.
In version 4.02 of Eudora, this change has already
been made. I think its important for all other HTML
Email readers to offer the same option for users.
- Form submits in Email messages should either not be
allowed or should always warn that data is being
uploaded to a Web site. The warning needs to give
the name of the Web site where the data is going to.
On the server-side of things, Web servers should reject
any form submits from Web pages that weren't downloaded
from the site. Maybe Web browsers should also
enforce this rule. That is, the domain of form action
must match the domain of the HTML page that is doing
the submit.
- Netscape and Microsoft need a method for other vendors
to be able to mark disk-based HTML pages and Java applets as
being unsafe when they are viewed in NAV or IE4. This
functionality is already present in both browsers, but
my understanding is not been brought for other vendors to
use. NAV has the concept of the mailbox: domain
while IE4 can put disk files in the Internet zone.
- ActiveX controls which are marked as trusted
should never be allowed to access disk files.
It is just too easy for JavaScript to make them
do bad things.
- Fix Authenticode so it doesn't keep asking me if I
want the same control over and over again. Authenticode
doesn't seem to understand the meaning of the word "No".
- There should be some simple method of stopping the
execution of a JavaScript program. The current
requirement of using CTRL-ALT-DEL is much to difficult
for most users to be able to use.
If anyone has further questions, I will be happy to provide
more details of the problems and working examples.
Richard M. Smith