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 attacksAttack 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