 |
|
|
|
|
|
|
The following securiy holes are directly related
with Java. While it is easy to write resource consuming applets and disguising
applets, it is difficult to write implementation-bug exploiting appelts
since it needs technically adept knowledge.
Java has few provision to prevent hostile applets from consuming all the available resources. The possible denial of service attacks are to consume CPU cycles, to allocate memory or thread until system runs out. Another attacks are to open a large number of windows which will crash the machine, and to create very large windows disabling theconsole which will make an user do nothing. An applet can annoy an user by playing background sounds endlessly or making the browser visit a given web site over and over popping up a new copy of the browser each time.
A collection of hostile applets and source codes are available in the Hostile Applets Home Page.
A possible solution to this problem is to monitor and control the use
of resources by Java classes. For example, the browser could enforce some
automatic limits, and the user could selectively override the built-in
limits.
The following applets can be distinguished from resource consuming applets in that these applets don't reveal their purpose. It is not easy to detect them and restrict them by the limits on resourses.
A rogue applet can learn the names of all applets running in the system. In addition, an applet could call the stop() or setPriority() methods on threads in other applets.
Netscape Navigator 4.0 prevents an attacker from seeing threads belonging
to applets on other web pages. Internet Explorer allows an applet to see
those threads, but calls to stop() or setPriority() have
no effect.
Java packages are normally named java.io, java.net. The runtime system replaces each "." with "/". And then this modified name is used to locate the package. The language prohibits "." from being the first character in a package name.
David Hopwood noted that if the first character of a package name was "/", the java runtime system would attempt to load code from an absolute path. An attaker's code loaded like this would be treated as trusted, since it came from the local system rather than from the network.
The language prohibits "/" from being the first character in a package
name.
The Secure Internet Programming
team at Princeton University found an
implementation bug in the Java bytecode verifier. An applet could create
and use classloaders to define classes by exploiting this implementation
bug.
Tom Cargil noted that Java's
interface feature could be used to call private methods.
This worked because all methods declared
in an interface are public, and a class was allowed to
implement an interface by inheriting a private method from its
parent.
The Secure Internet Programming
team at Princeton University discovered that under certain
circumstances an applet could define a class that had one of these
special names. The system detected this and threw an exception, but the
malicious definition was mistakenly left in one of the system's internal
tables. The result was that an applet could redefine one of Java's array
types. This was sufficient to break Java's type system and hence to completely
circumvent Java's security mechanisms. This bug affected Netscape Navigator
version 3.0 beta 5 and earlier.
The Secure Internet Programming
team at Princeton University found that the pre-release versions of Internet
Explorer 3.0 did not separeate packages with the same name loaded from
different origins. An applet could declare classes belonging to system
packages such as java.lang. These classes would be accepted due
to an error in the SecurityManager's method that was supposed
to prevent this. As a result, an applet could access package-scope variables
and methods of system packages.
The Secure Internet Programming team at Princeton University discovered a bug in the way the Java runtime manages identities of signers. By exploiting this bug, an hostile applet will scan through the list of trusted signatures and impersonate one of them, since the unprivileged, but signed, applet can act as if it were signed by anybody.
This bug is fixed in the JDK 1.1.2. The Netscape and Microsoft browsers
are not affected, since they do not currently support the JDK 1.1 code-signing
API.
A research group of Kimera project at University of Washington announced a list of verifier bugs in April, 1997, as part of a research effort developing automatic Java(tm) verification services.
JavaSoft summarized the verifier bugs as follows:
Non-Java Security Holes
The following security holes are not directly related to Java, but might
be used as part of a Java attack applet.
An applet was allowed to connect to any of the IP addresses associated with the name of the server where it originated. However, it did not enforce the rule that an applet can connect only to the server. Since a computer on the internet has been able to advertise a false IP address for itself through an untrusted DNS server, an applet could be allowed to connect to any other host whose IP address is the same as a false IP address for itself. A senario of DNS Spoofing attack is available.
The Java system fixed this problem by allowing the applet to connect
to the exact same numerical address.
An attacker can interpose his machine between the server and client, in a man-in-the-middle attack. The attacker can observes and controls all of the client's activity sent to the server. The attacker can forge the status line displaying the URL the link points to, the location line displaying the URL of the page currently being shown, and viewing the document source with a malicious JavaScript.
As a short-term solution, disabling JavaScript will unable the attacker to hide its evidence.
