Java Securityby Drew Dean Edward W. Felten and Dan S. Wallach

1
Java Security by Drew Dean Edward
W. Felten and Dan S. Wallach
2
Topics

• Introduction
• Java Semantics
• Taxonomy of Java Bugs
• Security Analysis
• Flexible Security for Applets
• Conclusion

3
Introduction

• Java and the HotJava browser it supports are
  insecure due to
• Implementation errors
• Unintended interactions between browser features
• Differences between the Java language and
  bytecode semantics
• Weaknesses in the design of the language and
  bytecode format
• Weaknesses in the design methodology used in
  creating Java and the browsers

4
Java Semantics

• System Name Space
• Shared by all name spaces
• Always searched first
• Prevents downloaded code from overriding a system
  class.

5
Java Semantics

• Mechanism of Java runtime system to fetch
  bytecode
• a Calls subclass of the abstract class
• ClassLoader
• ClassLoader defines an interface for the runtime
  system to ask a Java program to provide a class.
• Classes are transported across network as as
  byte streams, and reconstituted into class
  objects by subclasses of ClassLoader

6
Java Semantics (Contnd)

• Safety of Java bytecode
• Array stores require run time type checks as
  well as ordinary array bounds checks
• Example Suppose, A is a subtype of B. Java
  typing rules say that A is a subtype of B.
• Void proc (B x, B y)
• X0 y
• Dynamic checks introduces performance
  penalty

7
Java Security Mechanisms

• SecurityManager class
• Defines and implements a security policy
• Issues
• No security manager runs when Java runtime system
  starts
• Web browser or other user agent has to install a
  security maneger before executing untrusted code.
• The purpose of the SecurityManager class is to
  define an interface for access control.
• Default SecurityManager implementation throws a
  SecurityException for all access checks, forcing
  the user agent to define and implement its own
  policy in a subclass of SecurityManager

8
Taxonomy of Java Bugs

• Denial of Service Attacks
• Busy waiting to consume CPU cycles and allocating
  memory until the system runs out, starving other
  threads and processes.
• Applets can acquire locks on critical pieces of
  the browser to cripple it.
• sysnchronized (Class.forName(net.www.html.Metere
  dStream))
• while (true) Thread.sleep(10000)

9
Taxonomy of Java Bugs (Contd)

• An attack can be programmed to occur after some
  time delay, causing the failure to occur when the
  user is viewing a different web page, thereby
  masking the source of the attack
• Degradation of Service significantly reduces the
  performance of the browser without stopping it.
• The lock-based attack could be used to hold a
  critical system lock most of the time, releasing
  it only briefly and occasionally.

10
Taxonomy of Java Bugs (Contd)

• Two versus Three Party Attacks
• Two Party Attack Requires that the web server
  the applet resides on participate in the attack
• Three Party Attack Can originate from anywhere
  on the internet, and might spread if it is hidden
  in a useful applet that gets used by many web
  pages.

11
Taxonomy of Java Bugs (Contd)
Figure 2. A Three Party Attack Charlie produces
a Trojan horse applet. Bob likes it and uses it
in his Web page. Alice views Bobs Web page and
Charlies applet establishes a covert channel to
Charlie. The applet leaks Alices information to
Charlie. No collusion with Bob is necessary.
12
Taxonomy of Java Bugs (Contd)

• Information Available to Applets
• At a minimum , an applet can consume all the free
  space in the file system
• Users login name, machine name, the contents of
  all environment variables
• System.getenv() in HotJava has no security checks
• Netscape and JDK do not allow access to
  environment variables by applets

13
Taxonomy of Java Bugs (contd)
Figure 4. DNS subversion of Java an applet
travels from attacker.com to victim.org through
normal channels. The applet then asks to connect
to foo.attacker.com, which is resolved by
attacker.coms DNS server to be victim.orgs
internal mail server which can then be attacked.
14
Taxonomy of Java Bugs (Contd)

• Buffer Overflows
• sprintf()-HotJava and the alpha release of JDK
  used stack allocated buffers, yet did not check
  for buffer overflows
• Disclosing Storage Layout The Java library
  allows an applet to learn where in memory its
  objects are stored
• hashcode() casts the address of the objects
  internal storage to an integer and returns it,
  thereby exposing more internal state than
  necessary.

15
Taxonomy of Java Bugs (Contd)

• Public Proxy Variables
• We can change the browsers HTTP and FTP proxy
  servers. We can set up our own proxy server as a
  man-in-the-middle.
• We can both watch and edit all the traffic to and
  from the HotJava browser.
• Use the security managers put() method to store
  our desired proxy in the property managers
  database. If the user is then tricked into
  printing a web page, these settings will be saved
  to the disk, and will be the default setting next
  time the user starts HotJava.

16
Java Language and Bytecode Differences

• Superclass constructors Attack
• Class CL extends ClassLoader
• CL()
• try super()
• catch (Exception e) ClassLoader
  gives an attacker the ability to defeat Javas
  type system
• David Hopwood Attack
• Malicious code treated as trusted and can bypass
  runtime and access op system with full privilege
  of the user.

17
Java Language and Bytecode Weaknesses

• Language Weaknesses
• Has neither a formal semantics nor a formal
  description of its type system.
• Package system provides only basic modules
• Java allows methods to be called from the
  constructor
• Bytecode Weaknesses
• In Java bytecode, the verifier must show that all
  possible execution paths have the same virtual
  machine configuration-more complicated and hence
  more prone to error.
• The present verifier cannot be proven correct
  because there is not a formal description of the
  type system

18
Security Analysis

• Policy
• Lack of a formally defined security policy
• SecurityManager pitfalls
• Not always invoked
• Not tamperproof
• Not verifiable
• Integrity
• Browsers internal state is stored in public
  variables and classes which compromises Java
  runtime systems integrity.
• Accountability
• The Java runtime system does not have a
  configurable audit system

19
Flexible Security for Applets

• Networking
• An applet should not be able to control the PORT
  commands sent on its behalf.
• Distributed Applications
• Applications such as audio/video conferencing,
  real-time multi-player games, factoring, can be
  used as applets
• User Interface
• Security policy should be flexible enough so as
  not to make the user disable security.
• Applets should request capabilities when they are
  first loaded. The users response then should be
  logged, alleviating the need for future
  re-authorization.
• Use trusted dialog boxes

20
Summary

• Java lacks a well-defined, formal security policy
  that prevents the verification of an
  implementation
• The Java language definition could be altered to
  reduce accidental leaks of information from
  public variables, and encourage better program
  structure with a richer module system than Javas
  package construct.
• Redesign of the Java language, the bytecode
  format and the runtime system is paramount.
• Questions/Comments ???