------------------------------ Date: Fri, 10 Nov 1995 15:45:00 -0800 From: Marianne.Mueller@eng.sun.com (Marianne Mueller) Subject: regarding Java security This response was recently posted to comp.lang.java. Marianne Mueller <mrm@eng.sun.com>, Java Products Group, Sun Microsystems, Inc. Article 4356 of comp.lang.java: Path: handler.Eng.Sun.COM!puffin.Eng.Sun.COM!mrm
From: mrm@puffin.Eng.Sun.COM (Marianne Mueller) Newsgroups: comp.lang.java Subject: Re: PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE Date: 9 Nov 1995 00:50:27 GMT Organization: Sun Microsystems, Inc. Mt. View, Ca. Keywords: alpha3 hotjava security
The paper written by the two students at Princeton describes possible attacks on the alpha3 HotJava browser, which have all been fixed in JDK beta. Granted, until this week, the source code for JDK beta wasn't available, so it's understandable that they analyzed the alpha3 source base. We understand people need more information on the security model, and we're taking time right now to document the security story more rigorously. A security FAQ, an updated whitepaper, detailed user documentation and detailed implementor's documentation are all being worked on. The Java security mechanisms include: Java language mechanisms * no pointers * private interfaces, classes and methods * class loader that enforces namespace divisions * runtime byte code verifier that enforces language type rules and name space divisions Browser mechanisms, used by JDK beta appletviewer and by Netscape Navigator 2.0beta * AppletSecurity: extends java.lang.SecurityManager; strict applet checks * AppletClassLoader: extends java.lang.ClassLoader; strict class loading The goal for JDK beta is to enable browsers to run untrusted applets in a trusted environment. The approach is to be conservative at first, and to add functionality when it can be added securely. So, JDK beta applets (and Netscape 2.0beta applets) may not do the following. 1. Files: Access Control Lists are greatly restricted in beta, as compared to the situation in the alpha3 HotJava browser. ACLs are initialized - only once - by the applet security manager, and are not user configurable. For a file not on the access control list, an applet cannot - check for the existence of the file - read the file - write the file - check the file type - check if the file is a directory - check the timestamp when the file was last modified - check the file's size - create a directory - rename the file - list the files in this file (as if it were a directory) Applets cannot - create a FileInputStream - create a RandomAccessFile, either for reading or writing - Open file descriptors 2. Sockets: Applets cannot - Create socket connections other than to its own host - Create a socket factory 3. Loading/linking: Applets cannot - Create class loaders - Access a package in the sun.* hierarchy - Define a new class in the java.* hierarchy - Link dynamic libraries using System.loadLibrary() - Disable or override the AppletSecurityManager 4. Process control: Applets cannot - Define native methods - Fork processes - Manipulate threads or thread groups outside of the applet's thread group - Exit the virtual machine (e.g., the browser or the appletviewer) 5. awt: Applets cannot - Create toplevel windows that don't have a warning banner Applets can use network connections only to connect to the host they originate from, to download files that are part of the applet's implementation. Those files might be java bytecode class files, or they might be input files used by the applet (GIF, JPEG, audio, other data files.) Taking a look at the specific attacks mentioned in the paper - alpha3 HotJava JDK ---------------------- --- 1. socket accept() and applets cannot use listen() aren't protected accept() and listen() adequately, allowing a browser to eavesdrop 2. applets can connect to applets cannot connect the SMTP (mail) port on to the SMTP port on some web server and use the computer the applet that as a covert channel is visiting 3. InetAddress.getByName() applets cannot use is public and does not InetAddress to inquire check the security mode about hosts they are before making DNS request not already allowed to connect to 4. applets can use DNS to applets may not get the create a covert channel internet address of any host 5. Access Control Lists (ACLs) ACLs are greatly restricted for reading and writing in JDK beta. files are not strict enough Reading/writing files is disabled for web browsers, such as Netscape Navigator 2.0. 6. applets can use the System.getenv() is obsolete System.getenv() method and is not part of the JDK to gather information about API the computer that it is running on 7. applets can change the applets cannot read or alter property manager database client properties 8. applets can change the The fields that hold the HTTP and FTP proxy server HTTP and FTP proxy names are private. The values are stored in a property manager database that an applet cannot read or write. It's very difficult, if not impossible, for a web browser to completely prevent denial of service attacks. The JDK applet API doesn't claim to prevent denial of service attacks. A "denial of service" attack is where someone writes an applet whose goal is to consume all available resources on your computer, forcing you to kill the browser you're running. For example, someone could write an applet that creates a million pop-up windows. The windows don't do anything, but creating a million of them might use up all the virtual memory on your computer and you'd have to kill the web browser to reclaim the virtual memory. Before people engage in too much wailing and gnashing of teeth about how applets have been too severely restricted - We want to enable applets to do interesting things, including making socket connections, and reading and writing to the file system. One way to enable that is to used a signed class loader. When a trusted applet is loaded, then the applet could be granted permission to do some of the things they are prevented from doing by default. The goal is to ensure that untrusted applets can't steal or damage information on a computer running a Java-enabled browser. Later, we can allow trusted applets to do things that untrusted applets are not allowed to do. Since an implementation bug in a trusted applet could open a loophole that could be exploited by an untrusted applet, design matters. Marianne Java Products Group http://java.sun.com/people/mrm/ ------------------------------ ------------------------------------------------------------------------- Steven Weller | "The Internet, of course, is more +1 415 390 9732 | than just a place to find pictures | of people having sex with dogs." stevenw@best.com | -- Time Magazine, 3 July 1995