Thanks to
Laura
Pearlman, who contributed many of the Q&A's in this
section.
This message indicates that the contents of a form that you're
submitting to a CGI script is not encrypted and could be intercepted.
Right now you'll get this message whenever you submit a form
to any non-Netscape server, since only the Netsite Commerce
Server can handle encrypted forms. You probably shouldn't
send sensitive information such as credit card numbers via
unencrypted forms (however if you're the type who reads his
credit card number over cellular phones, an even more insecure
means of communication, go right ahead!).
To turn this warning off, select Preferences from Netscape's
Options menu, choose "Images and Security", and uncheck
the checkbox labeled "Warn before submitting forms insecurely."
Q2:
How secure is the encryption used by SSL?
SSL uses public-key encryption to exchange a session key between
the client and server; this session key is used to encrypt
the http transaction (both request and response). Each transaction
uses a different session key so that if someone manages to
decrypt a transaction, that does not mean that they've found
the server's secret key; if they want to decrypt another transaction,
they'll need to spend as much time and effort on the second
transaction as they did on the first.
Netscape servers and browsers do encryption using either
a 40-bit secret key or a 128-bit secret key. Many people
feel that using a 40-bit key is insecure because it's vulnerable
to a "brute force" attack (trying each of the 2^40 possible
keys until you find the one that decrypts the message).
This was in fact demonstrated in 1995 when a French researcher
used a network of workstations to crack a 40-bit encrypted
message in a little over a week. It is thought that with
specialized hardware, 40-bit messages can be cracked in
minutes to hours. Using a 128-bit key eliminates this problem
because there are 2^128 instead of 2^40 possible keys. To
crack a message encrypted with such a key by brute force
would take significantly longer than the age of the universe
using conventional technology. Unfortunately, many Netscape
users have browsers that support only 40-bit secret keys.
This is because of legal restrictions on the encryption
software that can be exported from the United States.
In Netscape versions 3.X and earlier you can tell what
kind of encryption is in use for a particular document by
looking at the "document" information" screen accessible
from the file menu. The little key in the lower left-hand
corner of the Netscape window also indicates this information.
A solid key with three teeth means 128-bit encryption, a
solid key with two teeth means 40-bit encryption, and a
broken key means no encryption. Even if your browser supports
128-bit encryption, it may use 40-bit encryption when talking
to older servers or to servers outside the U.S. and Canada.
In Netscape versions 4.X and higher, click on the "Security"
button to determine whether the current page is encrypted,
and, if so, what level of encryption is in use.
In Microsoft Internet Explorer, a solid padlock will appear
on the bottom right of the screen when encryption is in
use. To determine whether 40-bit or 128-bit encryption is
in effect, open the document information page using File->Properties.
This will indicate whether "weak" or "strong" encryption
is in use.
Chosen Ciphertext Attacks (June
1998)
In June 1998 researchers at Bell Laboratories discovered a
technically sophisticated attack on the PKCS#1 public key
cryptography standard, a protocol used by the SSL protocol.
This attack allows the session key used to encrypt a single
Web session to be discovered by an attacker by sending approximately
one million carefully constructed messages to the Web server
and observe its responses. If the session key is successfully
compromised, the attacker can then read the contents of a
single Web session (the requested URL and the returned document,
plus any information sent in cookies or fill-out forms). Because
the attack does not compromise the server's private key, the
attack has to repeated for each session the attacker wants
to read. Although the attack requires many trials and may
take a significant length of time to complete, it is far more
efficient than brute-force guessing.
Because the attack requires many messages to be sent to
the Web server, you may be able to detect it by noting an
increase in CPU or memory usage, or unusually high network
activity. In addition, products based on the SSLEay library,
such as C2Net's Stronghold product, will observe a sudden
growth in the SSL error log by approximately 300 MB.
Any SSL-enabled Web server dated earlier than June 1998
should be considered vulnerable to this attack. Patches
are available for the following products:
- C2Net Stronghold
- http://www.c2.net
- Microsoft IIS, Microsoft Exchange
- http://www.microsoft.com/security/bulletins/ms98-002.htm
- Netscape Enterprise, Proxy, Messaging and Collabra Servers
- http://help.netscape.com/products/server/ssldiscovery/index.html
- Open Market secure servers
- http://www.openmarket.com/security
- SSLeay Library
- http://www.ssleay.org/announce/
More information on the problem can be found at the following
sources:
- CERT (http://www.cert.org/advisories/CA-1998-07.html)
- Bell Labs (http://www.bell-labs.com) (pending)
- RSA Data Security (http://www.rsa.com/rsalabs/pubs/PKCS/)
Personal Certificates
Since 1996, the
VeriSign
corporation has been offering "personal certificates"
for use with Microsoft and Netscape browsers. A personal certificate
is a unique digital ID that can be used to identify you to
a Web server and to other users. With a personal certificate,
you can send and receive encrypted e-mail messages using the
S/MIME system, to verify the identity of the person who sent
you an e-mail message, or prove your identity to a Web server.
Personal certificates not widely used on the Web. Their
major use is within corporate intranets, where the possession
of a certificate is used to control access to confidential
information on the corporate Web server. However, many people
think that personal certificates will be used in the not-so-distant
future as legally binding electronic signatures in Internet-based
financial and legal transactions.
How secure are personal certificates? Personal certificates
use public key cryptography to sign and authenticate signatures.
As described in the SSL Q&A,
the security of public key cryptography depends entirely
on the secrecy of the user's private key. When you apply
for a digital certificate, a private key is automatically
generated for you and saved to the hard disk of your computer.
During this generation process, you are prompted for a password,
which will be used to encrypt the private key before saving
it to disk. This precaution lowers the risk that the key
will be intercepted if the computer is compromised either
physically or over the network.
Unfortunately this scheme is not foolproof because the
private key is only as secure as the software that manipulates
it. As described in the sections below, there are numerous
known and potential security holes in browser software.
If one of these holes is exploited to install new software
on your computer or to modify the browser itself, then it
is possible for the software to recover the private key
from memory after it has been decrypted. Once your private
key has been intercepted, it can be used to impersonate
you: to gain access to Web sites, to send S/MIME messages
in your name, or, at some point in the future, to sign binding
legal documents.
In addition to the weaknesses of the software infrastructure,
some security consultants have voiced particular concern
about the security of the cipher system that Microsoft Internet
Explorer uses to encrypt the private key. The issues are
obscure, controversial, and differ from version to version
of IE. Under some circumstances Internet Explorer can be
persuaded to export the private keys using weak 40-bit encryption,
a level of encryption that is known to be vulnerable to
brute-force key guessing attacks. In other cases, the private
key is vulnerable to fast "dictionary" attacks. Full details
can be found in an article written by Peter Gutmann (pgut001@cs.auckland.ac.nz ):
http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt
Cryptography and the Law
The use of cryptography is regulated by a complex web
of national and international laws. In some countries, such
as the United States, it is legal to use strong cryptography
but software that implements it cannot be exported. In other
countries, such as France, it is illegal to use strong cryptography
at all.
The laws are changing rapidly. As I was writing this update
in December 1998, the 33 countries in the Wassenaar Arrangement had agreed to establish
the same cryptography export controls as the United States.
However, it appears that free software, such as SSLEAY, is exempted from these restrictions.
Recently the United States loosened the export restrictions
slightly, allowing Web browsers to be used for strong encryption
when communicating with financial institutions or when an
American-owned company overseas needs to browse its home
office's Web site. Server certificates that allow for these
specific exemptions can be obtained from VeriSign through
its "step-up" program.
More information on the legalities and politics of cryptography
can be found at The
Free Crypto Website.
Q3:
When I try to view a secure page, the browser complains
that the site certificate doesn't match the server and asks
me if I wish to continue. Should I?
The host name of the Web server is an unalterable part of
the site certificate. If the name of the host doesn't match
the name on the certificate, the browser will notice this
fact and alert you of the problem. Sometimes this is merely
an innocent server misconfiguration, but it can also be evidence
that a server certificate has been stolen and is being used
to fool you. In most cases, it's best to abort the transmission.
You may occasionally see a similar message that warns
you that the server's certificate has expired. This may
mean that the Webmaster hasn't renewed the site's certificate
in a timely fashion, or may again indicate that the certificate
has been stolen and is being misused. Again, the safest
course is to abort the transmission.
Q4: When
I try to view a secure page, the browser complains that
it doesn't recognize the authority that signed its certificate
and asks me if I want to continue. Should I?
Web browsers come with a preinstalled list of certifying authorities
that they trust to vouchsafe the identity of Web sites. A
few years ago there was only one certifying authority, the
VeriSign corporation, but now there are dozens. You can view
the certifying authorities that your browser trusts by:
- In Netscape Navigator 1.0-3.02, choosing Options->Security
Preferences->Site Certificates
- In Netscape Navigator 4.X, clicking the Security
icon.
- In Internet Explorer, choosing View->Options->Security->Sites...
The browser will display a scrolling list of CA certificates
-- the master certificates that certifying authorities use
to sign the certificates of individual Web sites. Both the
Netscape and Microsoft browsers allow you to view the contents
of certificates, activate and deactivate them, install new
certificates, and delete old ones.
When a Web site presents your browser with a certificate
signed by some authority, the browser will look up the authority's
signature in its predefined list. If the browser finds the
signature, it will allow the SSL connection to continue.
Otherwise it complains that it doesn't recognize the certifying
authority.
When this happens, the options available to you depend
on the browser you are using. If you are using a Netscape
browser, the software offers you the option of reviewing
the site's certificate and the signature of the certifying
authority. If you decide to proceed, you can recognize the
validity of the certificate, either for this one session,
or for future sessions. If you accept the certificate, it
will be installed in the browser among the CA certificates,
and the SSL connection will be completed. Internet Explorer
does not give you this option. In order to connect to the
site, you will need to obtain a copy of the certifying authority's
certificate and install it. This is discussed below.
Is it safe to accept a site certificate signed by an unknown
certifying authority? If you have an older browser, it is
likely that the certifying authority is legitimate but entered
the business after the browser software was released. Another
real possibility, however, is that the certificate is signed
by a rogue CA -- there's nothing to prevent a site from
obtaining public domain certificate software and creating
its own signed certificates. Never accept a site certificate
blindly. Review it first, and contact the certifying authority
directly (by phone) if you have any questions as to its
legitimacy. If you can't easily determine how to contact
the certifying authority, chances are that it isn't legitimate.
It is possible to install new certifying authorities in
the browser. You do this by opening a URL that points to
the certifying authority's certificate. The browser will
present a warning dialog telling you that you are about
to install a new CA certificate and giving you a chance
to abort. If you proceed, the certificate will be installed
and the CA will appear on the list of trusted authorities.
All sites bearing certificates signed by this CA will now
be trusted to initiate SSL connections.
Because of its security implications, you should be very
careful before installing a new CA certificate. Never accept
a CA certificate unless you know exactly what you are doing
and have a priori evidence that the CA is to be
trusted. For example, many companies are now establishing
internal certifying authorities to sign the certificates
of intranet servers. If your employer gives you a floppy
disk with instructions for installing the certificate contained
within it, you can feel pretty safe accepting the certificate.
If, however, the CA installation dialog ever appears unexpectedly
while you're browsing the Internet, be sure to cancel immediately
and complain to the remote site's Webmaster.
Read
section (2) above. All requests
for documents are logged by the Web server. Although your
name is not usually logged, your IP address and computer's
host name usually is. In addition, some servers also log the
URL you were viewing (such as your home page) at the time
you requested the new URL. If the site is well administered,
the record of your accesses will be used for statistics generation
and debugging only. However, some sites may leave the logs
open for casual viewing by local users at the site or even
use them to create mailing lists.
The contents of queries in forms submitted using the GET
request appear in the server log files because the query
is submitted as part of the URL. However, when a query is
submitted as a POST request (which is often the case when
submitting a fill-out form), the data you submit doesn't
get logged. If you are concerned about the contents of a
keyword search appearing in a public log somewhere, check
whether the search script uses the GET or POST method. The
easiest technique is to try an innocuous query first. If
the contents of the query appear in the URL of the retrieved
document, then they probably appear in the remote server's
logs too.
Server/browser combinations that use data encryption,
such as Netsite/Netscape, encrypt the URL request. Furthermore
the encrypted request, because it is submitted as a POST
request, does not appear in the server logs.
Despite the similarity in names, Java and JavaScript are two
separate entities.
Java
is a language designed by Sun Microsystems. Java scripts are
precompiled into a compact form and stored on the server's
side of the connection. HTML documents refer to the mini-applications
known as Java "applets" by incorporating <APPLET> tags.
Browsers that support the <APPLET> tag (Netscape Navigator
2.0, Microsoft Internet Explorer 3.0 and Sun's HotJava), download
the compiled Java applications and execute them.
JavaScript is a series of extensions to the HTML language
designed by the Netscape Corporation and understood by Netscape
Navigator versions 2.0 and higher, as well as by Microsoft
Internet Explorer version 3.0 and higher (where it is called
"JScript"). It's an interpreted language designed for controlling
the browser; it has the ability to open and close windows,
manipulate form elements, adjust browser settings, and download
and execute Java applets.
Although JavaScript has a similar syntax to Java, it is
quite distinct in many ways.
Java scripts, because they execute on the browser's side of
the connection instead of on the server's, move the security
risk squarely from the server to the client. Is there anything
for the client to worry about?
Several failsafes are built into Java to prevent it from
compromising the remote user's machine. When running as
applets, Java scripts are restricted with respect to what
they are allowed to do by a "security manager" object. The
security manager does not ordinarily allow applets to execute
arbitrary system commands, to load system libraries, or
to open up system device drivers such as disk drives. In
addition, scripts are generally limited to reading and writing
to files in a user-designated directory only (the HotJava
browser allows you to set this directory, while Netscape
disallows all file manipulation).
Applets are also limited in the network connections they
can make: An applet is only allowed to make a network connection
back to the server from which it was downloaded. This is
important for reasons discussed below.
Finally, the security manager allows Java applets to read
and write to the network, read and write to the local disk,
but not both. This limitation was created to reduce the
risk of an Applet spying on the user's private documents
and transmitting the information back to the server. Since
the Netscape implementation disables all local file manipulation
anyway, this restriction is currently moot.
Security holes
Unfortunately in the short time since its release, a number
of security holes have been found in Java caused by bugs in
the implementation. The most recent one was described in September
of 1998, in which a buffer overflow bug in some Windows 95/NT
versions of the Java virtual machine can cause your computer
to crash. A demonstration, along with a listing of vulnerable
verions, can be found at
http://www.eyeone.no/KillerApp/KillerApp.htm.
A variety of other bugs have been identified and fixed,
and it is the author's personal opinion is that Java is
a far better alternative than the other forms of active
content, which provide little, if any security.
Some people, however, feel differently. For example, Princeton
computer scientist Edward Felten feels that there are fundamental
problems with the design of the language itself. His 1996
paper
Java Security: From HotJava to Netscape and Beyond,
which was published in the 1996 IEEE Symposium on Security
and Privacy, concludes with the following sobering assessment:
We conclude that the Java system in its current
form cannot easily be made secure. Significant redesign
of the language, the bytecode format, and the runtime system
appear to be necessary steps toward building a higher-assurance
system.
If you are security conscious, you might wish to take
the safest course and deactivate Java completely. In Netscape
Navigator 2.0-3.02, you can do this by unchecking the "Java"
option in Options->Network Preferences->Languages.
In Internet Explorer 3.02, uncheck "Enable Java Programs"
in the View->Options->Security->Active Content
window.
Deactivating Java is harder in the 4.0 versions of both
Navigator and Internet Explorer. In Netscape Navigator 4.0,
select Edit->Preferences from the menu bar,
then select the "Advanced" category. Locate the "Enable
Java" checkbox and deselect it.
In IE 4.0, select View->Internet Options->Security,
select the Internet Zone, and select "Custom" settings.
Now press the "Settings..." button and scroll down to the
Java settings. Choose "Disable Java."
Below are some of the older security holes present in
the Java implementations distributed with various versions
of Netscape and Internet Explorer.
Ability to Execute Arbitrary Machine
Instructions
On 22 March 1996, Drew Dean (
ddean@CS.Princeton.EDU) and Ed Felton (
felten@CS.Princeton.EDU) of the Princeton
Dept of Computer Science, announced that they had successfully
exploited a bug in Java to create a applet that deletes a
file on the user's local disk. In this bug, a binary library
file is first downloaded to the user's local disk using the
Netscape caching mechanism. The Java interpreter is then tricked
into loading the file into memory and executing it.
This bug is present in versions 2.0 and 2.01 of Netscape.
It has been fixed in versions 2.02 and 3.0x.
More information on this bug can be found at
http://www.cs.princeton.edu/sip
Vulnerability to Denial-of-Service
Attacks
Applets can hog system resources such as memory and CPU time.
This may happen as the result of a programmer error, or maliciously
in order to slow down the computer system to the point of
unusability. Applets running under the same browser are not
protected from one another. One applet can easily discover
another's existence and interfere with it, raising the interesting
spectre of one vendor's applet deliberately making a competitor's
applet appear to behave erratically.
If an applet appears to be behaving improperly, closing
the page from which it originated does not necessarily shut
it down. It may be necessary to shut off the browser entirely.
Ability to Make Network Connections
with Arbitrary Hosts
Version 2.0 of Netscape Navigator contained another Java bug,
this one involving the restriction on Applets from contacting
arbitrary hosts.
This bug has been fixed
in version 2.01 of Netscape, and you should upgrade to a more
current version if you haven't already.
Applets are supposed to be able to talk only to the server
that they originated from. However in early March 1996,
Steve Gibbons (
mailto:sgibbo@amexdns.amex-trs.com) and Drew Dean (ddean@CS.Princeton.EDU)
independently discovered holes in the implementation that
allows Applets to make connections to any host on the Internet.
This is a serious problem: once downloaded to a user's machine,
the applet can now attempt to make a connection to any machine
on the user's local area network, even if the LAN is
protected by a firewall. Many LANs are set up so that
local machines are trusted to access services that distant
machines are not. As a trivial example, an Applet could
open up a connection to the organization's private news
server, fetch recent postings to an internal newsgroup,
and transmit them back to a foreign host.
Unix users who are familiar with the Berkeley rsh,
rlogin and rcp commands will see
that this bug represents a risk to systems that trust each
other enough to allow commands to be executed remotely.
This bug also makes it possible for Applets to collect detailed
information on network topology and name services from behind
a firewall.
This security hole involves Java's trusting use of the
Domain Name System (DNS) to confirm that it is allowed to
contact a particular host. A malfeasant using his own DNS
server can create a bogus DNS entry to fool the Java system
into thinking that a script is allowed to talk to a host
that it is not authorized to contact.
On March 5, 1997, an internal security audit at JavaSoft revealed
a bug in the Java bytecode verifier. In theory, this bug could
be exploited to bypass the Java Security Manager and execute
forbidden operations. No actual exploitations of this bug
are known. The bug is present in JDK 1.1, in Microsoft Internet
Explorer versions 3.01 and earlier, and in Netscape Navigator
3.01 and earlier. A patch has been made available to Java
library licensees and should be appearing in more recent versions
of these products.
More information about Java and security can be found
at URL:
http://java.sun.com/sfaq/
JavaScript has a more troubling history of security holes.
Unlike the Java holes, which potentially can change data on
the user's disk, JavaScript holes generally involve infringements
on the user's privacy. Although many bugs have been closed,
others keep popping up. The most recent bug was reported on
October 16, 1997.
Ability to Read Arbitrary Files
on User's Machine (November 1998)
A bug in the JavaScript implementation in Netscape Communicator
4.5 and 4.04-4.05 allows a Web page to read arbitrary files
from the user's machine and transmitted across the Internet.
Any file that can be read with the user's permissions is
vulnerable, including the system password file. The bug
affects both Windows and Unix versions of Communicator.
Any HTML page can carry this exploit, including ones that
are transmitted as an e-mail enclosure. Internet Explorer
has not been reported to be vulnerable.
The "Cuartango" and "Son of Cuartango"
Holes (November 1998)
Microsoft Internet Explorer is also vulnerable to file theft
via JavaScript. Internet Explorer versions 4.0-4.01 and prerelease
versions of IE 5.0 allow JavaScript programs to cut and paste
text into file upload fields, thereby allowing a boobytrapped
Web page or e-mail message to steal any file on the user's
disk. The original hole and its "son" are described in Juan
Cuartango's pages at
http://pages.whowhere.com/computers/cuartangojc/.
See http://www.microsoft.com/security/bulletins/ms98-015.asp
for Microsoft's description of the bug and a patch file
to fix it.
The Netscape "Cache Browsing Bug"
(October 1998)
A hole in the Windows versions of Netscape Navigator 3.04,
4.07 and 4.5 allows remote sites to read URLs from the browser
cache, allowing them to intercept the list of sites recently
visited by the user. This bug is described in a Netscape
security note. Mac OS and Unix versions are not affected.
No patch is currently available for these software versions.
Ability to Intercept the User's
E-Mail Address and Other Preferences (February 1998)
Versions of Netscape Navigator 4.0 through 4.04 contain a
security hole involving access of JavaScript programs to the
browsers preferences settings. The settings, which are stored
in a file named
preferences.js in the Netscape
directory, include a variety of private information such as
your e-mail address, the names of mailbox files, and the identity
of your e-mail and news servers. In addition, in many cases
the preferences file also stores your e-mail (POP) and FTP
(publish) passwords. To see what else is in this file, open
it in a text editor and take a look.
The implications of this hole is that a JavaScript enabled
page can open the preferences file and upload all information
contained within it to a remote server. This can be exploited
to capture visitors' e-mail addresses and to gather information
about the user's network configuration. The worst risk is
that the user's e-mail password will be disclosed. Since
the e-mail password is, in many cases, the same as the user's
LAN login password, this exposes organizations to a potential
route of attack.
All versions of Netscape Communicator through 4.04 are
vulnerable. Netscape version 4.05 reportedly fixes the problem.
Please upgrade at your earliest convenience. Of course,
deactivating JavaScript is also an effective solution, and
protects you against other bugs that are likely to be lurking
in the JavaScript system.
This bug was uncovered by French software consultant Fernand
Portela. More information is available at his Web site at:
http://www.mygale.org/~nando
Interception of Files on User's
Local Machine (October 16, 1997)
Microsoft Internet Explorer 4.0 for Windows 95/NT is vulnerable
to pages that allow the remote Web site operator to spy on
the contents of any text, image or HTML file located on your
machine, or any file located on a mounted file server. Firewalls
cannot protect against this attack, and the browser is vulnerable
even when running in "High Security" mode. The Macintosh versions
of IE 4.0 are not affected, apparently.
The bug, discovered by German consultant Ralf Hueskes
and known as the "Freiburg attack," involves the trick of
using JavaScript to create an invisible frame 1x1 pixel
wide. While the unsuspecting user browses the remote site,
a JavaScript program running in the invisible frame scans
the user's local machine and file shares for files with
well-known names, and may then upload them to any site on
the Internet. The bug does not allow JavaScript to modify
or damage files. Microsoft has issued a patch for this bug,
available at:
http://www.microsoft.com/msdownload/ieplatform/ie4patch/ie4patch.htm
More information on the bug can also be found at:
http://www.jabadoo.de/press/ie4_us_old.html
Ability to Monitor the User's Session
(August 29, 1997)
A group of related bugs allows JavaScript pages to monitor
all pages the user visits during a session, capture the URLs
of documents viewed, and transmit the information to a host
somewhere on the Internet. Some variants of the bug allow
the malicious page to capture the contents of fill-out forms,
cookies, and information about other elements on the page.
Information can be stolen even if the user is viewing "secure"
pages encrypted with SSL, and users working behind corporate
firewall systems are as vulnerable as those connected directly
to the Internet. The only risk is to the user's privacy, however.
Data and software located on the user's machine cannot be
modified.
Most variants of the bug involve the ability of JavaScript
pages to open up an invisible window. Because the user can't
see the window, she isn't aware that a JavaScript program
continues to run even after leaving the page that launched
the script. Other variants of the bug open up a new browser
window and entice the user into using the window for subsequent
browsing.
Despite many attempts to quash this group of bugs, variants
reappear at almost monthly intervals and go under such cute
names as "the Bell labs bug," the "Singapore bug" and the
"Santa Barbara bug." There have been so many patches and
releases, it's difficult to keep track. However the following
browsers are known to be vulnerable:
- Microsoft Internet Explorer 3.01, Windows 95/NT
- Microsoft Internet Explorer 3.02, Windows 95/NT
- Microsoft Internet Explorer 4.0 Platform Preview, Windows
95/NT
- Netscape Navigator 3.0, 3.01, and 3.02, all platforms
- Netscape Communicator 4.0 and 4.01, all platforms
- Netscape Communicator 4.02, Windows 95/NT
More information on these bugs can be found at the locations
listed below. Check here for updates and code patches:
Older Holes
The following holes exist in Netscape versions 2.0 and 2.01.
They were discovered and publicized by John Robert LoVerso
of the OSF Research Institute (
loverso@osf.org):
- JavaScripts can trick the user into uploading a file
on his local hard disk or network mounted disk to an arbitrary
machine on the Internet. Although the user must click
a button in order to initiate the transfer, the button
can easily masquerade as something innocent. Nor is there
any indication that a file transfer has occurred before
or after the event. This is a major security risk for
systems that rely on a password file to control access,
because a stolen password file can often be readily cracked.
- JavaScripts can obtain directory listings of the user's
local hard disk and any network mounted disks. This represents
both an invasion of privacy and a security risk, since
an understanding of a machine's organization is a great
advantage for devising a way to break into it.
- JavaScripts can monitor all pages the user visits during
a session, capture the URLs, and transmit them to a host
somewhere on the Internet. This hole requires a user interaction
to complete the upload, but as in the first example the
interaction can be disguised in an innocuous manner.
- JavaScripts can trigger Netscape Navigator into sending
off e-mail messages without the user's knowledge. This
technique can be used to capture user's e-mail addresses.
A description of these bugs can be found at:
http://www.osf.org/~loverso/javascript/
These JavaScript bugs have been closed in Netscape Navigator
versions 3.0 and higher. The exception is the e-mail address
capture hole, which was closed in version 2.01 but reappeared
again in version 3.0. This hole has again been closed in
version 3.01, which offers a checkbox in the Network
& Security Options dialog box to warn you before
Navigator sends e-mail in your name. Microsoft Internet
Explorer, which supports a dialect of JavaScript, has a
similar option in its Options window.
The Bottom Line
JavaScript contains security holes. Many of them have been
caught, but new ones are appearing at a steady rate. Undoubtedly
there are still bugs lurking. People who worry about the disclosure
of personal information are encouraged to turn JavaScript
off completely. In Netscape Navigator 2.X-3.X, you can do
this by deactivating a checkbox located in
Options->Network
Preferences->Languages. In Microsoft Internet Explorer
versions 3.X, you can do this by unchecking a misleadingly-named
checkbox labeled
Run ActiveX scripts in
View->Options->Security.
In Microsoft Internet Explorer 4.0, the new "Security
Zones" feature, which was designed to make the Internet
safer, actually makes it difficult to turn off JavaScript,
since it is active even when "High Security" is selected.
To do this, go to View->Internet Options->Internet
Security, and select the "Internet Zone". Now select
the radio button labeled "Custom" and press the adjacent
"Settings..." button. Scroll down to the bottom of the option
list, and disable the option labeled "Active Scripting."
In Netscape Navigator 4.0, you should follow the procedure
outlined above for disabling Java.
ActiveX is a technology developed by the
Microsoft Corporation for distributing software
over the Internet. Like Java Applets, an ActiveX "control"
can be embedded in a Web page, where it typically appears
as a smart interactive graphic. A number of ActiveX controls
are available for the Microsoft Internet Explorer (the only
browser to support them so far), including a scrolling marquee,
a background sound generator, and an ActiveX control that
executes Java applets. Unlike Java, which is a platform-independent
programming language, ActiveX controls are distributed as
executable binaries, and must be separately compiled for each
target machine and operating system.
The ActiveX security model is considerably different from
Java applets. Java achieves security by restricting the
behavior of applets to a set of safe actions. ActiveX, on
the other hand, places no restrictions on what a control
can do. Instead, each ActiveX control can be digitally "signed"
by its author in such a way that the signature cannot be
altered or repudiated using a system called "Authenticode."
The digital signatures are then certified by a trusted "certifying
authority", such as VeriSign, to create the equivalent of
a shrink-wrapped software package. When a digital certificate
is granted, the software developer pledges that the software
is free from viruses and other malicious components. If
you download a signed ActiveX control and it crashes your
machine, you'll at least know who to blame.
This security model places the responsibility for the
computer system's security squarely on the user's head.
Before the browser downloads an ActiveX control that hasn't
been signed at all, or that has been signed but certified
by an unknown certifying authority, the browser presents
a dialog box warning the user that this action may not be
safe. The user can elect to abort the transfer, or may continue
the transfer and take his chances.
The ActiveX certification process ensures that ActiveX
controls cannot be distributed anonymously and that a control
cannot be tampered with by third parties after its publication.
However, the certification process does not ensure
that a control will be well-behaved. Although it is unlikely
that signed and certified ActiveX controls will behave in
a malicious fashion, it is not impossible. To illustrate
this point, software developer Fred McLain (mclain@halcyon.com) recently published an
ActiveX control named Exploder. This control,
which has been fully signed and certified, performs a clean
shutdown of any Windows95 machine that downloads it. The
shutdown occurs automatically soon after the user views
an HTML page that contains the Exploder control (using Microsoft
Internet Explorer version 3.0 or higher). After learning
about Exploder, Microsoft and Verisign jointly revoked Fred
McLain's certified digital signature, claiming that he had
violated the agreement made when the certification was issued.
Therefore, if you are running a newer version of Internet
Explorer, you'll see a message that Exploder's software
certificate is invalid.
While Exploder does not cause any data loss, a less friendly
control might reformat the user's hard disk or plant a virus.
In fact, a series of highly malicious ActiveX controls have
been created and distributed by the Chaos Computer Club
(CCC) of Hamburg, Germany. They are unsigned controls, meaning
that with its default settings in place, Internet Explorer
will warn the user that they are not to be trusted. However,
naive users who have changed Internet Explorer's restrictions
on active content to "Low Security", or who agree to download
and execute the controls despite the warnings, are vulnerable
to attack by this means.
The main problem with the ActiveX security model is that
it is difficult to track down a control that has taken some
subtle action, such as silently transmitting confidential
configuration information from the user's computer to a
server on the Internet, seeding the LAN with a virus, or
even patching Internet Explorer so that the code authentication
engine no longer functions correctly. This type of action
may escape detection completely, or at least for a long
period of time. Even if the damage is detected immediately,
Internet Explorer offers no secure audit trail that records
which ActiveX controls were downloaded. This makes identifying
the control responsible for damaging your system a non-trivial
task.
ActiveX can be turned off completely from the Internet
Options->Security pages of Microsoft Internet Explorer.
Choose the "High Security" setting to disable ActiveX completely,
or "Medium Security" to prompt you before downloading and
executing ActiveX controls. If you do allow a control to
run, read its Authenticode certificate carefully, and then
carefully commit its name, publisher, date and the time
of download to hardcopy. Don't store this information on
disk, since that medium can easily be altered or destroyed
by the control itself! The "Low Security" option allows
any ActiveX control to run, signed or not, and is not recommended.
IE 4.0 allows you to customize the behavior of ActiveX controls
depending on whether they are coming from a site on the
Internet, a site on the local area network, or a site on
specially-prepared lists of trusted and untrusted sites.
This section deals with Web "cookies", explaining what they
are, and what security issues they pose.
What Cookies Are
A "cookie" is a mechanism developed by the Netscape Corporation
to make up for the stateless nature of the HTTP protocol.
Normally, each time a browser requests the URL of a page from
a Web server the request is treated as a completely new interaction.
The fact that the request may be just the most recent in a
series of requests as the user browses methodically through
the site is lost. Although this makes the Web more efficient,
this stateless behavior makes it difficult to create things
like shopping carts that must remember the user's actions
over an extended period of time.
Cookies solve this problem. A cookie is a small piece
of information, often no more than a short session identifier,
that the HTTP server sends to the browser when the browser
connects for the first time. Thereafter, the browser returns
a copy of the cookie to the server each time it connects.
Typically the server uses the cookie to remember the user
and to maintain the illusion of a "session" that spans multiple
pages. Because cookies are not part of the standard HTTP
specification, only some browsers support them: currently
Microsoft Internet Explorer 3.0 and higher, and Netscape
Navigator 2.0 and higher. The server and/or its CGI scripts
must also know about cookies in order to take advantage
of them. Cookies contain attributes that tell the browser
what servers to send them to. The "domain" attribute tells
the browser which host names the cookie should be returned
to, and the "path" attribute indicates what URL paths within
that domain are valid. For instance, a domain of "megacorp.com"
and a path of "/users" tells the browser to return the cookie
to hosts with names like "ftp.megacorp.com" and "www.megacorp.com",
and to do so only when requesting URLs that start with the
path "/users". An important security measure prevents the
cookie's domain from being set to top-level domains like
".com". This prevents someone from creating a promiscuous
cookie that will be returned to any server.
Cookies And Privacy
Cookies cannot be used to "steal" information about you or
your computer system. They can only be used to store information
that you have provided at some point. To give a benign example,
if you fill out a form giving your favorite color, a server
can turn this information into a cookie and send it to your
browser. The next time you contact the site, your browser
will return the cookie, allowing the server to alter background
color of its pages to suit your preferences.
However cookies can be used for more controversial purposes.
Each access your browser makes to a Web site leaves some
information about you behind, creating a gossamer trail
across the Internet. Among the tidbits of data left along
this trail are the name and IP address of your computer,
the brand of browser you're using, the operating system
you're running, the URL of the Web page you accessed, and
the URL of the page you were last viewing. Without cookies,
it would be nearly impossible for anyone to follow this
trail systematically to learn much about your Web browsing
habits. They would have to reconstruct your path by correlating
hundreds or thousands of individual server logs. With cookies,
the situation changes considerably.
The DoubleClick Network
is a system created by the DoubleClick Corporation to create
profiles of individuals using the World Wide Web and to
present them with advertising banners customized to their
interests. DoubleClick's primary customers are Web sites
looking to advertise their services. Each member of the
DoubleClick Network becomes a host for the advertising of
other members of the network. When a Web site joins DoubleClick
it creates advertisements for its services and submits them
to DoubleClick's server. The Web site then modifies its
HTML pages to include an <IMG> graphic that points
to DoubleClick. When a user goes to view one of these modified
HTML pages, her browser makes a call to DoubleClick's server
to retrieve the graphic. The server chooses one of its member's
advertisements and returns it to the browser. If the user
reloads the page, a different advertisement appears. If
the user clicks on the graphic, her browser jumps to the
advertised site. Currently many hundreds of sites belong
to DoubleClick. From the user's point of view DoubleClick's
graphics appear no different from any other Web advertisement,
and there's no visible indication of anything special about
the graphic. However, there is an important difference.
When a user first connects to the DoubleClick server to
retrieve a graphic, the server assigns the browser a cookie
that contains a unique identification number. From that
time forward whenever the user connects to any
Web site that subscribes to the DoubleClick Network, her
browser returns the identification number to DoubleClick's
server, allowing the server to recognize her. Over a period
of time DoubleClick compiles a list of which member sites
the user has visited and revisited, using this information
to create a profile of the user's tastes and interests.
With this profile in hand the DoubleClick server can select
advertising that is likely to be of interest to the user.
It can also use this information to compile valuable feedback
for its member Web sites, such as providing them with audience
profiles and rating the effectiveness of the advertisements.
Although names and e-mail addresses are not
part of the information that DoubleClick records, other
information that the browser leaves behind is sufficient,
in many cases, to identify the user. See Server
Logs and Privacy for more information. For this reason
many people are uncomfortable with DoubleClick's use of
cookies. To find out whether you have been tracked by DoubleClick,
examine your browser's cookies file. On Unix systems using
Netscape, the cookies file can be found in your home directory
in the file ~/.netscape/cookies. If a line
like this appears:
ad.doubleclick.net FALSE / FALSE 942195440 IAA d2bbd5
then you are carrying a DoubleClick cookie.
Windows users will find the equivalent information in
the file cookies.txt, located in their
C:\Programs\Netscape\Navigator directory,
while Macintosh users should look in their System Folder
under Preferences:Netscape. Users of Microsoft
Internet Explorer should examine the files located in C:\Windows\Cookies.
Current versions of both Netscape Navigator and Internet
Explorer offer the option of alerting you whenever a server
attempts to give your browser a cookie. If you turn this
alert on, you will have the option of refusing cookies.
You should also manually delete any cookies that you have
already collected. The easiest way to do this is to remove
the cookies file entirely.
The drawback to this scheme is that many servers will
offer the same cookie repeatedly even after you refuse to
accept the first one. This rapidly leads to a nuisance situation.
Before you panic over cookies, it's worth remembering that
the vast majority of cookies are benign attempts to improve
your Web browsing experience, not intrusions on your privacy.
Netscape Navigator 4.0 provides a new feature that allows
you to refuse cookies that are issued from sites other than
the main page you are viewing. This foils most DoubleClick
schemes without interfering with the more benign cookies.
To access this option, select Edit->Preferences->Advanced,
and select the appropriate radio button from the cookies
section.
Some people might want to allow transient cookies (ones
active only during a browsing session) but forbid persistent
ones (ones that store user identification information over
an extended period). On Unix systems, you can do this easily
by creating a symbolic link between the Unix "bit bucket"
device, /dev/null and the cookies file. Users
of other operating systems may have to invest in third party
products that intercept cookies. A representative listing
of such products follows:
- NSClean, IEClean
- Windows 95/NT programs that wipe the cookies file clean.
- http://www.nsclean.com/
- InterMute (Windows, Macintosh, Unix)
- An anonymizing proxy that removes cookies, referer information,
and other identifying information from your URL requests.
Runs as a Java applet within the browser.
- http://www.intermute.com/
- Internet Junkbuster Proxy (Unix)
- An anonymizing proxy that removes cookies, referer information,
and other identifying information from your URL requests.
- http://internet.junkbuster.com/
Cookies And System Security
In addition to the privacy issues, cookies carry security
implications as well. Many sites use cookies to implement
access control schemes of various sorts. For example, a subscription
site that requires a user name and password might pass a cookie
back to your browser the first time you log in. Thereafter,
the site will give you access to restricted pages if your
browser can produce a valid cookie, basically using the cookie
as an admission ticket. This can have several advantages for
the site, not the least of which is that it can avoid the
overhead of looking up your user name and password in a database
each and every time you access a page.
However, unless this type of system is implemented carefully,
it may be vulnerable to exploitation by unscrupulous third
parties. For instance, an eavesdropper armed with a packet
sniffer could simply intercept the cookie as it passes from
your browser to the server, using it to obtain free access
to the site. Because browsers use the domain name system
(DNS) to determine what cookies belong to a server, it is
possible to trick a browser into sending a cookie to a rogue
server by temporarily subverting the DNS. If the cookie
is persistent, of course, it is also vulnerable to being
stolen from the user's cookie database file.
Now consider a transaction processing systems that uses
cookies as session IDs to preserve state during the steps
of a multi-part transaction. Examples of such systems include
a system that allows authorized employees to update records
in a corporate database, an on-line ordering system, or
a bank transaction system. If care is not taken to protect
the cookie from interception, it is possible for an interloper
to hijack the transaction and use it to make unauthorized
transactions.
Designers of systems that use cookies for authentication
and state-preservation should be alert to the possibility
of cookie interception. Cookies should aways contain as
little private information as possible. In particular, it
is never appropriate for cookies to contain plaintext
user names and passwords. In ISP environments where many
users share the same Web server, it is important to use
as specific a path as possible in the cookie. For instance,
if the program that processes cookies lives at URL http://bigISP.com/users/fred/order.cgi,
then the developer should arrange for the cookie path to
be set to /users/fred/order.cgi rather than
a more general path like /.
If possible, cookies should contain information that allows
the system to verify that the person using them is authorized
to do so. A popular scheme is to include the following information
in cookies:
- the session ID or authorization information
- the time and date the cookie was issued
- an expiration time
- the IP address of the browser the cookie was issued
to
- a message authenticity check (MAC) code
By incorporating an expiration date and time into the cookie,
system designers can limit the potential damage that a hijacked
cookie can do. If the cookie is intercepted, it can only be
used for a finite time before it becomes invalid. The idea
of including the browser's IP address into the cookie is that
the cookie will only be accepted if the stored IP address
matches the IP address of the browser submitting it. This
makes it difficult for an interloper to hijack the cookie,
because it is hard (although not impossible) to spoof an IP
address.
The MAC code is there to ensure that none of the fields
of the cookie have been tampered with. There are many ways
to compute a MAC, most of which rely on one-way hash algorithms
such as MD5 or SHA to create a unique fingerprint for the
data within the cookie. Here's a simple but relatively secure
technique that uses MD5:
MAC = MD5("secret key " +
MD5("session ID" + "issue date" +
"expiration time" + "IP address" +
"secret key")
)
This algorithm first performs a string concatenation of all
the data fields in the cookie, then adds to it a secret string
known only to the Web server. The whole is then passed to
the MD5 function to create a unique hash. This value is again
concatenated with the secret key, and the whole thing is rehashed.
(The second round of MD5 hashing is necessary in order to
avoid an attack in which additional data is appended to the
end of the cookie and a new hash recalculated by the attacker.)
This hash value is now incorporated into the cookie data.
Later, when the cookie is returned to the server, the software
should verify that the cookie hasn't expired and is being
returned by the proper IP address. Then it should regenerate
the MAC from the data fields, and compare that to the MAC
in the cookie. If they match, there's little chance that
the cookie has been tampered with.
Perl programmers can take advantage of the HMAC algorithm,
a slightly more sophisticated technique that has been incorporated
into a module by Gisle Aas. It is available at CPAN in the module MD5::Digest.
An alternative method is to encrypt the entire cookie
with an encryption algorithm such as DES, IDEA or RC4. For
more information on using encryption and hash algorithms,
see the cryptography references
at the end of this document. For extremely sensitive applications,
developers should probably encrypt the entire channel between
browser and server using a non-crippled version of SSL.
The cookie will be encrypted along with the rest of the
data stream in such a way that network eavesdroppers cannot
intercept the cookie without first cracking the encryption.
To avoid the cookie being inadvertently disclosed across
a non-secure channel, developers should set the "secure"
attribute so that the browser only transmits the cookie
when SSL is in effect.
For many years the answer to this question was a resounding
no and that is largely the case now as well. There
are a series of hoax chain letters that are seemingly endlessly
circulating around the globe. A typical letter is the "Good
Times" hoax. It will warn you that if you see an e-mail
with a subject line that contains the phrase "Good Times"
you should delete it immediately because the very fact of
opening it will activate a virus that will do damage to
your hard disk. The letter will encourage you to send this
warning to your friends.
The "Good Times" hoax, and many like it, are simply not
true. However there are enough people who believe these
hoaxes that the messages are endlessly forwarded and reforwarded.
If you get a letter like this one, simply delete it. Do
not forward it to your friends, and please do not forward
it to any mailing lists. If you are uncertain whether the
letter is a hoax, refer it to your system administrator
or network security officer.
Just to make life complicated, however, there are some
cases in which the simple act of opening an e-mail message
can damage your system. The newer generation of e-mail
readers, including the one built into Netscape Communicator,
Microsoft Outlook Express, and Qualcomm Eudora all allow
e-mail attachments to contain "active content" such as ActiveX
controls or JavaScript programs. As explained in the JavaScript
and in the ActiveX sections, active content provides a variety of
backdoors that can violate your privacy or perhaps inflict
more serious harm. Until the various problems are shaken
out of JavaScript and ActiveX, enclosures that might contain
active content should be opened cautiously. This includes
HTML pages and links to HTML pages. Disabling JavaScript
and ActiveX will immunize you to potential problems.
In addition, there are other cases where e-mail messages
can be harmful to your health. In the summer of 1998, a
number of programming blunders were discovered in e-mail
readers from Qualcomm, Netscape and Microsoft. These blunders
(which involved overflowing static buffers) allowed a carefully
crafted e-mail message to crash your computer or damage
its contents. No actual cases of damage arising from these
holes has been described, but if you are cautious you should
upgrade to a fixed version of your e-mail reader. More details
can be found at the vendors' security pages:
- Microsoft
- http://www.microsoft.com/security/bulletins/
- Netscape
-
http://www.netscape.com/products/security/
- Qualcomm
-
http://eudora.qualcomm.com/security.html
Finally, don't forget that some documents do carry viruses.
For example, Microsoft Word, Excel and PowerPoint all support
macro languages that have been used to write viruses. Naturally
enough, if you use any of these programs and receive an
e-mail message that contains one of these documents as an
enclosure, your system may be infected when you open that
enclosure. An up-to-date virus checking program will usually
catch these viruses before they can attack. Some virus checkers
that recognize macro viruses include:
- McAfee VirusScan
- http://www.mcafee.com/
- Symantec AntiVirus
- http://www.symantec.com/
- Norton AntiVirus
- http://www.symantec.com/
- Virex
- http://www.datawatch.com/virex.shtml
- IBM AntiVirus
- http://www.av.ibm.com/
- Dr. Solomon's Anti-Virus
- http://www.drsolomon.com/
There are many variants of this question, and the answer
to them all is yes. If a site publishes public
(not password-protected) pages on the Web, there is nothing
to stop anyone who wants to from copying the entire site
and setting up a server that uses the pirated content.
It is surprisingly easy to do this; there are many Perl
"spiders" that will copy an entire site with a single
command, and even Internet Explorer has a simple built-in
spider. Sometimes this activity is legitimate, such as
when someone sets up a mirror site of a public document
(for example, the the WWW Security FAQ is mirrored in this way), but
sometimes it is out-and-out piracy.
The implication of this is that you should be a little
careful about trusting what you see on the screen. Popular
sites often are surrounded by non-affiliated sites with
similar names that exploit peoples' tendency to make
typographical errors when entering URLs. For example,
try http://www.nescape.com or http://www.mcrosoft.com/. Always check double-check
the URL of the site you are accessing before submitting
personal or confidential information to it.
Although difficult, it is possible in some cases for
a site to temporarily "spoof" the domain name system
so that a URL points to the wrong server. In this case
both the URL and the content will look right, but the
server you are communicating with is not the one you
think it is. If the site uses SSL, one way to confirm
its identity is to check the site's
digital certificate. If the site is supposed to
be using SSL, but isn't, this is a cause for suspicion.
However, even when the URL and certificate agree you
cannot always be sure that a page contains the content
approved by the Web site. In November 1998, a breathtaking
flaw came to light in the implementation of frames in
recent versions of Netscape Navigator and Microsoft
Internet Explorer. By exploiting this bug, a malicious
Web site can insert its own content into one or more
frames of a trusted Web site. This will make the content
appear to be coming from the trusted site, but in actually
it comes from a untrusted third party. The URL will
appear to be correct, and not even the digital certificate
can be used to tell otherwise! This bug is described
in the following URLs:
A related question frequently
asked by Webmasters is how to prevent their material
from being hijacked. If the concern is that someone
will copy a public document across the Internet and
then uses it for their own ends, the sad answer is that
there is no way to avoid this. However, there are a
number of techniques for digitally "watermarking" copyrighted
images, sound samples, and other binary formats in order
to discourage their use and to prosecute offenders.
For collections of links to products that offer this
technology, see the bilderbank
digital watermarking pages, and Alessandro
Piva's digital watermarking pages, and Digital watermarking, steganograph
& information hiding.
If, on the other hand, the concern is that unscrupulous
sites are linking to your CGI scripts and images without
authorization, essentially freeloading on your site,
then you may be able to prevent this by using the Referer
field to restrict access. This requires you to have
a Web server that can filter requests based on arbitrary
HTTP request fields. You will want to allow requests
by older clients that have no Referer field defined,
and those whose Referer field points back to one of
your site's pages. Clients whose Referer field is from
an unrelated site are refused acccess. This will prevent
remote sites from using your site as the target of their
<IMG> and <FORM> tags.
The Apache Web
server, when equipped with the optional mod_rewrite module,
can accomplish this with the following series of directives:
RewriteCond %{HTTP_REFERER} !^$ # Referer field exists
RewriteCond %{HTTP_REFERER} !^http://my.site.com/ [NC] # and not my site
RewriteRule [^/]+\.(gif|jpg)$ - [F] # No access to images
RewriteRule ^/cgi-bin/.+$ - [F] # No access to
CGIs
See your vendor's documentation to determine whether
the Web server you use provides this capability.
For Windows 95, WFWG and Windows NT users, the answer
is sometimes yes. A malicious Web server can trick either
Internet Explorer or Netscape Navigator into revealing
the user name that you use to log in to your organization's
local area network. It can also force the browser to reveal
your login password in an encrypted form that can often
be cracked using a "dictionary attack". This represents
a major problem both for yourself and for your organization,
because as soon as your login name and password are known,
outsiders can use it to break into your organization's
LAN, steal data, or damage files. This is provided, of
course, that the LAN is not specifically protected against
attacks of this sort by a properly configured
firewall system.
If intruders succeed in inflicting damage on your
organization's systems, the damages will appear to have
caused by you, and you'll have some explaining
to do. Even if you are not connected to a LAN, you still
have cause to worry. If you have at any point turned
on Windows-based file sharing, your personal files can
be stolen or damaged during the period of time you are
connected to the Internet through an ISP.
A total of three separate, but related bugs have been
discovered. The first bug was reported on March 14,
1997 by Aaron Spanger and
so far has not been fixed. It affects Internet Explorer
versions 3.01 and lower (including those with Microsoft's
security patches), running under Windows 95, Windows
NT and Windows 97. Netscape Navigator 3.01 (regular
and gold) and Netscape Communicator beta2 browsers are
also vulnerable when running on Windows NT systems,
and under some, but not other, Windows 95 systems (results
are mixed). A description and demonstration is available
at:
http://www.ee.washington.edu/computing/iebug/
The second bug, discovered by Paul Ashton on the heels of the first,
affects IE (3.01 and lower) running on Windows NT 3.51/4.0
(both server and workstation versions). It is described
at:
http://www.efsl.com/security/ntie/
The second bug, reported on March 17, 1997 by Steve Birnbaum, affects Microsoft Internet
Explorer (version 3.01 and lower) when running on Windows
95. It is described at:
http://www.security.org.il/msnetbreak/
These bugs all involve Microsoft's "challenge/response"
mode of user authentication used for file sharing. Here's
a slightly simplified explanation. When a client attempts
to contact a server (whether a file server, a web server
or a shared printer), the server sends the client a
short, randomly chosen challenge string called a "nonce."
The client encrypts the challenge using the user's password,
and sends the encrypted challenge, the user's name,
and other identifying information back to the server.
The server looks up the user in its password database,
finds the user's password, and uses the password to
encrypt the challenge. This is now compared to what
that the client sent back, and if they match, the server
confirms that the user knows the right password without
the password ever having been sent over the network.
Note that the thing being encrypted is not the "secret"
in this case, but the password used as the encryption
key.
If either IE or Netscape sees a URL of the form:
file://\\aa.bb.cc.ddd\path\to\file
(where "aa.bb.cc.dd" is the Internet address of the remote
server), it will attempt to access the file as if it were
a file on the local LAN, and attempts to authenticate
itself through the challenge/response system described
above. This is all done quietly without any notification
to the user.
During a password-theft attack, the host at this location
is running a specially modified version of the Windows
filesharing server that sends a constant challenge string
each time instead of a randomly chosen one. Your computer
trustingly encrypts the challenge with your password
and sends it back to the server. The server is now free
to compare your encrypted password to a dictionary containing
tens of thousands of passwords that have previously
been used to encrypt the challenge. If it finds a match,
it has successfully guessed your password (this is known
as a "dictionary attack"). Because many people pick
easily-guessed passwords, a good dictionary attack can
crack an average password about a quarter of the time.
Even if the server doesn't guess your password, it has
still collected other useful information about you:
the name of your computer, your user name, and the name
of your Windows domain. Because the source code to a
Unix-based Windows filesharing server is widely available,
it is relatively easy to create a modified server of
this sort.
In the case of the bug discovered by Steve Birnbaum,
the password isn't even encrypted. It's sent to the
malicious server in plaintext form. This is because
Windows 95 uses a less sophisticated authentication
system that that described above.
How can you tell if your password has been stolen
in this way? You can't. The malicious URL can be hidden
in an image. Unless you examine the source code for
every page you download, the image will look no different
from any other picture on the Web. Users running non-Windows
browsers will see the "broken image" icon -- hardly
something to raise suspicions.
What can you do to avoid this problem? Until Microsoft
and Netscape correct this bug there's not very much
you can do. Your best bet is to choose a good login
password. Make it long, and make it hard to guess. One
technique is to choose a phrase that is meaningful to
yourself but not to anyone else, for example:
blue wire chair too cold in AM
Now use the first letter (or the third or last) of each
word, creating the password bwctciA.
Don't share this password with anyone, and don't use it
for anything but LAN login.
There are a variety of security risks in Internet Explorer
that involve the JavaScript, Java and ActiveX subsystems. These risks
can be removed by turning off those features or installing
desktop active content protection software. This section
discusses problems that are part of the core browser software
and cannot be so easily avoided.
Certificate Spoofing, MIME Headers,
Cached Content, Version 5.5
Microsoft Internet Explorer 5.5 (Windows 95, Windows
NT, Macintosh and Unix versions) suffer from a series
of programming flaws related to features. For certificate
validation, the CRL check that is performed is flawed
and as a result, the certificates expiration date, issuer,
and hostname checks could all possibly be improperly
validated. For more information, and the patch,
see Microsoft's
security bulletin.
Since HTML email's are really just 'web' pages, when
using IE for email, there is a vulnerability whereby
a malicious MIME type could be specified for an email
attachment, and upon reading the email, IE would lauch
a program unchecked that was included as a part of the
email. This would allow a malicious user to send you
a program in email that IE would automatically run.
For more information, and the patch, see Microsoft's
security bulletin.
Since retrieved content is cached, IE retains the information
from where it came. IE 5.5 has a vulnerability whereby
the location of the cached content can be learned and
therefore web pages may be put together that would cause
cached content to be launched without being checked
as to from where it came. The security mechanisms normally
associated with controlling Internet content that is
cached are bypassed, and the content run as if coming
from the local machine (which is far more permissive).
For more information, and the patch, see Microsoft's
security bulletin.
HTML Help, Version 5
Microsoft Internet Explorer 5 and 5.5 (Windows 95,
Windows NT, Macintosh and Unix versions) suffer from
a series of programming flaws related to features each
provides. The HTML Help function relies on help files
originally written as web pages, which if altered in
some way can then cause malicious programs to run. This
Buffer Overflow Bugs, Versions
4.0, 4.01
Microsoft Internet Explorer 4.0 and 4.01 (Windows 95,
Windows NT, Macintosh and Unix versions) suffer from a
series of programming flaws in the way the software parses
and decodes certain HTML tags. A knowledgeable Web page
author can exploit this bug to cause Internet Explorer
to crash when you download a particular page or view an
image. Specifically, these bugs involve the allocation
of a static region of memory, known as a buffer, to hold
a URL or other HTML element. When the browser tries to
process an element that is longer than the buffer was
designed to hold, the browser overruns the region and
the program crashes. This type of memory allocation bug
is among the most common programming problems known, and
has been the cause of a variety of security holes in CGI
scripts and Web servers. See safe
CGI scripting for more details.
The bug has reared its head several times since January
of 1998. The first incarnation, called the "mk" bug,
involves the special "mk:" URLs that invoke the Microsoft
help system. This bug was patched, but anoother variant
reared its head soon after. Then, in April 1998, a bug
involving processing the <EMBED> tag was discovered.
This class of bug can have serious consequences. A
knowledgeable Web author can exploit this bug to execute
arbitrary machine code on your machine without your
knowledge. The code can do anything, including installing
viruses, tampering with files, or patching your copy
of Internet Explorer in order to disable other security
features. Changing the browser's security settings or
disabling active documents have no effect on these bugs.
Fortunately a patch for all known memory overflow bugs
is now available at Microsoft's Web site, at http://www.microsoft.com/security/.
If you use any version of Internet Explorer through
4.01, you should download the patch and apply it. Another
alternative is to downgrade to a Internet Explorer 3.02,
which has been around longer and has no known outstanding
security issues.
Further information on Internet Explorer's buffer
overflow bugs can be found at:
http://l0pht.com/advisories/
Recursive Frames Bug, Versions
4.0-4.01 (April 1998)
Microsoft Internet Explorer doesn't correctly detect and
handle "recursive" frames. To understand what a recursive
frame is, consider an HTML file named recursive.htm.
This file contains code like the following:
<HTML>
<FRAMESET COLS="*,*">
<FRAME SRC="recursive.htm">
<FRAME SRC="recursive.htm">
</FRAMESET>
</HTML>
This page defines two side-by-side frames, each of which
refers back to the original document. When Internet Explorer
sees this frameset, it tries to load the document into
each of the frames. Then it tries to create subframes
within each frame, and sub-subfames within those. This
continues ad infinitum until IE runs out
of memory and crashes.
This type of page can be used to cause an annoying
browser crash, but does not otherwise compromise security.
Reportedly certain versions of Netscape Navigator are
also vulnerable, but the 4.0X series does not appear
to be affected.
"Shortcut Bug", Versions 3.01
and Earlier
In addition to the LAN password bug, Microsoft Internet
Explorer versions 3.01 and earlier contains a serious
bug that allows any command on your computer to be executed
by remote control. Anything, up to and including the deletion
of the contents of your hard disk, is possible: you need
only click on a link leading to a malicious URL. Worse,
the bug can be easily exploited by people who have no
particular programming skills.
The problem is the result of a "feature" buried in
IE. Shortcut files are ordinarily created by individuals
in order to quickly access files and programs on their
local machines. If a shortcut file is copied onto a
Web server and accessed over the Internet, clicking
on a link to the shortcut has the surprising effect
of opening a copy of the file (if it exists) on the
local user's machine. If the file is an executable
program, such as the Windows registry editor or the
DOS command interpreter, this can result in potentially
dangerous programs being run on the user's computer
without his knowledge or consent. It is also possible
for a malicious individual to wrap several commands
into a .BAT file, arrange for it to be stored in the
unsuspecting user's browser cache, and then to have
this file executed.
The bug affects both Windows 95 and Windows NT systems,
and is present even if the you choose the highest level
of security. It is unrelated to ActiveX or Java. In
addition to links inside HTML files, the bug affects
hot links embedded in newsgroup postings and e-mail
messages.
The bug was discovered by Paul Greene, and further
researched with the help of Geoffrey Elliot and Brian
Morin. You can find further details (including dramatic
examples) at http://www.cybersnot.com/iebug.html.
If you are running IE 3.01 or earlier, you are strongly
advised to apply a patch provided by Microsoft Corporation,
which can be downloaded from http://www.microsoft.com/ie/security/update.htm.
After applying the patch, make sure that your copy of
IE was correctly updated by selecting "About Internet
Explorer" from the Help menu. It should indicate that
you are running version "3.01b". With the patch in place,
IE will warn you before opening a shortcut file. In
general, you should refuse to open any shortcut file
downloaded from the Internet.
Here's a simple test of whether you're running a patched
version of Internet Explorer. Try to open the link below.
If you get a message that warns you that you are attempting
to run a binary file and asks you whether to "Open"
or "Save" it, then you are using a patched version of
I.E. If the Notepad application opens then you have
a problem.
file:///C:\WINDOWS\NOTEPAD.EXE
As of 3/14/97, Microsoft's fix also handles the problem
of shortcut files attached to e-mail messages and news
postings. The original patch did not take care of the
latter problems.
On a side note, Microsoft's avowed plan to blur the
distinction between the Internet and the desktop has
a dark side. When it is difficult to distinguish between
untrusted software that originates "out there" and trusted
software that lives on the local disk, users can easily
be led into making mistakes that open up their machines
to a variety of attacks. In my opinion, this strategy
is one that is fraught with risks.
A Internet Explorer security FAQ is taking shape at
the following address:
