\documentstyle[12pt,twoside,alltt,psfig]{article}
%\documentstyle[12pt,twoside,alltt,psfig]{article}
% is the line you should use IF you're using EPS images.
% make sure to copy the psfig.sty file into the directory with
% the latex document however.
\textwidth=6in
\oddsidemargin=0.25in
\evensidemargin=0.25in
\topmargin=-0.1in
\footskip=0.8in
\parindent=0.0cm
\parskip=0.3cm
\textheight=8.00in
\setcounter{tocdepth} {3}
\setcounter{secnumdepth} {2}
\sloppy

\newenvironment{proof}{\noindent{\bf Proof:}}{\qed\bigskip}
\newenvironment{proof_sketch}{\noindent{\bf Sketch of 
Proof}\hspace*{1em}}{\qed\bigskip}

\newtheorem{theorem}{Theorem}
\newtheorem{corollary}{Corollary}
\newtheorem{lemma}{Lemma}
\newtheorem{claim}{Claim}
\newtheorem{fact}{Fact}
\newtheorem{definition}{Definition}
\newtheorem{assumption}{Assumption}
\newtheorem{observation}{Observation}
\newtheorem{example}{Example}
\newcommand{\qed}{\rule{7pt}{7pt}}

\newcommand{\lecture}[4]{
\pagestyle{headings}
\thispagestyle{plain}
\newpage
\noindent
\begin{center}
\framebox{
\vbox{
\hbox to 5.75in { {\bf 6.857 Computer and Network Security
\hfill Fall Term, 1997}  }
\vspace{4mm}
\hbox to 5.75in { {\Large \hfill Lecture #1 : #2 \hfill} }
\vspace{2mm}
\hbox to 5.75in { {\it Lecturer: #3 \hfill Scribe: #4} }
}
}
\end{center}
\markboth{Lecture #1 : #2}{Lecture #1 : #2}
\vspace*{4mm}
}

\begin{document}

\lecture{18}{November 4, 1997}{Ron Rivest}{Jessica Wong} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Topics Covered}

\begin{itemize}
\item Java
\item Java Security Mechanisms
\item Attack Applets
\item Malicious Applets {\em -----  This topic was actually discussed in
Lecture 19.}
\end{itemize}

\section{Java}

Java has been described as a ``simple, object-oriented, distributed,
interpreted, robust, secure, architecture-neutral, portable,
high-performance, multi-threaded, dynamic language.''

The basic principle of Java is that it runs on a {\em virtual machine}.
This machine is a basically a particular well-defined architecture which
will run the Java applet.  An applet developer
writes a program which converts Javacode into bytecode to be interpreted
by a particular virtual machine.

\subsection{Java features}

\begin {description}
  
\item[Object-oriented:] Java is object-oriented, meaning that it deals
  explicitly with objects which the programmer defines.  This is
  implemented through {\em classes}.
  
\item[Strongly-typed:] The system knows what type of result to expect
  from each message.  Types (e.g. int, float) are known at compile time.
  
\item[Garbage-collection:] When a new object is created, there is no
  need for storage allocation or deallocation.  A garbage collection
  thread runs in the background and periodically frees up memory as
  appropriate.  {\em (This is a big security feature, since many
  security holes are due to illegal memory accesses.)}

\item[No pointers:] There are no pointers- only {\em references}.

\item[Exception Handling:] Java declares a routine when an exception
  occurs.
  
\item[Dynamic Linking:] {\em Classes} can be brought in and linked to,
  as needed.
\end {description}

\subsection{Applets vs. Applications}

Applets are programs imbedded in webpages invoked without the user
knowing, which therefore must follow a set of {\em restrictions}.
Applications are stand-alone (like C programs), and have no security
restrictions.

{\bf Applet restrictions:}

An applet {\bf can't}:

\begin{itemize}
\item read/write/delete/rename files on client
\item create or list a directory
\item check if a file exists or find file properties (size, type, mod
  time, creation date, etc.)
\item connect over the network to anything except its own host
\item listen for a connection
\item create a top-level window without an ``UNTRUSTED'' banner (making
  it clear that the window is untrusted
\item obtain a username or home directory
\item run other programs
\item exit the interpreter (killing all other applets)
\item load dynamic libraries
\item create or manipulate any thread other than those in its own Thread
  Group
\item create a Class Loader (a program that loads a class onto a Virtual
  Machine)
\item create a Security Manager
\item define classes as part of a package (a collection of classes) on
  the local client system
\end{itemize}

\section{Java Security}

There are three parts to security:

\begin{enumerate}
\item Byte Code Verifier
\item Applet Class Loader
\item Java Security Manager
\end{enumerate}

\subsection{Byte Code Verifier}

``Byte code,'' or machine code compiled for a virtual machine, must pass
the tests of the Byte Code Verifier before it runs on the client
machine.  The Byte Code Verifier (written by the applet developer)
checks the folllowing:

\begin{description}
\item [Static typing:] All object types are appropriate.  This is
  important since there are possible security breaches if an object has a
  different type than an applet expects (e.g. An applet thinks it's
  dealing with type {\em foo} when it's really dealing with the security
  manager, and then the applet changes some permissions.)
\item [No stack overflow:] At a return from a branch, the stack is the
  same height as it was before the branch.
\item [Legal access to methods:] There are no accesses to private
  methods outside of an object's own class.
\end{description}

\subsection{Class Loader}

Each applet has its own name space.  A class is loaded onto a machine at
the same time as an applet, which defines all associated classes and
methods.

\subsection{Java Security Manager}

The Java Security Manager performs run-time checks to determine whether
a request should be allowed.  (It corresponds to a guardian or reference
monitor.)  It handles the following:

\begin{itemize}
\item no new Class Loaders created by applets
\item protecting threads from each other
\item file system access
\item network access
\item controlling access to packages 
\end{itemize}

\section{Attack Applets}

Attack applets are applets which violate the policy, creating a security
hole.  Here are some examples of attack applets which have caused bugs
(often an error of implementation, not of principle).

\subsection{Jumping the firewall}

Alice can download an applet that attacks a machine in the R\&D
department of her company, when the machine sits inside a firewall.
How?  [{\em The first implementation of Java used DNS addresses.
It now uses IP addresses.} ]

\begin{figure}[h]
\begin{center}
\mbox{\psfig{figure=notes-18-fig-1.eps}}
\caption{Jumping a firewall.}
\label{fig:1}
\end{center}
\end{figure}

Alice downloads an attack applet from att.com onto her computer, which
correctly passes through the firewall.  att.com controls its domain name
server, and a hacker writes his own DNS entries and assigns both {\bf
17.15.12.19} {\em and} {\bf 1.2.3.4} to b.att.com.  Now b.att.com wants
to run an applet on {\bf 1.2.3.4}.  Alice's computer looks up the
originator of the applet, and may find the IP address {\bf 1.2.3.4}.
This is clearly wrong since the computer thinks that the applet is
coming from inside the firewall, when in fact it's coming from outside
the firewall.

\subsection{Slash and Burn}

If an applet tries to access class ``foo.bar,'' the translation changes
the ``.'' to a ``$\backslash$'' and looks up class foo$\backslash$bar: a
{\em relative} pathname.  But if the applet tries to access
``$\backslash$foo.bar,'' then this translates into
``$\backslash$foo$\backslash$bar,'' an {\em absolute} pathname!  By
allowing class names to start with the ``$\backslash$'' character, an
applet can access {\em any} file on the user's machine.

\subsection{Type confusion}

The bytecode declares its type to be ``[ ...  .''  The client machine
interprets the opening bracket as an {\em array} type, which can allow
the applet to index parts of memory it shouldn't be allowed to see.

\subsection{Linking}

An ``evil Class Loader'' can create a situation where we get type
confusion due to linking objects.  One bug allowed the user to define a
``subclass'' of class Class Loader, and another allowed this subclass to
instantiate without calling the instantiation routine for its
superclass.  As a result we get the following scenario: Class ``A''
references classes of types B and C.  Class ``B'' references
classes of types A and C'.  Class C references a class of
type C$_1$, and class C' references a class of type C$_2$.
Now A makes a type C$_1$, and passes it to B, who thinks that it's of
type C$_2$.

\begin{figure}[h]
\begin{center}
\mbox{\psfig{figure=notes-18-fig-2.eps}}
\caption{Linking causing type confusion.}
\label{fig:2}
\end{center}
\end{figure}

\subsection{Interface casting}

An interface casting allows an illegal call of a private method.

Suppose we had the commands listed below to declare interface function, f,
a private function f and a public routine, f.  \\

Then we define an array of length 2 with an instance of Dummy class and
of Secure class.  The loop calls the f function of Dummy, then of
Secure.  It should check each time whether the private function is
allowed each time through the loop, but in fact the legality was only
checked the first time.


\begin{tabbing}
	
	{\tt interface Inter \{void f();\} } \\
	{\tt class} \= {\tt Secure implements Inter \{private void f();\} } \\
	{\tt class Dummy implements Inter \{public void f();\} } \\
	{\tt static void attack() \{ } \\
	\> {\tt Inter inter(2) = \{new Dummy(), new Secure()\} ;} \\
	\> {\tt for (}\={\tt int j=0; j<2 ; ++j)}\\
	\> \> {\tt inter[j].f();}\\
	\> {\tt \}} \\ 
\end{tabbing}

\subsection{Package attack}

\begin{tabbing}

Variables in Java are either \={\bf private}: usable only by methods in its
class\\
\>{\bf protected}: usable by class and subclasses\\
\>{\bf public}: usable by all classes\\
\>{\bf undeclared}: usable by all classes in the same {\em package}
\end{tabbing}

The bug in Internet Explorer was that only the first component was used
to compare package names.  Therefore if a package name was ``com.ms,''
a package named ``com.foo'' could access the variables in ``com.ms'' if
they were undeclared.

\section{Malicious Applets}

Here is a list of a few ``malicious applets'' which are not necessarily
destructive, but cause annoyance to the user.

\begin{description}

\item[Barking dog:]
An applet sets up a thread that is ``immortal'' ; it redefines its
``stop'' method to do nothing.  

\item[Business assassin:]

An applet kills all threads of competitors' applets.

\item[Denial of service:]
An applet assigns itself as a high-priority CPU task and soaks up all
the cycles.

\item[Opening windows like crazy:] rather annoying. 

\item[Forging email:] An applet can take advantage of the fact that
sendmail is often on port 25.  Alice sends an email to Bob, and an
applet telnets to port 25 of Bob's machine.  The ``Received from:''
header contains Alice's IP address, since that's where the connection
came from.  The applet then changes the ``Received from:'' header of an
email message from Alice's machine to Charlie's machine, thus forging
the email to Bob.

\end{description}

{\bf {\large Endnote on ``Digitally Signed Applets:''}}\\

One approach to handling security of Java applets is for every applet to
be signed by its developer.  A browser can only run an applet if it is
signed by an approved signer.  The browser then stores a list of
approved signers and a list of certifiers of signers.  We can then have
statements like ``Applet is signed by author Y.'' and ``Y is approved by
X.'' to let us run the applet if X is on our certifier list but Y is not
on our approved list.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}
