Up to Table of Contents|
Back to Server Logs & Privacy|| Forward to Specific Servers|
These words of warning apply also to the macro worksheets generated by popular PC spreadsheet programs. Although it seems natural to declare a type "application/x-msexcel-macro" in order to receive spreadsheets that automatically recalculate themselves, some of the functions in the Excel macro language have the potential to inflict damage on other worksheets and files. These warnings even apply to such seemingly innocuous things as word processor style sheets and template files! Many high end word processors have a built-in macro processing ability. An example of the way in which word processing macros can be misused is the Microsoft Word "prank macro", which has the ability to spread, virus-like, from document to document.
I have heard of at least one individual who decided he'd only be using
the C-shell to download scripts written by himself and other trusted
parties. He screened all URLs by hand to make sure they didn't end
.csh extension before downloading them.
Unfortunately the file extension is not a reliable way to determine
what a URL contains. The type of a document is determined by the Web
(HTTP) server, not the browser, and a document of type application/x-csh
can just as easily have an extension of
.txt or no
extension at all.
In short, beware of declaring an external viewer for any file that contains executable statements.
This security problem is addressed by scripting languages as Java and Safe Tcl in which dangerous functions can be disabled. There's even a prototype "Safe Perl" that can be used as a safer external viewer for perl programs.
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."
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, most 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 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 Netscape servers or Netscape servers outside the U.S. and Canada.
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.
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.
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.
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.
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.
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.
Because of the current problems with Java, the safest course is to turn Java off except when retrieving URLs from well-known and trusted hosts. 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 specific holes present in the Java implementations distributed with various versions of Netscape and Internet Explorer.
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
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.
Applets are supposed to be able to talk only to the server that they originated from. However in early March 1996, Steve Gibbons (a href="mailto:email@example.com" mailto:firstname.lastname@example.org) 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
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
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.
More information about Java and security can be found at URL:
More information on the bug can also be found at:
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:
More information on these bugs can be found at the locations listed below. Check here for updates and code patches:
A demo of this exploit can be found at http://www.genome.wi.mit.edu/~lstein/crossframes. Although it only captures inline image information from a single document, be aware that it could catch all the image URLs you view and upload them to a server somewhere.
This bug affects Netscape Navigator 3.0, 3.01 and Netscape Communicator 4.01. It is fixed in 4.02 and 3.03. It does not affect Navigator 2.X or Internet Explorer.
In order to exploit this bug, the remote server must know the name of the local file in advance. However, this is still a big problem. A large amount of sensitive information, including system passwords, are stored in files with known names.
Netscape Navigator 2.0, 3.0, 3.01 and Netscape Communicator 4.0 are all affected by this bug. Netscape Communicator 4.01, released June 21, contains a patch for this problem. Version 3.02 of Netscape Navigator is also expected to correct the problem. The most recent versions of these browsers are available at Netscape's Web site.
In Netscape Navigator 4.0, you should follow the procedure outlined for disabling Java.
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 (email@example.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.
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
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
then you are carrying a DoubleClick cookie.ad.doubleclick.net FALSE / FALSE 942195440 IAA d2bbd5
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
Users of Microsoft Internet Explorer should examine the files located
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.
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:
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:
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:
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:
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:
(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.file://\\aa.bb.cc.ddd\path\to\file
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 AMNow 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.
This bug has severe consequences. In the best case, the browser will exit unexpectedly. In the worst case, the browser will execute untrusted code of the remote author's design. This code can do anything, such as installing viruses, tampering with your files, or patching your copy of Internet Explorer to disable other security features.
Currently there is nothing you can do to avoid this bug (short of not using Internet Explorer). You cannot protect yourself with the Security Realms feature, with firewalls, or by changing the Security Settings level. Microsoft has not yet responded to the problem (as of January 16, 1998), but will no doubt release a patch in the near future.
Full information on this bug, along with sample exploits, are available at:
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.
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.
To emphasize the point, this security hole is among the most serious ever to have been identified in Web based software. If you use Internet Explorer, download and apply either of these patches or you are leaving yourself in a very vulnerable position.
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:
Check here for more information about IE security problems.http://www.teleport.com/~hindu/iesf-faq.html
Up to Table of Contents|
Back to Server Logs & Privacy|| Forward to Specific Servers|
Lincoln D. Stein (firstname.lastname@example.org)
Last modified: Fri Jan 16 10:59:38 EST 1998