Date: Fri, 20 Dec 1996 11:03:26 -0800
Message-Id: <199612201903.LAA15013@puffin.eng.sun.com>
From: Marianne Mueller <mrm@eng.sun.com>
To: kocka@ban.junis.ni.ac.yu
> Date: Fri, 20 Dec 1996 13:33:09 +0100
> From: kocka@ban.junis.ni.ac.yu (Dejan Kocic)
>
> Hi,
> My name is Dejan and I have problem with Java security exception when I wont start applet via Netscape.
> What I can do through Netscape ( somethings like read file and etc ).
> Applet work with appletviewer ( I have acl.read="some dir." ) but what I must do to start applet via Netscape.
> Exsackly how I can start network orentied applet via Netscape.
> Thank You
Hi Dejan,
In Netscape Navigator, by default, downloaded applets can't read or
write to the file system.
In appletviewer, or HotJava, applets can access files that are
explicitly labeled as read-able or write-able in the properties file
(as you discovered!)
One workaround is to install your applet locally, in a directory on
the CLASSPATH that is used by Netscape Navigator.
The trouble with this workaround is that someone who downloads your
applet over the net won't be able to use it -- they need to get a copy
of your applet, and install it locally, in a directory on their
CLASSPATH.
We are working on the infrastructure to allow downloaded applets more
access. The idea is that browser users will be able to configure
their system to allow more access to digitally signed applets.
For some other tips and examples, see the Security FAQ at
http://java.sun.com/sfaq. I include a text version of it here, since
it might not be easily accessible for you from Bosnia/Serbia. If you
do have access to the web, check out the new software and
documentation for digital signatures in Java. You can find pointers
to this from http://java.sun.com/security. You will want to download
a copy of JDK 1.1 beta, from http://java.sun.com/products/JDK/1.1.
Marianne
[ JavaSoft, a Sun Microsystems Business ]
What's Java(tm)?[Image]JavaSoft News
Products and Services[Image]Developer's Corner
----------------------------------------------------------------------------
Last modified 12/17/96
Frequently Asked Questions - Applet Security
The goal for the JDK is to enable browsers to run untrusted applets in a
trusted environment. Our approach is to be conservative at first, and to add
functionality when it can be added securely. The intent is to prevent
applets from inspecting or changing files on the client file system. Also,
the intent is to prevent applets from using network connections to
circumvent file protections or people's expectations of privacy.
JDK 1.1 provides the basic technology for loading and authenticating signed
classes. This enables browsers to run trusted applets in a trusted
environment. This does not make obselete the need to run untrusted applets
in a secure way. In the release following JDK 1.1, we will provide tools for
finer-grained control of flexible security policies.
----------------------------------------------------------------------------
Status of all known security-related bugs
Web Spoofing (December, 1996)
The Secure Internet Programming team at Princeton University published
a technical report describing an Internet security attack they name web
spoofing. In this scenario, an attacker
o creates a shadow copy of a web page
o funnels all access to the web page through the attacker's machine
o tricks the unwary consumer into revealing sensitive or private
data, such as PIN numbers, credit card numbers or bank account
numbers
Web spoofing requires that the attacker be able to interpose his
machine between the server and client, in a man-in-the-middle attack.
Web spoofing does not require and does not exploit Java technologies.
Consumers know they are being spoofed when they notice either of these
visual cues in the browser status line:
o When a connection is made, the status line shows which host the
browser is connecting.
o When you hold the mouse over a link, the address you will be taken
to when you click on the link is displayed in the status line.
Granted, some novice internet consumers will not be sensitive to these
visual cues, but others will, and given the nature of the web and how
quickly email bounces around the net, a spoofed web site will be found
out quickly and publicized widely.
JDK 1.1 beta (December 13, 1996)
JDK 1.1 Beta 2 fixes the implementation inconsistency in the javakey
security tool that caused jar files to be signed with invalid
signatures. In JDK 1.1 Beta 1, signature checking always failed, and so
all applets ran as untrusted, with minimal permissions enabled. This
made the code signing feature unusable, but was not a security hole.
Please report anything else you find to
http://java.sun.com/products/JDK/1.1/bugreport.html.
Illegal type cast attack (June 2, 1996)
David Hopwood, a Java researcher in the UK, has uncovered a way to
manipulate the way objects are assigned and the way they collaborate,
in order to undermine the Java type system. Hopwood contacted JavaSoft
directly regarding the bug, and we have had a team working on a fix
from the time that we were notified. We are also applying Hopwood's
model to conduct a security review, to determine if there are other
bugs that may apply. Fixed in JDK 1.1; fixes propagated to all Java
licensees by mid-June 1996
New twist on previous classloader attack (May 18, 1996)
The May 18 edition of the New York Times reported that Ed Felten, Drew
Dean and Dan Wallach of Princeton University's Safe Internet have found
a new way to get past system restrictions on creating a classloader.
This attack builds on work done by Tom Cargill. The applet sandbox
security model states that applets are not allowed to create and use
classloaders to define classes. Once an applet has its own classloader,
it can use it to define and execute classes that would otherwise be
barred from execution. Fixed in JDK 1.0.2, and in Netscape Navigator
3.0b4.
Hostile Applets (April, 1996)
A number of hostile web pages, that host malicious or rude
resource-consuming applets, are popping up on the web. These sites
demonstrate problems related to denial of service attacks. We are
investigating ways to better monitor and control resource consumption
of applets. Here's more details.
URL name resolution attack (April, 1996)
For a specific firewall-protected network configuration, an applet
downloaded from a client inside the firewall would be able to connect
to a single specific host behind the firewall. (It requires an unusual
network configuration, but here are the details.) Fixed in JDK 1.0.2
and in Netscape Navigator 2.02.
Verifier implementation bug (Mar, 1996)
Researchers at Princeton found an implementation bug in the Java
bytecode verifier. The verifier is a part of Java's runtime system
which checks that applets downloaded over the Internet adhere to Java's
language safery rules. Here's our response. Fixed in JDK 1.0.2 and in
Netscape Navigator 2.02.
Class loader implementation bug (Mar, 1996)
David Hopwood at Oxford University found a bug in the class loader that
could be exploited to load illegal byte code, which could then be used
to load a class referenced by an absolute path name. Fixed in Netscape
Navigator 2.01 and in JDK 1.0.1.
DNS attack (Feb, 1996)
Drew Dean, Ed Felten and Dan Wallach from Princeton described an attack
on the applet security model, based on exploiting how the applet
security manager uses DNS for name/IP address resolution. Sun's
response to this security bug was posted to comp.lang.java on Feb 21.
Fixed in Netscape Navigator 2.01 and in JDK 1.0.1.
Steve Gibbons also independently suggested this attack scenario: see
http://www.aztech.net/~steve/java/
JavaScript (Feb, 1996)
JavaScript is a scripting language used with Netscape Navigator 2.0.
There have been reports of privacy problems with JavaScript, and
Netscape is committed to addressing those concerns. JavaScript cannot
be used to invoke Java applets. The privacy problems reported with
JavaScript are not present in Java applets.
----------------------------------------------------------------------------
Applet Security
Applets
1. What are applets prevented from doing?
2. Can applets read or write files?
3. How do I let an applet read a file?
4. How do I let an applet write a file?
5. What system properties can be read by applets, and how?
6. How do I hide system properties that applets are allowed to read by
default?
7. How can I allow applets to read system properties that they aren't
allowed to read by default?
8. How can an applet open a network connection to a computer on the
internet?
9. How can an applet open a network connection to its originating host?
10. How can an applet maintain persistent state?
11. Can an applet start another program running on the client?
12. What features of the Java language help people build secure applets?
13. What is the difference between applets loaded over the net, and applets
loaded via the file system?
14. What's the applet class loader, and what does it buy me?
15. What's the applet security manager, and what does it buy me?
16. Is there a summary of applet capabilities?
17. If other languages are compiled to Java bytecodes, how does that affect
the applet security model?
Examples
Tiny applet examples that demonstrate the security features of your web
browser.
Glossary
Terms used in this FAQ.
See Also
Other references on Java security
----------------------------------------------------------------------------
Applets
1. What are applets prevented from doing?
In general, applets loaded over the net are prevented from reading and
writing files on the client file system, and from making network
connections except to the originating host.
In addition, applets loaded over the net are prevented from starting
other programs on the client. Applets loaded over the net are also not
allowed to load libraries, or to define native method calls. If an
applet could define native method calls, that would give the applet
direct access to the underlying computer.
There are other specific capabilities denied to applets loaded over the
net, but most of the applet security policy is described by those two
paragraphs above. Read on for the gory details.
2. Can applets read or write files?
In Netscape Navigator 2.0, applets cannot read or write files at all.
Sun's appletviewer allows applets to read files that reside in
directories on the access control lists.
If the file is not on the client's access control list, then applets
cannot access the file in any way. Specifically, applets cannot
o check for the existence of the file
o read the file
o write the file
o rename the file
o create a directory on the client file system
o list the files in this file (as if it were a directory)
o check the file's type
o check the timestamp when the file was last modified
o check the file's size
3. How do I let an applet read a file?
Applets loaded into Netscape Navigator 2.0 can't read files.
Sun's appletviewer allows applets to read files that are named on the
access control list for reading. The access control list for reading is
null by default, in the JDK. You can allow applets to read directories
or files by naming them in the acl.read property in your
~/.hotjava/properties file.
Note: The "~" (tilde) symbol is used on UNIX systems to refer
to your home directory. If you install a web browser on your
F:\ drive on your PC, and create a top-level directory named
.hotjava, then your properties file is found in
F:\.hotjava\properties.
For example, to allow any files in the directory home/me to be read by
applets loaded into the appletviewer, add this line to your
~/.hotjava/properties file.
acl.read=/home/me
You can specify one file to be read:
acl.read=/home/me/somedir/somefile
Use ":" to separate entries:
acl.read=/home/foo:/home/me/somedir/somefile
Allowing an applet to read a directory means that it can read all the
files in that directory, including any files in any subdirectories that
might be hanging off that directory.
4. How do I let an applet write a file?
Applets loaded into Netscape Navigator 2.0 can't write files.
Sun's appletviewer allows applets to write files that are named on the
access control list for writing. The access control list for writing is
empty by default.
You can allow applets to write to your /tmp directory by setting the
acl.write property in your ~/.hotjava/properties file:
acl.write=/tmp
You can allow applets to write to a particular file by naming it
explicitly:
acl.write=/home/me/somedir/somefile
Use : to separate entries:
acl.write=/tmp:/home/me/somedir/somefile
Bear in mind that if you open up your file system for writing by
applets, there is no way to limit the amount of disk space an applet
might use.
5. What system properties can be read by applets, and how?
In both Netscape Navigator 2.0 and the appletviewer, applets can read
these system properties by invoking System.getProperty(String key):
key meaning
____________ ______________________________
java.version Java version number
java.vendor Java vendor-specific string
java.vendor.url Java vendor URL
java.class.version Java class version number
os.name Operating system name
os.arch Operating system architecture
file.separator File separator (eg, "/")
path.separator Path separator (eg, ":")
line.separator Line separator
Applets are prevented from reading these system properties:
key meaning
____________ _____________________________
java.home Java installation directory
java.class.path Java classpath
user.name User account name
user.home User home directory
user.dir User's current working directory
To read a system property from within an applet, simply invoke
System.getProperty(key) on the property you are interested in.
For example,
String s = System.getProperty("os.name");
6. How do I hide system properties that applets are allowed to read by
default?
There's no way to hide the above ten system properties from applets
loaded into Netscape Navigator 2.0. The reason is that Netscape
Navigator 2.0 doesn't read any files, as a security precaution,
including the ~/.hotjava/properties file.
From the appletviewer, you can prevent applets from finding out
anything about your system by redefining the property in your
~/.hotjava/properties file. For example, to hide the name of the
operating system that you are using, add this line to your
~/.hotjava/properties file:
os.name=null
7. How can I allow applets to read system properties that they aren't
allowed to read by default?
There's no way to allow an applet loaded into Netscape Navigator 2.0 to
read system properties that they aren't allowed to read by default.
To allow applets loaded into the appletviewer to read the property
named by key, add the property key.applet=true to your
~/.hotjava/property file. For example, to allow applets to record your
user name, add this line to your ~/.hotjava/properties file:
user.name.applet=true
8. How can an applet open a network connection to a computer on the
internet?
Applets are not allowed to open network connections to any computer,
except for the host that provided the .class files. This is either the
host where the html page came from, or the host specified in the
codebase parameter in the applet tag, with codebase taking precendence.
For example, if you try to do this from an applet that did not
originate from the machine foo.com, it will fail with a security
exception:
Socket s = new Socket("foo.com", 25, true);
9. How can an applet open a network connection to its originating host?
Be sure to name the originating host exactly as it was specified when
the applet was loaded into the browser.
That is, if you load an HTML page using the URL
http://foo.state.edu/~me/appletPage.html
then your applet will be able to connect to its host only by using the
name foo.state.edu. Using the IP address for foo.state.edu won't work,
and using a "shorthand" form of the host name, like foo.state instead
of foo.state.edu, won't work.
10. How can an applet maintain persistent state?
There is no explicit support in the JDK applet API for persistent state
on the client side. However, an applet can maintain its own persistent
state on the server side. That is, it can create files on the server
side and read files from the server side.
Interesting examples are
o Chat Touring, by Paul Burchard
o Scribble Forum, a shared scribble pad, by Robert O'Callahan
11. Can an applet start another program on the client?
No, applets loaded over the net are not allowed to start programs on
the client. That is, an applet that you visit can't start some rogue
process on your PC. In UNIX terminology, applets are not allowed to
exec or fork processes. In particular, this means that applets can't
invoke some program to list the contents of your file system, and it
means that applets can't invoke System.exit() in an attempt to kill
your web browser. Applets are also not allowed to manipulate threads
outside the applet's own thread group.
12. What features of the Java language help people build secure applets?
o Java programs do not use pointers explicitly. Objects are accessed
by getting a handle to the object. Effectively, this is like
getting a pointer to an object, but Java does not allow the
equivalent of pointer arithmetic on object handles. Object handles
cannot be modified in any way by the Java applet or application.
o C and C++ programmers are used to manipulating pointers to
implement strings and to implement arrays. Java has high-level
support for both strings and arrays, so programmers don't need to
resort to pointer arithmetic in order to use those data
structures.
o Arrays are bounds-checked at runtime. Using a negative index
causes a runtime exception, and using an index that is larger than
the size of the array causes a runtime exception. Once an array
object is created, its length never changes.
o Strings in Java are immutable. A string is zero or more characters
enclosed in double quotes, and it's an instance of the String
class. Using immutable strings can help prevent common runtime
errors that could be exploited by hostile applets.
o The Java compiler checks that all type casts are legal. Java is a
strongly typed language, unlike C or C++, and objects cannot be
cast to a subclass without an explicit runtime check.
o The final modifier can be used when initializing a variable, to
prevent runtime modification of that variable. The compiler
catches attempts to modify final variables.
o Before a method is invoked on an object, the compiler checks that
the object is the correct type for that method. For example,
invoking
t.currentThread()
when t is not a Thread object causes a compile time error.
o Java provides four access modifiers for methods and variables
defined within classes and makes sure that these access barriers
are not violated.
+ public: a public method is accessible anywhere the class name
is accessible
+ protected: a protected method is accessible by a child of a
class as long as it is trying to access fields in a similarly
typed class. For example,
class Parent { protected int x; }
class Child extends Parent { ... }
The class Child can access the field "x" only on objects that
are of type Child (or a subset of Child.)
+ private: a private method is accessible only within its
defining class
+ default: if no modifier is specified, then by default, a
method is accessible only within its defining package
For example, programmers can choose to implement sensitive
functions as private methods. The compiler and the runtime checks
ensure that no objects outside the class can invoke the private
methods.
13. What is the difference between applets loaded over the net and applets
loaded via the file system?
There are two different ways that applets are loaded by a Java system.
The way an applet enters the system affects what it is allowed to do.
If an applet is loaded over the net, then it is loaded by the applet
class loader, and is subject to the restrictions enforced by the applet
security manager.
If an applet resides on the client's local disk, and in a directory
that is on the client's CLASSPATH, then it is loaded by the file system
loader. The most important differences are
o applets loaded via the file system are allowed to read and write
files
o applets loaded via the file system are allowed to load libraries
on the client
o applets loaded via the file system are allowed to exec processes
o applets loaded via the file system are allowed to exit the virtual
machine
o applets loaded via the file system are not passed through the byte
code verifier
As of 2.0beta4, Netscape Navigator uses the applet class loader to load
applets specified with file: URLs. So, the restrictions and protections
that accrue from the class loader and its associated security manager
are now in effect for applets loaded via file: URLs in NN2.0.
This means that if you specify the URL in the textfield at the top of
Netscape Navigator like so:
Location: file:/home/me/public_html/something.html
and the file something.html contains an applet, Netscape Navigator 2.0
loads it using its applet class loader.
14. What's the applet class loader, and what does it buy me?
Applets loaded over the net are loaded by the applet class loader. For
example, the appletviewer's applet class loader is implemented by the
class sun.applet.AppletClassLoader.
The class loader enforces the Java name space hierarchy. The class
loader guarantees that a unique namespace exists for classes that come
from the local file system, and that a unique namespace exists for each
network source. When a browser loads an applet over the net, that
applet's classes are placed in a private namespace associated with the
applet's origin. Thus, applets loaded from different network sources
are partitioned from each other.
Also, classes loaded by the class loader are passed through the
verifier. The verifier checks that the class file conforms to the Java
language specification - it doesn't assume that the class file was
produced by a "friendly" or "trusted" compiler. On the contrary, it
checks the class file for purposeful violations of the language type
rules and name space restrictions. The verifier ensures that
o There are no stack overflows or underflows.
o All register accesses and stores are valid.
o The parameters to all bytecode instructions are correct.
o There is no illegal data conversion.
The verifier accomplishes that by doing a data-flow analysis of the
bytecode instruction stream, along with checking the class file format,
object signatures, and special analysis of finally clauses that are
used for Java exception handling.
Details on the verifier's design and implementation were presented in a
paper by Frank Yellin at the December 1995 WWW conference in Boston.
A web browser uses only one class loader, which is established at
start-up. Thereafter, the system class loader cannot be extended,
overloaded, overridden or replaced. Applets cannot create or reference
their own class loader.
15. What's the applet security manager, and what does it buy me?
The applet security manager is the Java mechanism for enforcing the
applet restrictions described above. The appletviewer's applet security
manager is implemented by sun.applet.AppletSecurity.
A browser may only have one security manager. The security manager is
established at startup, and it cannot thereafter be replaced,
overloaded, overridden, or extended. Applets cannot create or reference
their own security manager.
16. Is there a summary of applet capabilities?
The following table is not an exhaustive list of applet capabilities.
It's meant to answer the questions we hear most often about what
applets can and cannot do.
Key:
o NN: Netscape Navigator 2.x, loading applets over the Net
o NL: Netscape Navigator 2.x, loading applets from the Local file
system
o AN: Appletviewer, JDK 1.x, loading applets over the Net
o AL: Appletviewer, JDK 1.x, loading applets from the Local file
system
o JS: Java Standalone applications
Stricter ------------------------> Less strict
NN NL AN AL JS
read file in /home/me, no no no yes yes
acl.read=null
read file in /home/me, no no yes yes yes
acl.read=/home/me
write file in /tmp, no no no yes yes
acl.write=null
write file in /tmp, no no yes yes yes
acl.write=/tmp
get file info, no no no yes yes
acl.read=null
acl.write=null
get file info, no no yes yes yes
acl.read=/home/me
acl.write=/tmp
delete file, no no no no yes
using File.delete()
delete file, no no no yes yes
using exec /usr/bin/rm
read the user.name no yes no yes yes
property
connect to port no yes no yes yes
on client
connect to port no yes no yes yes
on 3rd host
load library no yes no yes yes
exit(-1) no no no yes yes
create a popup no yes no yes yes
window without
a warning
17. If other languages are compiled to Java bytecodes, how does that affect
the applet security model?
The verifier is independent of Sun's reference implementation of the
Java compiler and the high-level specification of the Java language. It
verifies bytecodes generated by other Java compilers. It also verifies
bytecodes generated by compiling other languages into the bytecode
format. Bytecodes imported over the net that pass the verifier can be
trusted to run on the Java virtual machine. In order to pass the
verifier, bytecodes have to conform to the strict typing, the object
signatures, the class file format, and the predictability of the
runtime stack that are all defined by the Java language implementation.
----------------------------------------------------------------------------
Examples
None of these examples are malicious - the one line descriptions can be
taken at face value. You can look at the source code for each applet, before
visiting the page that has that applet inside. (The first link in each
example takes you to the source code, and the second link takes you to an
html page that includes the executable content for the example.)
Files:
* Can this applet read files on your system?
* Can this applet obtain information about files on your system?
* Can this applet write a file on your system?
* Can this applet use File.delete() to delete the file named /tmp/foo?
* Can this applet use the unix command /bin/rm to delete the file named
/tmp/foo?
System Properties:
* Can this applet read the ten system properties that applets are allowed
to read by default?
* Can this applet read hidden properties like user.name or user.home?
* Can this applet replace your browser's property file?
Sockets:
* Can this applet connect to port 25 on www.netscape.com?
* Can this applet send data to www.sun.com?
Processes:
* Can this applet kill your browser?
* Can this applet run some program on your computer?
Libraries and name spaces:
* Can this applet load a library on your computer?
* Can this applet create its own class loader?
* Can this applet create a class of its own in the java.net namespace?
Windows:
* What does a window created by an applet look like?
----------------------------------------------------------------------------
Glossary of terms used in this FAQ
Applet
A Java program that is run from inside a web browser. The html page
loaded into the web browser contains an <applet> tag, which tells the
browser where to find the Java .class files. For example,
appletviewer http://foo.com/~jo/coolApplet.html
Standalone Java application
A Java program that is run by invoking the java interpreter. For
example,
java coolApplication
Server
The computer that hosts the web page that contains an applet. The
.class files that make up the applet, and the .html files that
reference the applet, reside on the server. When someone on the
internet connects to a web page that contains an applet, the server
delivers the .class files over the internet to the client that made the
request.
The server is also known as the originating host.
Client
The computer that displays the web page that contains an applet.
The terms server and client are sometimes used to refer to computers,
and are sometimes used to refer to computer programs. For example,
www.sun.com is a server, and the httpd process running on www.sun.com
is its server process. My computer at home is a client, and the web
browser running on my computer at home acts as the client process.
----------------------------------------------------------------------------
See Also
Low-level Security in Java, Frank Yellin, WWW4 Conference, December, 1995
This paper presents the details of the lowest levels of the java
security mechanism. Before any downloaded code is executed, it is
scanned and verified to ensure that it conforms to the specifications
of the virtual machine.
HotJava: The Security Story
This paper from May 1995 (the 1.0alpha3 release of Java nd HotJava)
provides a high-level overview of the security mechanisms, which were
elaborated on for the JDK 1.0 release.
---------------------------------------------------------------------
Copyright © 1996 Sun Microsystems, Inc., 2550 Garcia Ave., [ Java ]
Mtn. View, CA 94043-1100 USA. All rights reserved.
Contact the Java developer community via the newsgroup
comp.lang.java
or JavaSoft technical support via email to
java@java.sun.com.
Send questions or comments about this web site to
webmaster@java.sun.com.