-----BEGIN PGP SIGNED MESSAGE----- ___ __ __ _ ___ __ __ __ __ __ / | /_\ / |\ | / \ | |_ /_ \___ __|__ / \ \___ | \| \__/ | |__ __/ Number 96-01 March 18, 1996 This edition of CIAC NOTES includes: 1) Java and JavaScript Vulnerabilitites 2) FIRST Conference Announcement 3) Security and Web Search Engines 4) Microsoft Word Macro Virus Update Please send your comments and feedback to ciac@llnl.gov. $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ $ Reference to any specific commercial product does not necessarily $ $ constitute or imply its endorsement, recommendation or favoring by $ $ CIAC, the University of California, or the United States Government.$ $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ ========================================================================= 1) Java and JavaScript Vulnerabilities ========================================================================= By John Fisher Introduction - ------------ Over the past several weeks, a variety of reports have surface regarding security problems with Java and JavaScript. Java was developed by Sun Microsystems Incorporated, and JavaScript was developed by Netscape Incorporated. Java is available directly from Sun through the Java Development Kit. Both Java and JavaScript are supported with Netscape Navigator 2.0. Although similiar in name, and in some ways similiar in syntax, these two languages are vastly different in their usage. Accordingly, the security problems that have been reported are completely separate as well. This article maps out what problems have been reported and discusses the availability of solutions. Java applications communicate easily across a network environment, particularly the Internet. Although not initially intended for this environment, Java became a natural mechanism for enhancing the usability and functionality of the World-Wide Web. With Java "applets," a Web site can provide functionality for its visitors that is not available with HTML code. Java can be used in a variety of different capacities. A standard Java application can work stand-alone, providing functionality similar to other programming languages (i.e., file input/output, graphical interfaces, etc). When a Java application is made available on a Web site (via an HTML Web page), it is in the form of a Java applet. An applet is given definite restrictions on its capabilities. For example, a Java applet can not write files to a Web visitor's local disk drive, or contact an Internet site besides the server it was downloaded from. Java was supported with Netscape's Navigator 2.0, released in February. JavaScript is also supported in Navigator 2.0. Originally named LiveScript, JavaScript code is placed directly in the text of an HTML document (as opposed to being referenced in the HTML, similar to how an image would be included, like Java does). For browsers that don't understand JavaScript, JavaScript code simply seems to be a comment in the HTML code. For Navigator 2.0, a JavaScript program can provide additional functionality for the Web page that can't be provided with just HTML. While JavaScript provides increased functionality, it is syntactically simpler and less powerful than Java. Both Java and JavaScript have been developed with security in mind. Both were developed with considerable emphasis on preventing a Web site from gaining unintended access to a Web user's system or from performing actions on behalf of the Web user without the user's knowledge. Unfortunately, as is common with new technologies, unanticipated security concerns have come to light. The next section addresses the latest security concerns for Java and the section following addresses security issues for JavaScript. Java Problems - ------------- The security problems reported about Java exist both in Netscape's Navigator 2.0 and in the Java Devlopment Kit 1.0 from Sun Microsystems. Solutions to both problems are provided below. DNS Attack In January, three students at Princeton University (Drew Dean, Ed Felten, and Dan Wallach) discovered a way to use Java to exploit a well-known Domain Name Service (DNS) vulnerability. Note that this is not a vulnerability with Java, per se. It is really a vulnerability with DNS that Java does not check for. DNS servers provide a means for translating between host names and IP addresses. For example, if a computer on the Internet were to initiate a connection to the machine ciac.llnl.gov, the local DNS server for that machine with resolve the host name as representing the IP address 128.115.19.53. Java applets running under Sun's appletviewer or Netscape's Navigator 2.0 are only allowed to connect the host from which they originated. To allow an applet to connect to other hosts would be dangerous, as the applet would be acting on behalf of the user who downloaded the applet. Imagine downloading an applet from a Web site, only to find that the applet sent mail to another system, acting as you. What's worse, without this restriction, a Java applet would have all the access capabilities your machine does, including accessing hosts behind a firewall. The problem occurs because Java does not completely verify that the information provided by the DNS server is accurate. Thus, if one can corrupt the DNS server, it is possible to trick a Java applet into accessing an arbitrary host. The potential for corrupting the information in DNS servers is a known problem. See, for example, CIAC Bulletin G-14, Domain Name Services Vulnerabilities. CLASSPATH Attack In February, David Hopwood of Oxford University made public another security problem with Java related to the loading of local class libraries. Java provides a class loading capability which allows a Java applet to load a class either from the host it originated from or from the user's local system. Java applets residing on the user's local system are allowed special capabilities such as reading and writing files or executing processes. Either of these tasks can cause serious security problems if not used properly. But, for large Java applets connecting to recognized hosts, the additional functionality provided by placing class libraries on a local system may be warranted. Ordinarily, an applet is restricted to loading applets from the directories specified in the environment variable CLASSPATH. However, Hopwood discovered a way to load class libraries from any readable directory on a user's system. This means that by placing a malicious class file and a dynamic library on the user's system, an attacker can open that system to attack. JavaScript Problems - ------------------- Several different security problems have been identified with JavaScript as well. Some of these vulnerabilities existed only in the public beta distributions made available by Netscape Navigator 2.0. Others still were present in the final release. The various problems reported include the following: (1) Reading a user's URL history list and transmitting it to a remote site. (2) Reading a user's disk cache (containing URLs recently acquired by the Web browser) and sending the information to the Web server. (3) Stealing the e-mail address of the Web user and forging an e-mail message with it. (4) Obtaining a recursive listing of local disk directories. (5) Logging all URL accesses made by a Web browser and transmitting the information to a remote system. Problems (1) and (2) were fixed in the final release of Netscape Navigator 2.0. The other problems were fixed in the latest release, described below. Solutions - --------- Netscape solution In late Februrary, Netscape made a patch available to solve the DNS server problem. On March 14, Netscape released Navigator 2.01, which fixed all of the vulnerabilities described above. It can be found at: http://home.netscape.com Sun Microsystems solution On March 15, Sun released Java Development Kit 1.0.1, which fixed all of the vulnerabilities described above. It can be found at: http://java.sun.com ========================================================================= 2) FIRST Conference Announcement ========================================================================= The Forum of Incident Response and Security Teams (FIRST) is an international organization that brings together a variety of computer security incident response teams. These teams include government agencies, commercial companies, academic organizations and computer vendors. This year the 8th FIRST Conference and Workshop on Computer Security Incident Handling and Response will be held in Santa Clara, CA, July 28-31, 1996. For more information on the conference, please go to: http://ciac.llnl.gov/firstconf ========================================================================= 2) Security and Web Search Engines ========================================================================= By John Fisher A variety of very powerful search engines are available on the Internet, including Netscape (http://home.netscape.com/home/internet-search.html), Yahoo (http://www.yahoo.com), Alta Vista (http://altavista.digital.com), Lycos (http://www.lycos.com), and others. These engines, known as "web crawlers," provide a means for users to find URLs matching keywords. Their databases are populated by gathering up all of the available information provided by any Web server that can be found. The Alta Vista database, for example, contains an index over 30 gigabytes in size. But, perhaps, these search engines have become a little too powerful. Some Web sites have provided a few too many links, including information related to system configuration. For example, doing a search for keywords such as "root", "daemon:", "passwd", etc, will return back a few stray /etc/passwd or /etc/group files, located on systems that have very poor Web configurations. This is a way to quickly find those Web sites that are not maintained very well and are most vulnerable to attack. So, the lesson here, if you maintain a Web site, be very sure of what information you are making available. Make sure no URLs are available which give configuration information about your system. With today's advanced search engines, you may be opening yourself to unnecessary problems. ========================================================================= 2) Microsoft Word Macro Virus Update ========================================================================= By Bill Orvis Here is the latest news on the Microsoft Word Macro Virus: 1. CIAC Bulletin G-10 has been revised to G-10a. 2. It needs to be emphasized that the scanning software from Microsoft only works if you open a document using the File, Open command. It does not work if you double click or drag and drop a document. It may not work if you open an attached document from within a mailer program. 3. The scanning software from Microsoft comes in three versions: mvtool10.exe English version mvtool20.exe International version 1 (defaults to English) mvtool30.exe International version 2 (defaults to English) For English speaking peoples, all three of these scanners will give the same results. 4. The scanner works in Word 6 on the Macointosh as well, but the file mvtool10.exe must be uncompressed on a PC first. Once it is uncompressed, it can be copied to a Macintosh system and loaded into Word. 5. If you save a document in any format that does not have macros, the macros can not be passed on. For example, on an infected machine, saving a file in Macintosh Word 5 format would not pass a macro virus. Safe formats include: Any Macintosh format earlier than 6, rtf, text only, WordPerfect, Word for Windows 1, Word for MS-DOS. Note that you may lose special formatting when converting to some of these other file formats. 6. The Wordview reader (Windows only) can be used to display or print the contents of a Word file. The reader completely ignores any attached macros. This would also be a good choice for use with a mail reader that wants to launch an application to display a formatted document. 7. There is currently no scanner for Excel, and only one known Excel macro virus. ============================================================================ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 510-422-8193 FAX: +1 510-423-8002 STU-III: +1 510-423-2604 E-mail: ciac@llnl.gov For emergencies and off-hour assistance, DOE, DOE contractor sites, and the NIH may contact CIAC 24-hours a day. During off hours (5PM - 8AM PST), call the CIAC voice number 510-422-8193 and leave a message, or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC duty person, and the secondary PIN number, 8550074 is for the CIAC Project Leader. Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://ciac.llnl.gov/ Anonymous FTP: ciac.llnl.gov (128.115.19.53) Modem access: +1 (510) 423-4753 (28.8K baud) +1 (510) 423-3331 (28.8K baud) CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send the following request as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for list-name and valid information for LastName FirstName and PhoneNumber when sending E-mail to ciac-listproc@llnl.gov: subscribe list-name LastName, FirstName PhoneNumber e.g., subscribe ciac-notes OHara, Scarlett W. 404-555-1212 x36 You will receive an acknowledgment containing address, initial PIN, and information on how to change either of them, cancel your subscription, or get help. PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMU9N9LnzJzdsy3QZAQHEeQQAk5QDWeKT8Ce2g8qCfUcERhMGasHrDxRi IFiGW/VEjftINKlnWzs+fPb9ZAhxNsHnItCXkUyuscxu3KDi4pzcL0IfYegWPciS 2f1Anypt6Hs3xStaJhzE5vtBFCYo5mgS3iAG4Olnn5mykZIkhPFOyDDc+DZlvhIQ 1rOn14NhKZw= =VRBp -----END PGP SIGNATURE-----