E 57
I 57
|
E 57
E 44
The goal for the JDK is to enable browsers to run untrusted applets in
E 21
D 32
a trusted environment. The approach is to be conservative at first,
E 32
I 32
a trusted environment. Our approach is to be conservative at first,
E 32
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.
D 32
A goal for future releases is to enable loading and authentication
of signed classes. This enables browsers to run trusted applets in a
trusted environment. That will not make obselete the need to run
untrusted applets in a secure way. We are also exploring ways to
expand the functionality of unauthenticated applets, without
compromising security.
E 32
I 32
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.
E 32
D 38
E 38
I 38
E 38
I 35
D 57
E 57
D 38
E 38
D 44
Status of all known security-related bugs
E 44
I 44
D 57
E 57
I 57
E 57
D 56
Status of all known security-related bugs
E 56
I 56
See the chronology page to
check on the status of security-related bugs.
E 56
D 57
E 57
I 57
E 57
E 44
I 38
D 56
E 56
I 42
I 54
D 55
- June 23, 1997 - UW Team Alerts JavaSoft about verifier implementation bug
E 55
I 55
D 56
- June 23, 1997 - UW Team Alerts JavaSoft about verifier implementation bug
E 55
- A team of scientists including Emin Gun Sirer, Sean McDirmid, and
Prof. Brian Bershad at the University of Washington's Department of
Computer Science and Engineering, has been developing a verification
technology for Java bytecodes as part of the Kimera Java Security
Project. The team recently informed JavaSoft that they discovered an
implementation bug in the JavaSoft JDK 1.1.2 verifier. For more
details, see http://java.sun.com/security/23jun97.html
E 54
I 49
- University of Washington Verification System (May 16, 1997)
- A team of researchers at the University of Washington
independently developed a Java(tm) verification system that led to the
discovery of a bug in the JDK 1.1.1 verifier. There are no known
security attacks based on exploiting the bug, but JavaSoft has issued
a fix to licensees. The fix will be available publically in the JDK
1.1.2 release, due out by the end of May, 1997.
I 50
E 50
I 50
Due to the large number of media inquires, additional details about
the University of Washington verifier project are posted at http://java.sun.com/security/UWdetails.html. (May 21, 1997)
E 50
E 49
I 48
- JDK 1.1.1 Signing Flaw, (April 29, 1997)
- The Secure Internet
Programming team at Princeton University notified JavaSoft of a
flaw in the way the Java runtime manages identities of signers.
JavaSoft is testing the fix and plans to ship it to licensees within
48 hours. Full details here.
E 48
I 45
- Privacy hole, related to IP addresses, fixed in May 1996 JDK
1.0.2 (March 17, 1997)
- Recently we've been getting lots of inquires about an alleged privacy attack on the Java
sandbox. The privacy attack is that an applet calls getLocalHost() to
find out the IP address of the computer that it's running on. This is
not a big deal on the open internet, since IP addresses are clearly
well-known and publicized in the internet routing tables. But if the
computer running the applet resides inside a firewall, the IP address
should remain hidden from the visiting applet. This is exactly what
was implemented at JavaSoft about a year go, in time for the May 1996
JDK 1.0.2 release. An applet that calls getLocalHost() will get the
loopback host ("localhost/127.0.0.1") as an answer. This is a generic
handle to the local computer, which does not reveal any private
information that should remain private.
E 45
- Fix Delivered for Virtual Machine bug (March 5, 1997)
- As part of our ongoing internal security audit at JavaSoft, our
engineering team came across a bug in the implementation of the
verifier in the Java Virtual Machine.
Within 24 hours, we investigated the bug and evaluated a fix. We
tested the fix and created a patch for our licensees. As we always
do, we notified our licensees and shipped the patch immediately. We
encourage each of our licensees to include the patch in their products
as soon as possible.
We are aware of no actual attacks involving this bug. It is
important to note that a program written in the Java language and
compiled by a standard compiler cannot access or exploit this bug.
This depends on someone hand-crafting "evil byte code" and trying to
slip it by the verifier. The theoretical attack is complex and
extremely difficult to exploit.
E 42
D 44
- Update on Java Security and ActiveX (February 25, 1997)
E 44
I 44
-
Update on Java Security and ActiveX (February 25, 1997)
E 44
E 38
D 38
E 38
I 38
-
We've received lots of inquiries on the recently publicized
Chaos Computer Club's theoretical hack into Microsoft's ActiveX.
D 39
This well-established hacker organization headquartered in Hamburg
E 39
I 39
This well-established hacker organization, headquartered in Hamburg,
E 39
demonstrated on German television how its members could use an
ActiveX control to theoretically electronically transfer funds from
an individual's bank account without using a personal identification
number or a transaction number.
I 39
E 39
I 39
E 39
Executable code on the Internet is a complex security issue. That's
D 39
why Java was designed from the ground up for complex networked environments,
and our basic architecture takes into account using executable code from
unknown sources. Check out the rest of this document Frequently Asked Questions--Java Security for a full description of the Java security model.
E 39
I 39
why Java was designed from the ground up for complex networked
environments, and our basic architecture takes into account using
executable code from unknown sources. Check out the rest of this
document, Frequently Asked Questions--Java
Security, for a full description of the Java applet security
model.
E 39
D 39
In brief, all Java applets run in a protected space that prohibit
access to local disk. Encryption and certification can be used in
conjunction with applets to add extra levels of security in trusted
or controlled environments--like corporate intranets. JavaSoft
has included digital signature capability in the JDK 1.1, which
shipped February 18, 1997.
E 39
I 39
In brief, all Java applets run in a protected space that prohibits
access to local disk. Encryption and certification can be used in
conjunction with applets to add extra levels of security in trusted or
controlled environments--like corporate intranets. JavaSoft has
included digital signature capability in the Java Development Kit, JDK 1.1, which shipped February 18,
1997.
E 39
D 39
ActiveX uses a different model. Because it allows arbitrary
binary code to be executed, a malicious ActiveX component can
be written to remove or alter files on the user's local disk or
to make connections to other computers without the knowledge or
approval of the user. There is also the risk that a
well-behaved ActiveX component could have a virus attached to
it. Unfortunately, viruses can be encrypted just as easily as
ordinary code.
E 39
I 39
ActiveX uses a different model. Because it allows arbitrary binary
code to be executed, a malicious ActiveX component can be written to
remove or alter files on the user's local disk or to make connections
to other computers without the knowledge or approval of the user.
There is also the risk that a well-behaved ActiveX component could
have a virus attached to it. Unfortunately, viruses can be encrypted
just as easily as ordinary code.
E 39
D 39
In some cases, digital signing is fine alone. In cases where stronger
protection is required, Java allows the alternative of
running untrusted code securely, which is extremely important for the
E 39
I 39
In some cases, digital signing is adequate. In cases where stronger
protection is required, Java allows the alternative of running
untrusted code securely, which is extremely important for the
E 39
Internet.
I 39
E 39
I 39
E 39
The most complete security solution for complex networks like the
D 39
Internet requires not a single security solution, but many.
Unlike ActiveX, Java was designed from the ground up for secure
network computing. Security is fundamental to Java, not bolted on.
E 39
I 39
Internet requires not a single security solution, but many. Unlike
ActiveX, Java was designed from the ground up for secure network
computing. Security is fundamental to Java, not bolted on.
E 39
I 44
E 44
E 38
- 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
E 35
D 18
E 18
I 18
D 20
E 18
I 16
E 20
I 20
D 32
E 32
I 32
E 32
E 20
D 17
The Security Hotline
E 17
I 17
D 18
Status of all known security-related bugs
E 18
I 18
D 32
Status of all known security-related bugs
E 32
I 32
D 35
JDK 1.1 Beta
E 35
I 35
- creates a shadow copy of a web page
E 35
E 32
E 18
E 17
D 20
E 20
E 16
I 12
I 32
D 34
There is a implementation inconsistency in the javakey security
E 34
I 34
D 35
December 9, 1996 -- There is a implementation inconsistency in the javakey security
E 34
tool that causes jar files to be signed with invalid
signatures. This means that signature checking will always
fail, thus all applets will run as untrusted, with minimal
D 33
permissions enabled. This makes code signing feature unusable,
E 33
I 33
permissions enabled. This makes the code signing feature unusable,
E 33
but it is not a security hole. We are working on a fix for
this, and we will let you know within 24 hours when this fix
will be made available.
E 35
I 35
- funnels all access to the web page through the attacker's machine
E 35
I 35
- tricks the unwary consumer into revealing sensitive or private
data, such as PIN numbers, credit card numbers or bank account numbers
E 35
E 32
I 31
E 31
I 20
I 31
D 32
There are at present no known security-related bugs for which fixes
have not been propagated to all Java licensees. -- November, 1996
E 32
I 32
D 35
Please report anything else you find to http://java.sun.com/products/JDK/1.1/bugreport.html.
E 35
I 35
Web spoofing requires that the attacker be able to interpose his
machine between the server and client, in a man-in-the-middle attack.
E 35
E 32
I 32
D 35
Check here for more information on the availability of this release.
E 35
I 35
Web spoofing does not require and does not exploit Java technologies.
I 40
E 40
D 40
Consumers know they are being spoofed when they notice either of these visual
cues in the browser status line:
E 40
E 35
I 40
If consumers are using a browser that does not have JavaScript
(LiveScript) enabled, they will be able to tell that they are being
spoofed when they notice either of these visual cues in the browser
status line:
E 40
D 35
E 35
I 35
E 35
D 35
Status of all known security-related bugs
E 35
I 35
- When a connection is made, the status line shows which host the
browser is connecting.
E 35
I 35
- 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.
E 35
E 32
E 31
E 20
D 16
What's New
E 16
D 35
E 35
I 35
E 35
I 26
I 32
D 35
- JDK 1.1 beta (December, 1996)
E 35
I 35
D 40
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.
E 40
I 40
If consumers use a browser with JavaScript (LiveScript) enabled, then
even these rudimentary and subtle alerts can be hidden by a malicious
script. Recall that such scripts are not written in Java, and are not
subject to the Java security model. In that case, consumers would
have no way of noticing the spoofing. For this reason, people
concerned about web spoofing attacks might consider disabling
scripting languages.
E 40
E 35
D 35
- We are testing a fix for the inconsistency described above and
will post the fix when testing completes.
E 35
I 35
I 40
Note that in any case, some novice internet consumers will not be
sensitive to visual cues, even if they aren't obliterated by scripting
languages. However, it is often the case on the internet that web
spoofing attacks are noticed quickly and given wide publicity. Given
the nature of the web and how quickly email bounces around the net,
there is strong likelihood that a spoofed web site will be found out
quickly and publicized widely.
E 40
E 35
I 35
- JDK 1.1 beta (December 13, 1996)
-
D 44
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.
E 44
I 44
D 51
JDK 1.1
E 51
I 51
JDK 1.1
E 51
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.
E 44
E 35
I 35
D 44
Please report anything else you find to http://java.sun.com/products/JDK/1.1/bugreport.html.
E 44
I 44
Please report anything else you find to
http://java.sun.com/products/JDK/1.1/bugreport.html.
E 51
I 51
href="/products/jdk/1.1/bugreport.html">
http://java.sun.com/products/jdk/1.1/bugreport.html.
E 51
E 44
E 35
E 32
- 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.
D 31
We are currently thoroughly testing the fix, and plan to issue the fix
to Java licensees as soon as possible.
E 31
I 31
Fixed in JDK 1.1; fixes propagated to all Java licensees by mid-June 1996
E 31
E 26
I 24
- 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
D 25
way to get past system restrictions on creating a classloader. 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.
E 25
I 25
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.
E 25
E 24
I 23
- 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
D 47
of applets. Here's more Here are more details.
E 23
I 16
D 17
- Domain-name-spoofing 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. )
E 17
I 17
- URL name resolution attack (April, 1996)
E 17
E 16
I 17
- For a specific firewall-protected network configuration, an applet
downloaded from a client inside the firewall would be able to connect
D 21
to a single specific host behind the firewall. (It requires an unusual
E 21
I 21
to a single specific host behind the firewall. (It requires an unusual
E 21
network configuration, but here are the
D 21
details.)
E 21
I 21
details.) Fixed in JDK 1.0.2 and in Netscape Navigator 2.02.
E 21
I 21
E 21
E 17
I 14
- Verifier implementation bug (Mar, 1996)
D 15
- Researchers at Princeton recently found an implementation bug in the Java bytecode Verifier. The Verifier is a part of Java's runtime system which certifies that applets downloaded over the Internet adhere to Java's laguage safety rules. Here's our response.
E 15
I 15
D 17
- Researchers at Princeton recently found an implementation bug in the Java bytecode Verifier. The Verifier is a part of Java's runtime system which certifies that applets downloaded over the Internet adhere to Java's language safety rules. Here's our response.
E 17
I 17
D 44
- Researchers at Princeton found an
E 44
I 44
- Researchers at
Princeton found an
E 44
implementation bug in the Java bytecode verifier. The verifier is a
part of Java's runtime system which checks that applets downloaded
D 21
over the Internet adhere to Java's language safery rules. Here's our
response.
E 21
I 21
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.
E 21
E 17
E 15
I 17
E 17
I 17
- Class loader implementation bug (Mar, 1996)
E 17
I 17
D 30
- David Hopwood at Oxford
E 30
I 30
D 44
- David Hopwood at Oxford
E 30
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.
E 44
I 44
- 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.
E 44
D 18
E 18
I 18
D 20
<
E 20
I 20
E 20
E 18
E 17
E 14
- DNS attack (Feb, 1996)
D 13
- Researchers at
Princeton described an attack on the applet security model, based
on exploiting how the applet security manager uses DNS for name/IP
address resolution. 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
E 18
I 18
D 44
href="/java.sun.com/people/mrm/dns_spoofing.html">Sun's
E 44
I 44
href="/people/mrm/dns_spoofing.html">Sun's
E 44
E 18
response to this security bug was posted to comp.lang.java on Feb
D 17
21. Netscape has made a patch
available for people using Netscape Navigator 2.0.
I 13
E 17
I 17
D 20
21. Fixed in Netscape Navigator 2.01 and in JDK 1.0.1.
E 20
I 20
21. Fixed in Netscape Navigator 2.01 and in JDK 1.0.1.
E 20
E 17
Steve Gibbons also independently suggested this attack scenario: see
http://www.aztech.net/~steve/java/
E 13
- 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.
E 56
I 39
E 39
D 18
E 18
I 18
D 20
E 20
I 20
D 44
E 44
E 20
E 18
I 44
D 57
E 57
I 57
E 57
E 44
D 18
Applet Security
E 18
I 18
D 57
Applet Security
E 57
I 57
Applet Security
E 57
E 18
D 39
E 39
I 39
E 39
E 12
D 10
- Applets
E 10
I 10
- Applets
E 10
D 10
- What are applets prevented from doing?
- Can applets read or write files?
- How do I let an applet read a file?
- How do I let an applet write a file?
- What system properties can be read by applets, and how?
- How do I hide system properties that applets are allowed to read by default?
- How can I allow applets to read system properties that they aren't allowed to read by default?
- How can an applet open a network connection to a computer on the internet?
- How can an applet open a network connection
E 10
I 10
- What are applets prevented from doing?
- Can applets read or write files?
- How do I let an applet read a file?
- How do I let an applet write a file?
- What system properties can be read by applets, and how?
- How do I hide system properties that applets are allowed to read by default?
- How can I allow applets to read system properties that they aren't allowed to read by default?
- How can an applet open a network connection to a computer on the internet?
- How can an applet open a network connection
E 10
to its originating host?
D 10
- How can an applet maintain persistent state?
- Can an applet start another program running on the client?
- What features of the Java language help people build secure applets?
- What is the difference between applets loaded over the net,
E 10
I 10
- How can an applet maintain persistent state?
- Can an applet start another program running on the client?
- What features of the Java language help people build secure applets?
- What is the difference between applets loaded over the net,
E 10
and applets loaded via the file system?
D 10
- What's the applet class loader, and what does it buy me?
- What's the applet security manager, and what does it buy me?
E 10
I 10
- What's the applet class loader, and what does it buy me?
- What's the applet security manager, and what does it buy me?
E 10
D 10
- Is there a summary of applet capabilities?
E 10
I 10
- Is there a summary of applet capabilities?
E 10
D 10
- If other languages are compiled to Java
E 10
I 10
- If other languages are compiled to Java
E 10
bytecodes, how does that affect the applet security model?
D 10
- Examples
E 10
I 10
- Examples
E 10
- Tiny applet examples that demonstrate the security features of your web browser.
D 10
- Glossary
E 10
I 10
- Glossary
E 10
- Terms used in this FAQ.
I 6
D 10
- See Also
E 10
I 10
- See Also
E 10
- Other references on Java security
E 6
D 18
E 18
I 18
D 20
E 20
I 20
D 44
E 44
I 44
E 44
E 20
E 18
D 18
E 18
I 18
D 57
E 57
I 57
E 57
E 18
D 19
- What are applets prevented from doing?
E 19
I 19
- What are applets prevented from doing?
E 19
D 10
In general, applets loaded over the net are
E 10
I 10
In general, applets loaded over the net are
E 10
prevented from reading and writing files on the client file system, and from making network
connections except to the originating
E 10
I 10
href="#client">client file system, and from making network
connections except to the originating
E 10
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.
D 19
- Can applets read or write files?
E 19
I 19
- Can applets read or write files?
E 19
D 43
In Netscape Navigator 2.0, applets cannot read or write files at
E 43
I 43
D 62
In Java-enabled browsers, applets cannot read or write files at
E 43
all.
E 62
I 62
In Java-enabled browsers, untrusted applets cannot read or write files at
all. By default, downloaded applets are considered untrusted. There are
two ways for an applet to be considered trusted:
E 62
I 62
- The applet is installed on the local hard disk, in a directory
on the CLASSPATH used by the program that you are using to run the
applet. Usually, this is a Java-enabled browser, but it could be
the appletviewer, or other Java programs that know how to load applets.
- The applet is signed by an identity marked as trusted in your
identity database. For more information on signed applets, refer to
an example of using signed applets, and
to a short description on using javakey.
E 62
I 62
E 62
D 21
Sun's JDK 1.0 appletviewer allows applets to read files that reside in
E 21
I 21
Sun's appletviewer allows applets to read files that reside in
E 21
D 19
directories on the access control lists.
E 19
I 19
directories on the access control lists.
E 19
If the file is not on the client's access control list, then applets
cannot access the file in any way. Specifically, applets cannot
- check for the existence of the file
- read the file
- write the file
- rename the file
- create a directory on the client file system
- list the files in this file (as if it were a directory)
- check the file's type
- check the timestamp when the file was last modified
- check the file's size
D 19
- How do I let an applet read a file?
E 19
I 19
- How do I let an applet read a file?
E 19
D 43
Applets loaded into Netscape Navigator 2.0 can't read files.
E 43
I 43
Applets loaded into a Java-enabled browser can't read files.
E 43
Sun's appletviewer allows applets to read files that are named on the
access control list for reading. The access control list for reading
D 11
is null by default (in JDK 1.0beta2 and later.) You can allow applets
E 11
I 11
D 21
is null by default (in JDK 1.0 and in JDK1.0beta2.) You can allow applets
E 21
I 21
is null by default, in the JDK. You can allow applets
E 21
E 11
to read directories or files by naming them in the
acl.read property in your
~/.hotjava/properties file.
I 3
D 19
Note: The "~ " (tilde) symbol is used on UNIX
E 19
I 19
Note: The "~ " (tilde) symbol is used on UNIX
E 19
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 .
E 3
D 10
For example, to allow any files in the directory home/mrm
E 10
I 10
For example, to allow any files in the directory home/me
E 10
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
D 19
Use ":" to separate entries:
E 19
I 19
Use ":" to separate entries:
E 19
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.
D 19
- How do I let an applet write a file?
E 19
I 19
- How do I let an applet write a file?
E 19
D 43
Applets loaded into Netscape Navigator 2.0 can't write files.
E 43
I 43
Applets loaded into a Java-enabled browser can't write files.
E 43
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
D 19
Use : to separate entries:
E 19
I 19
Use : to separate entries:
E 19
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.
D 19
- What system properties can be read by applets, and how?
E 19
I 19
- What system properties can be read by applets, and how?
E 19
D 43
In both Netscape Navigator 2.0 and the appletviewer, applets can read
E 43
I 43
In both Java-enabled browsers and the appletviewer, applets can read
E 43
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
I 36
os.version Operating system version
E 36
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");
D 19
- How do I hide system properties that applets
are allowed to read by default?
E 19
I 19
- How do I hide system properties that applets
are allowed to read by default?
E 19
There's no way to hide the above ten system properties from applets
D 43
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.
E 43
I 43
loaded into a Java-enabled browser. The reason is that the browsers
don't consult any external files as part their Java configuration, as
a security precaution, including the
~/.hotjava/properties file.
E 43
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
D 19
- How can I allow applets to read system
properties that they aren't allowed to read by default?
E 19
I 19
- How can I allow applets to read system
properties that they aren't allowed to read by default?
E 19
D 43
There's no way to allow an applet loaded into Netscape Navigator 2.0
E 43
I 43
There's no way to allow an applet loaded into a Java-enabled browser
E 43
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
D 19
- How can an applet open a network connection to a
computer on the internet?
E 19
I 19
- How can an applet open a network connection to a
computer on the internet?
E 19
D 3
Applets are not allowed to open network connections to any host that
provided the .class files. This is eitehr the host where the html
page came from, or the host specified in the codebase
parameter in the applet tag, with codebase
taking precendence.
E 3
I 3
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.
E 3
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);
D 19
- How can an applet open a network connection
to its originating host?
E 19
I 19
- How can an applet open a network connection
to its originating host?
E 19
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.
D 19
- How can an applet maintain persistent state?
E 19
I 19
- How can an applet maintain persistent state?
E 19
D 21
There is no explicit support in the JDK 1.0 applet API for persistent
E 21
I 21
There is no explicit support in the JDK applet API for persistent
E 21
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
D 7
- CUPPA, Chat Up Plenty O' People applet, by Paul Burchard
E 7
I 7
D 8
- CUPPA, Chat Touring, by Paul Burchard
E 8
I 8
- Chat Touring, by Paul Burchard
E 8
E 7
- Scribble
Forum, a shared scribble pad, by Robert O'Callahan
D 8
Although the CUPPA page says that its multiuser chat room shouldn't be
allowed by the applet security policy, actually, it's fine - there's
no violation of the security policy here.
E 8
D 19
- Can an applet start another program on the
client?
E 19
I 19
- Can an applet start another program on the
client?
E 19
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.
D 19
- What features of the Java language help people
build secure applets?
E 19
I 19
- What features of the Java language help people
build secure applets?
E 19
D 19
- What is the difference between applets loaded
over the net and applets loaded via the file system?
E 19
I 19
- What is the difference between applets loaded
over the net and applets loaded via the file system?
E 19
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
- applets loaded via the file system are allowed to read and write files
- applets loaded via the file system are allowed to load libraries on the client
- applets loaded via the file system are allowed to exec processes
- applets loaded via the file system are allowed to exit the virtual machine
- applets loaded via the file system are not passed through the byte code verifier
D 9
For these reasons, Netscape Navigator 2.0 does not load applets via
file: URLs.
E 9
I 9
D 43
As of 2.0beta4, Netscape Navigator uses the applet class loader to
E 43
I 43
Java-enabled browsers use the applet class loader to
E 43
load applets specified with file: URLs. So, the restrictions and
protections that accrue from the class loader and its associated
D 43
security manager are now in effect for applets loaded via file: URLs
in NN2.0.
E 43
I 43
security manager are now in effect for applets loaded via file: URLs.
E 43
E 9
I 43
E 43
I 9
E 9
D 43
This means that if you specify the URL in the textfield at the top of
Netscape Navigator like so:
E 43
I 43
This means that if you specify the URL like so:
E 43
Location: file:/home/me/public_html/something.html
D 9
and the file something.html contains an applet, Netscape Navigator 2.0 won't
load it. You need to specify the URL using the http protocol, like so:
Location: http://someserver/~me/something.html
E 9
I 9
D 43
and the file something.html contains an applet, Netscape Navigator 2.0 loads
E 43
I 43
and the file something.html contains an applet, the browser loads
E 43
it using its applet class loader.
E 9
D 19
- What's the applet class loader, and what does it buy me?
E 19
I 19
- What's the applet class loader, and what does it buy me?
E 19
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
- There are no stack overflows or underflows.
- All register accesses and stores are valid.
- The parameters to all bytecode instructions are correct.
- 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.
D 5
Details on the verifier's design and implementation were presented in
a paper by Frank Yellin at the December 1995 WWW conference in Boston.
E 5
I 5
D 10
Details on the verifier's design and
E 10
I 10
Details on the verifier's design and
E 10
implementation were presented in a paper by Frank Yellin at the
December 1995 WWW conference in Boston.
E 5
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.
D 19
- What's the applet security manager, and what
does it buy me?
E 19
I 19
- What's the applet security manager, and what
does it buy me?
E 19
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.
D 19
- Is there a summary of applet capabilities?
E 19
I 19
- Is there a summary of applet capabilities?
E 19
The following table is not an exhaustive list of applet capabilities.
It's meant to answer the questions we hear most often about what
D 3
applets can and cannot do. Send in your suggestion for an
applet capability that we should list explicitly in this table.
E 3
I 3
applets can and cannot do.
E 3
Key:
D 11
- NN: Netscape Navigator 2.0beta, loading applets over the Net
- NL: Netscape Navigator 2.0beta, loading applets from the Local file system
- AN: Appletviewer, JDK beta, loading applets over the Net
- AL: Appletviewer, JDK beta, loading applets from the Local file system
E 11
I 11
D 19
- NN: Netscape Navigator 2.0, loading applets over the Net
- NL: Netscape Navigator 2.0, loading applets from the Local file system
- AN: Appletviewer, JDK 1.0, loading applets over the Net
- AL: Appletviewer, JDK 1.0, loading applets from the Local file system
E 11
- JS: Java Standalone applications
E 19
I 19
D 21
- NN: Netscape Navigator 2.0, loading applets over the Net
- NL: Netscape Navigator 2.0, loading applets from the Local file system
- AN: Appletviewer, JDK 1.0, loading applets over the Net
- AL: Appletviewer, JDK 1.0, loading applets from the Local file system
E 21
I 21
D 58
- NN: Netscape Navigator 2.x, loading applets over the Net
- NL: Netscape Navigator 2.x, loading applets from the Local file system
E 58
I 58
- NN: Netscape Navigator 4.x, loading unsigned applets over the Net
- NL: Netscape Navigator 4.x, loading unsigned applets from the Local file system
E 58
- AN: Appletviewer, JDK 1.x, loading applets over the Net
- AL: Appletviewer, JDK 1.x, loading applets from the Local file system
E 21
- JS: Java Standalone applications
E 19
Stricter ------------------------> Less strict
NN NL AN AL JS
D 3
read file, no no no yes yes
E 3
I 3
read file in /home/me, no no no yes yes
E 3
acl.read=null
D 3
read files in no no yes yes yes
/tmp and ~/public_html
read file, no no yes yes yes
E 3
I 3
read file in /home/me, no no yes yes yes
E 3
acl.read=/home/me
D 3
write file, no no no yes yes
E 3
I 3
write file in /tmp, no no no yes yes
E 3
acl.write=null
D 3
write file, no no yes yes yes
E 3
I 3
write file in /tmp, no no yes yes yes
E 3
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
D 3
read system no no no yes yes
properties
E 3
I 3
read the user.name no yes no yes yes
property
E 3
D 58
connect to port no yes no yes yes
E 58
I 58
connect to port no no no yes yes
E 58
on client
D 58
connect to port no yes no yes yes
E 58
I 58
connect to port no no no yes yes
E 58
on 3rd host
load library no yes no yes yes
I 3
exit(-1) no no no yes yes
E 3
D 3
exit(-1) no yes no yes yes
E 3
I 3
create a popup no yes no yes yes
window without
a warning
E 3
D 3
E 3
D 19
- If other languages are compiled to Java
bytecodes, how does that affect the applet security model?
E 19
I 19
- If other languages are compiled to Java
bytecodes, how does that affect the applet security model?
E 19
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.
D 18
E 18
I 18
D 20
E 20
I 20
D 44
E 44
I 44
E 44
E 20
D 57
E 57
I 57
E 57
E 18
I 18
E 18
I 18
E 18
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.)
I 3
E 3
Files:
System Properties:
Sockets:
Processes:
Libraries and name spaces:
Windows:
D 18
E 18
I 18
D 20
E 20
I 20
D 44
E 44
I 44
E 44
E 20
E 18
D 18
Glossary of terms used in this FAQ
E 18
I 18
D 57
Glossary of terms used in this FAQ
E 57
I 57
Glossary of terms used in this FAQ
E 57
E 18
- 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.
I 6
D 18
E 18
I 18
D 20
E 20
I 20
D 44
E 44
I 44
E 44
E 20
E 18
D 18
E 18
I 18
D 57
E 57
I 57
E 57
E 18
D 10
- Low-level Security in Java, Frank
E 10
I 10
- Low-level Security in Java, Frank
E 10
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.
D 10
- HotJava: The
E 10
I 10
D 30
- HotJava: The
E 30
I 30
- HotJava: The
E 30
E 10
Security Story
D 46
- This paper from May 1995 (the 1.0alpha3 release of Java nd
E 46
I 46
- This paper from May 1995 (the 1.0alpha3 release of Java and
E 46
HotJava) provides a high-level overview of the security mechanisms,
D 29
which were elaborated on for the current beta JDK release
E 29
I 29
D 30
which were elaborated on for the JDK 1.0 release.
E 30
I 30
which were elaborated on for the JDK 1.0 release.
E 30
E 29
E 6
I 18
D 27
E 27
I 27
D 57
E 57
E 27
E 18
D 3
E 3
I 3
D 18
   
E 18
I 18
D 19
E 19
I 19
D 57
E 57
I 57
E 57
E 19
E 18
E 3
I 3
D 18
E 18
I 18
D 57
E 57
I 57
E 57
D 57
D 36
Copyright © 1996 Sun Microsystems, Inc., 2550 Garcia Ave., 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.
E 36
I 36
D 37
Copyright © 1996 Sun Microsystems, Inc., 2550 Garcia Ave., 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.
E 37
I 37
D 53
Copyright © 1996 Sun Microsystems, Inc., 2550 Garcia Ave., 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 email addresses. Send questions or comments about this web site to webmaster@java.sun.com.
E 53
I 53
Copyright © 1996 Sun Microsystems, Inc., 2550 Garcia Ave., 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 email addresses. Send questions or comments about this web site to webmaster@java.sun.com.
E 53
E 37
E 36
E 57
I 57
|
See Also
Security Top
Security Bug Chronology
D 59
D 61
Security Q&A Archive
E 61
I 61
Security Q&A Archive
E 61
E 59
I 59
Security Q&A Archive
E 59
This page last modified %G%
E 57
|
D 57
D 28
E 28
I 28
D 44
E 44
I 44
E 44
E 28
E 18
E 57
I 57
|
E 57
D 18
E 18
I 18
D 57
E 57
E 18
I 57
|
E 57
D 18
E 18
I 18
D 27
E 27
I 27
D 44
E 27
E 18
E 44
D 18
Copyright ©
1995 Sun Microsystems, Inc., 2550 Garcia Ave., Mtn. View, CA
94043-1100 USA. All rights reserved.
For Java technical support, see the newsgroup comp.lang.java or send mail to java@java.sun.com. For problems
with this web site, send mail to webmaster@java.sun.com.
E 18
I 18
E 18
E 3
E 1
|