[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Java security (reposted from RISKS)
------------------------------
Date: Fri, 10 Nov 1995 15:45:00 -0800
From: [email protected] (Marianne Mueller)
Subject: regarding Java security
This response was recently posted to comp.lang.java.
Marianne Mueller <[email protected]>, Java Products Group, Sun Microsystems, Inc.
Article 4356 of comp.lang.java:
Path: handler.Eng.Sun.COM!puffin.Eng.Sun.COM!mrm
>From: [email protected] (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."
[email protected] | -- Time Magazine, 3 July 1995