Security in Java2



Prabhu Ram Raghunathan
Srikanth E. Musti
Deep Kapadia
Is Java still secure?
David M. Chess, John F. Morar
IBM TJ Watson Research Center






In the beginning there was:
Passive Content
Currently:
Active Content : Macro,ActiveX etc.
Digital Signature used by Office2000,
ActiveX
Only macros signed by trusted parties are run.
Original Java Security Model
The Sandbox



Security manager – construed guilty.
All programs on N/w assumed
Untrusted
Untrusted Applets Prohibited from
“damaging the system running them, or
reveal private or confidential
information”
Thou Shall Not :







Interact with the local file system : read,write,delete
or rename files.
Connect to another computer over the network.
Accept network connections from any other computer
Alter System Properties (Environment Variables)
Invoke a program or load a library.
Cause the Java Interpreter to Exit.
Prompt the user without an “Untrusted Applet”
warning or Create a new Security Manager.
Effect of Sand Boxing








This set of limits for an applet is the sandbox.
Good: A program can at best display unwanted
messages or snoop preferences etc.
Bad : Functionality trimmed.
Escape : JDK 1.1 introduced Command Line
feature
Developer signs JAR file digitally.
Users indicate trust in some signers.
a good start toward flexible security in Java
A failure as it was too complex
Keeping up with the Joneses
Function
Java 2 SDK
Netscape
Communicator
Microsoft Internet
Explorer
Mechanism for
delivering Signed Java
Java 2 signed JAR
Netscape signed JAR
Microsoft signed CAB
Signature Verification
Algorithm
DSA/SHA1
RSA/SHA1
RSA/MD5
Certificate handling at
client
Sun "keystores" for
keys and certificates
Netscape proprietary
key and certificate
management
Microsoft proprietary
key and certificate
management
Request for privileges
Applet attempts
privileged action. An
exception is thrown
when action is not
allowed.
Programmer defines
the privileges required
by calling privilege
manager methods.
Code signer defines
the privileges required
when signing the CAB
file.
Mechanism for storing
policy information
Policy configuration
files (can be located
remotely) that are
manually edited.
User prompted the first
time privileges are
requested. Proprietary
method for storing
persistent settings.
Privileges are
configured in security
zones that are stored
in a Microsoft
proprietary format.
Enter Java 2





Uses Java Runtime Environment & Java 2 plugin .
Page has HTML code directing the applet to
plugins.
Semi Automatic Install on Demand.
Security Manager on start up reads Policy Files.
Each policy file can describe many principals, and
for each principal specify a number of privileges
that should be granted applets associated with
those principals. A principal can be everyone, a
particular signer, a particular place that a program
can be loaded from, or a combination of a signer
and a place
Morar’s Example


// Everyone can do these things
grant {
permission java.util.PropertyPermission
"user.haircolor";
permission java.io.FilePermission
"c:\\temp\\*", "read,write";
};
// These guys can read and write the directory
we set up for them
grant signedBy "GoodGuys Inc." {
permission java.io.FilePermission
"c:\\GoodGuys\\*", "read,write"; };
Morar’s Example

// Things signed by the security administrator
and loaded
// from his server can do various magic
grant signedBy "secadmin", codeBase
http://secadmin.example.com/admin/*" {
permission java.security.SecurityPermission
"Security.insertProvider.*";
permission java.security.SecurityPermission
"Security.removeProvider.*";
permission java.security.SecurityPermission
"Security.setProperty.*";};
Java 2 Enhancements



No centralized Security Management, but definite
steps towards it.
it is possible to configure a system so that both Java
2 plugins and Java applications use the same
security manager and security policy.
The Java 2 security system provides more granular
control than did previous versions of Java, but the
range of available function in the sandbox is
essentially the same. Consequently, there is no
fundamentally new danger of viral spread in the new
environment
Morar’s Final Words



Various Java engines coexisting on a
machine could share a common security
configuration as in JVM in Netscape, IE,
Opera etc.
Risk is very low as possibilities of
exploiting holes is limited.
Java2 is Secure.
Securing Java
Gary McGraw
Edward W. Felten

Security risk categories:
* System modification
* Invasion of Privacy
* Denial of Service
* Antagonism

