Security in Java2 - PowerPoint PPT Presentation

1 / 32
About This Presentation
Title:

Security in Java2

Description:

These guys can read and write the directory we set up for them. grant signedBy 'GoodGuys Inc. ... a picture or display some cute animation. A simple DOS attack ... – PowerPoint PPT presentation

Number of Views:50
Avg rating:3.0/5.0
Slides: 33
Provided by: people5
Category:
Tags: cute | guys | java2 | security

less

Transcript and Presenter's Notes

Title: Security in Java2


1
Security in Java2
  • Prabhu Ram Raghunathan
  • Srikanth E. Musti
  • Deep Kapadia

2
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.

3
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

4
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.

5
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

6
Keeping up with the Joneses
7
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

8
Morars 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"

9
Morars 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."

10
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

11
Morars 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.

12
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

13
Classes of Security attacks
14
Parts of default Sandbox
15
Parts of default Sandbox-The Verifier
  • The Verifier scrutinizes byte code before it is
    allowed to be run on a local VM.

16
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

17
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

18
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.

19
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).

20
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.

21
Capabilities of new security architecture in Java2
  • Fine-grained access control.
  • Configurable security policy.
  • Extensible access control structure.
  • Security checks for all Java programs.

22
New security mechanisms in Suns Java2
  • Identity
  • Permissions
  • Implies
  • Policy
  • Protection domains
  • Access control
  • And privilege

23
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

24
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

25
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.

26
A simple DOS attack (contd)
  • 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.

27
Killing Off the Competition
  • The Business Assassin
  • Matt LaDues Gamelan killer
  • Stealing Cycles
  • Why have a fast CPU when you can use somebody
    elses to do your work for you?
  • Forge Email (Old dog with new tricks)

28
Solutions
  • Disable Java
  • Know where you are on the Internet
  • Third party solutions
  • Improve Java itself
  • Someone tell Netscape and Microsoft to update
    their JVMs

29
Solutions (contd)
  • 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

30
Myths about signing Java code
  • Signatures denote authorship
  • If a signer is honest, the code is secure
  • Signatures imply accountability/liability

31
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

32
Should we use Java at all
Write a Comment
User Comments (0)
About PowerShow.com