Transcript Java-Security

Java Security: From HotJava to
Netscape and Beyond
Drew Dean, Edward W. Felten & Dan S. Wallach
Presented by Ted Hsu
April 5, 2000
Agenda
•
•
•
•
Background
Security analysis
Methods of applet attacks
Conclusion
Background
• Java applets – run inside the web browser,
downloaded from a remote server
• Balance between functionality and security
• Published in 1996
• Sun’s HotJava version 1.0 alpha 3
• Netscape Navigator 2.0
• Sun’s JDK version 1.0
Security Analysis
• Follow Orange Book’s Fundamental Computer
Security Requirements
• Four fundamental requirements
•
•
•
•
Define a formal security policy
Enforce the security policy
Maintain user integrity
Maintain an audit trail
• HotJava and Netscape fail to fulfill the fundamental
security requirements
Policy
• Conflict between flexibility and security
• Must give enough freedom for applets
• Must also maintain user privacy and security
• “There must be an explicit and well-defined security
policy enforced by the system.” – Orange Book
• Clarifies the behaviors of a secure implementation
• Netscape and HotJava fail to provide a formal security
policy
Enforcement
• Use a reference monitor to track access permissions
• Must always be invoked
• Must be tamperproof
• Must be verifiable
• Java uses the SecurityManager
• Relies on programmers to call the SecurityManager
• Not tamperproof – superclass constructor attack
• Java does not have precisely defined semantics
Integrity
• Hide the user’s internal state from attackers
• Public and protected variables or methods are most
vulnerable
• Static synchronized methods are vulnerable - applets can
acquire and keep the locks
• TCB (Trusted Computing Base)
• Track which components require trust
• Not included in Java
Accountability
• “Audit information must be selectively kept and
protected so that actions affecting security can be
traced to the responsible party.” – Orange Book
• No audit trail exists in Java
Access to System Information
• Java permits write access to the \TEMP directory in
Windows 95
• HotJava’s System.getenv() call contains the user’s log
name, machine name, and environment variables
• No security requirements for this call
• PATH variable often lists the installed software on the
system
• Sun claims that System.getenv() is obsolete and not
included in JDK
• Applets can read the system clock under Java - allows
benchmarking
Denial of Service
• Applets can monopolize CPU and memory
•
•
•
•
Acquire and keep locks on critical browser components
Invoke wait
Unable to determine whether the need is genuine
Difficult to resolve
• Variations
• Degradation of service
• Introduction of time delays – mask source of problem
• Sun considers it low priority and difficult to prevent
DNS Weakness
• DNS policy in JDK and Netscape
• An applet can only open a TCP/IP connection with the
server from which it was loaded from
• The IP-address of any host that the applet is attempting to
connect must be found in the list of hostnames that the
applet was loaded from
• The applet can ask to connect to any DNS server
• Create and access a fake DNS server
• Allows attacker to access any IP-address
Inter-Applet Attack
• Multiple applets must be separated
• Applets can access the top-most thread list
• In Java, the applet’s class name is the same as its thread
name
• Use thread list to identify other running applets
• SecurityManager checks if applets are accessing
system threads - no checks on applet threads
• Perform denial or degradation of service attacks on
other running applets
Superclass Constructor Attack
• Java constructors - the same class or of a superclass
• The language requires constructors to be initialized before
use
• System classes use this as the security mechanism
• Bytecode verifier acts differently from the language
• Applets are not allowed to instantiate system classes
• The bytecode verifier allows this to happen
• ClassLoader allows all requested classes to be loaded
• The namespace is not searched beforehand
• Can define the namespace seen by other Java classes
• Allows attacker to create a customized namespace
Recent Bugs
• October 1999 – A flaw in Microsoft’s JVM allows
applets to violate Java’s type-checking
• August 1999 – A flaw in Microsoft’s JVM allows
malicious applets to be delivered over Internet
Explorer and Microsoft Outlook
• April 1999 – A flaw in Sun’s JDK 1.1 and JDK 1.2
allow booby-trapped web pages to take over a
victim’s computer
• July 1998 – A flaw in Netscape Navigator 4.0x
allows applets to display all security controls
Conclusion
• The demand for functionality of mobile code result in
inherently insecure applications
• Java applets have serious security flaws
• Flaws can be reduced by following Orange Book’s
fundamental security requirements
• Due to the design of the language, security flaws will
persist