Java presents a multitiered approach to security:
* Restricted access to file systems
* Restricted access to browser internals
* Load time & runtime checks to verify that byte code is
following the rules
* A system for signing code and assigning it some level of
capability
Classes of Security attacks
Attack class
Explanation and consequences
Java Defense
System
modification
The most severe class of attacks. Applets that
implement such attacks are attack applets.
Consequences of these attacks: severe.
Strong
Invasion of Privacy
If you value your privacy, this attack class may be
particularly odious. They are implemented by
malicious applets. Include mail forging.
Consequences of these attacks: moderate.
Strong
Denial of Service
Also serious but not severely so, these attacks
can bring a machine to a standstill. Also
implemented by malicious applets. May require
reboot. Consequences of these attacks:
moderate.
Weak
Antagonism
Merely annoying, this attack class is the most
commonly encountered. Implemented by
malicious applets. May require restart of browser.
Consequences of these attacks: light to
moderate.
Weak
Parts of default Sandbox
Parts of default Sandbox
-The Verifier
The Verifier scrutinizes byte code before it is allowed to
be run on a local VM.
Parts of default Sandbox
-The Verifier(contd.)

Verification
* Internal checks
* Runtime checks

Verification assures:
* The class file has the correct format
* Stacks will not be overflowed or underflowed
* Byte code instructions all have parameters of the correct
type
* No illegal data conversions (casts) occur
* Private, public, protected, and default accesses are legal
* All register accesses and stores are valid
Parts of default Sandbox
-The Class Loader


Code is loaded (from the disk or over the network) by
a Class Loader.
Class Loaders perform 2 functions:
* Finding the byte code.
* Class loaders define the namespaces seen by different
classes and how those namespaces relate to each other

Class Loaders also need to make sure that important
parts of the Java runtime environment are not
replaced by impostor code
Parts of default Sandbox
-The Class Loader(contd.)

Fake Security Manager – Class Spoofing
Spoofing occurs when someone or something pretends to be
something it is not.
In this figure, an external class has arrived from the Internet and
declares itself to be the Security Manager (in order to replace
the real Security Manager). If external code were allowed to do
this, Java's security system would be trivial to break.
Parts of default Sandbox
-The Security Manager


The Security Manager implements a good portion of the entire
security model.
How the Security Manager works:
The Security Manager keeps tabs on potentially dangerous calls to
the native operating system (underlying the VM).
Parts of default Sandbox
-The Security Manager(contd.)

The Java library's use of the Security Manager works
as follows:
* A Java program makes a call to a potentially dangerous
operation in the Java API.
* The Java API code asks the Security Manager whether the
operation should be allowed.
* The Security Manager throws a SecurityException back to the
Java API if the operation is denied. This exception propagates
back to the Java program.
* If the operation is permitted, the Security Manager call
returns without throwing an exception, and the Java API
performs the requested dangerous operation and returns
normally.
Capabilities of new security
architecture in Java2




Fine-grained access control.
Configurable security policy.
Extensible access control structure.
Security checks for all Java programs.
New security mechanisms in
Sun’s Java2







Identity
Permissions
Implies
Policy
Protection domains
Access control
And privilege
Malicious Applets
Q) What can they do?
A) Can attack the local system of a Web
surfer causing…
 Antagonism
 Invasion of Privacy
 Denial of Service
Malicious Applets
…are known to
 Antagonize web surfers
 Forge mail from you to whomever the evil
applet's author chooses, saying whatever
they wish while masquerading as you
 Steal your CPU cycles to perform their own
work while your legitimate processes languish
 Crash your local system by using all available
system resources
A simple DOS attack
The dreaded thread



Create an applet that starts a thread with its priority set to
MAX_PRIORITY. This makes the thread run as quickly as
possible and gives it a leg up in the ongoing competition
between threads for CPU time.
Redefine the stop() method to null for the thread.
Do something silly in the main part of the applet so that it
appears to be harmless. Show a picture or display some cute
animation.
A simple DOS attack (cont’d)


Have the thread sleep for a while to delay its malicious
activities. Such sleight of hand will have the effect of placing
the blame somewhere else when the thread wakes back up to
perform its dirty work.
When the thread wakes up, have it begin calculating in an
infinite loop (or some other CPU-intensive activity that eats
cycles). Such a computation will, in effect, bring the browser
down by taking away all available computational resources.
Killing Off the Competition



The Business Assassin
Matt LaDue’s Gamelan killer
Stealing Cycles
Why have a fast CPU when you can use
somebody else’s to do your work for
you?
Forge Email (Old dog with new tricks)
Solutions





Disable Java
Know where you are on the Internet
Third party solutions
Improve Java itself
Someone tell Netscape and Microsoft to
update their JVM’s
Solutions (cont’d)





Writing safer code
Assess your risks
Understanding Code Signing
Easy to use signing tools
Avoid signing your code as far as possible
But try not to throw the good out with the
bad
Myths about signing Java code



Signatures denote authorship
If a signer is honest, the code is secure
Signatures imply accountability/liability
The future: Challenges facing
Mobile code




New features introduce new security
holes
New classes of attacks keep appearing
Secure Distributed Programming
Java as a “secure” true multiuser
system
Should we use Java at all