|Main|Lecture|WWW-Design|SS 96 Works|
Just by visiting a Webpage with an applet embedded in it the Javaprogram will be downloaded into the user's browser where it can directly be executed. Often the visitor is not even informed about what is going on. So, everyone using the Web can be affected by hostile appelts created by an attacker. During the last month several of these bugs have been discovered. Some examples are listed below.) Drew Dean from Princeton who is intensly examing the security weakness in Java pointed out that all bugs which occured so far have been fixed. But is not very likely that all possible bugs are allready found yet. To be on the save side choose the option security preferences from the netscape menu and disable Java and Javascript.
If you download an applet into your system it might be able...
in chronological order
Applets can bypass the DNS. As a consequence they can even contact machines protected by firewalls. Therefore an attacker assigns two IP-Numbers to his machine , his real IP address and the IP address of the machine he wants to contact. He has to mention the wrong number first. The IP Number of its homeserver (real IP-Number) is in the pool of an applet. Being downloaded from the Web into the user's browser an applet must not build up a connection to any server but the server it came from. Therefore the applet tells the security-manager the name of its homeserver. Then the security-manager gets the IP addresss belonging to that name from the DNS. If one of these numbers fits the number which is in the pool of the applet the contact is allowed. As the attacker has mentioned the wrong IP address first, this number is first told to the security-manager by the DNS. This means that the connection will be build up to this address. So, a network connection even to protected machines is build up. Another possibility for an attacker is to manipulate his DNS server to give back the addresses the applets encodes in its request.
DNS Attack scenario by Drew Dean, Edward W. Felton, Dan S. Wallach
Works under Netscape 2.00, fixed in 2.01 With help of the Javascript an attacker can design a page where your directories are listed and send to a foreign server by clicking on a button. If the button is not labeled correctly, you might have no idea what you are doing.
works in 2.00 and in a different way in 2.01 With the help of theJavascript it is possible to track which pages a user visits in the Web. This bug is possible because Javascript might stay resistent even after the user leaves the page. If the user clicks on a certain spot the tracking program is started. But it runs in a window which is to small to be visible. As I pointed out above this program stays resistent, when the user leaves the page. From now on it checks which page the user is viewing and sends its results back to it programmer. It can be possible to gather information about the password this way.
Fixed in Netscape 2.01 and JDK 1.0.1 An applet should only be able to load classes from the Classpath. (These classes have extanded access and the are checked by the Jav security system). As the local classloader wrongly regards every class beginning with "/" as absolute pass name classes can also be loaded from local files. Thus, it is possible to bypass security restrictions. This bug only works when having installed two different files in a readable directory first. The effect of this bug is that the applet can create read and delete files with the same permission as the user of the browser. It can also run native code.
Being downloaded from the Web it exists a possibility for applets to generate and execute machinecode. This means they can read, write or alter all of a user's files. In addition they can embed themselves to the user's Webpages, wherefrom they can be downloaded into the browser of the next victom. That means they distribute like a virus. This attack takes advantage of a bug in the Classloader. So, it becomes possible to load more then one class under the same name, which means that you can bypass security restrictions.
Security Flaw by Princeton University
Applets can find out the path of the directory where Netscape was started. This can be dangerous, because in Unix this path provides information about the structure of the network, the user's login name, respectively his email name. This could be useful hints for hackers.
UnderJDK an applet is generally not allowed to read or write any directory.
By adding the line ~alc.read=/directoryname or
~alc.write=/directoryname to the file
Two applets being loaded from different servers can bypass security
restrictions. For example accessing private variables becomes possible,
etc. In fact it is a further possibility for an applet to read or alter
files or to run native code.
With the help of the Javascript an attacker can design his Webpage in such
a way that everyone who visits this page cannot help but sending an email
to the attacker without the visitor noticing what is happening. So, the
attackers gets all the email addresses of the readers of his page.
As I allready said above Javaprograms can be downloaded into the user's
browser and they can directly be executed. On the one hand this is an
advantage of Java, because it is an easy way to distribute and use
programs all over the Web. On the other hand it is one risks of this language.
For downloading a hostile applet into your system can have as eval
consequenses as a hacker having access to your system
Programs need to have access to resources of a user's machine to be
effective. (E.g. most programs would not make much sense without the
option save).
But everybody using the Web should be secure of applets damaging his
system. This is important, just because most times you are not warned
when entering a Webside with an applet embedded in it.
For that reason it is difficult to decide in how far applets should
have access to resources. You have to weight up the effectivty of
the applet and the highest protection of the user's machine possible
. Security-restrictions in Java should provide this protection.
The Javacompiler, the classloader and the security-manager are elements
of Java which should take care of applets obeying to these restrictions.
While transforming Java-sourcecode into bytecode, the Javacompiler
controlls that no stackoverflows, no illegal memory access, no illegal
parameters (Applets must not have access to private variables.) or
illegal data transformation occurs in the code. Then the compiled
bytecode is send accross the net.
Applets usually try to download so called Javaclasses. Therefore the
classloader in a user's browser checks if these classes are allowed
to load and if these classes obey to the security restrictions.
In addition the security manager checks every action an applet is
going to take.
Bugs have shown that it is nevertheless possible to pass by
the security-restrictions.
A further problem in Java is that two applets running in the
same browser cannot be separeted from one another. They can
recognize each other and start to interact.This could slow your
machine down, thus you cannot use it anylonger.
As so many bugs and problems have occured it seems obvious that
the Java-security-system has many gaps. Allthough a lot of
these gaps have been fixed, there are people who believe that
security risks in Java are a never ending story. They believe
that you cannot create a language that generates directly
executable programs to send across the net that is really save.
1 June
Applets execute machinecode (second variant)
Date unknown
Sending off an email without intention
Works under Netscape 2.00
Attention! Read before you click:
IF you click here, you will send an email to Wuerzburg
Short overview of the security system in Java