Small Java VMs and Security

1
Small Java VMs and Security

• Gary McGraw, Ph.D.
• gem_at_cigital.com
• http//www.cigital.com

2
Project goals

• Year one
• Understand the JVM security mechanism range
• Build a framework for describing security model
  features
• Dig into J2ME security
• Year two
• Research application of advanced security
  mechanisms to constrained platforms
• Use J2ME devices as a real world target

3
The classic security tradeoff
Security
Functionality

• How do resource constraints impact Javas
  standard security mechanisms?
• Strategy understand the range
• Classic Java Security Architecture
• J2ME security
• Java Card Security

4
The JVM Range

• Provide a scientific framework for understanding
  VM security mechanisms

5
The Java VM range
J2EE
JavaCard
MicroChai
More resources
J2SE
TINI
J2ME
6
How Sun sees it
7
The original sandbox

• The Byte Code Verifier
• Enforce type safety (some progress on Java Card)
• The Class Loader System
• Namespace management, dynamic loading
• The Security Manager
• API-level access control and enforcement

8
VMs and security

• Different resource constraints support different
  language and VM features
• Features removed to save memory/time/battery
• Little formal impact analysis
• Javas security architecture is a set of
  interconnected blocks
• Meant to work in concert
• Mutually dependant

9
Is this a house of cards?
What happens when we knock down a few of the
cards supporting the structure?
?
10
Defining a Framework

• JVM security mechanisms (in the large)

11
The approach

• Examine security models of the Java language and
  VMs
• Bytecode verifier, Class loader, Security
  Manager, Stack Inspection
• Multi-threading, Garbage Collection, etc
• Examine select implementations of smaller Java
  VMs
• Java Card (leveraging commercial work for
  Visa/MasterCard)
• J2ME
• Understand how physical constraints impact
  security
• Memory
• Power (both computational and battery)
• Connection
• Environment

12
Features relevant to security

• Applet isolation
• Security manager
• Class loading
• Verifier
• Authorization
• Stack inspection

• Native functions
• Reflection
• Threads
• Garbage collection
• Exceptions

These features are architected and implemented
differently throughout the JVM range.
13
The framework (writ small)
14
J2ME security

• JVM security mechanisms (in the middle)

15
J2ME CDC or CLDC configurations

• CLDC
• Constrained CPU
• 16 or 32 bit
• 512K or less
• J2ME environment
• JVM layer
• Configuration layer
• Profile layer (API)
• Vertical markets
• Apps written to profile layer
• MID profile

16
J2ME devices exist today (Japan)
17
Not just phones

• KVM (40-80K)
• Offline bytecode verification
• No Security Manager
• No Garbage Collection
• CLDC
• No app lifecycle
• No user interface/ app model
• No event handling
• MIDP
• Application behavior and support
• MIDlets (MIDlet suite)
• Nothing on app management, app level security,
  channel security

18
J2ME security features
19
J2SE feature relations
20
J2ME feature relations
21
Attacks and defenses

• Invalid byte code
• STACKMAP is new
• Trust problems
• User decides how much trust to give a MIDlet
• MIDlet masquerading
• User interface issues!
• Web spoofing revisited

• Inter-MIDlet interactions
• Attacking barriers
• Corrupting the record store
• Locking the interface
• Changing MIDlet suite state
• Denial of service
• Disruptive and easy to do

22
Security strategy

• Development
• Valid tools
• Compiler
• Stack map
• Trusted MIDlet suites
• Unit and System Testing

• Deployment
• Trust of source and signee
• (big hole in this stage)

• Execution
• Load time verification
• Dynamic runtime checking
• Careful privilege API design
• MIDlet suite sandbox

23
Security risks I

• Off-line verification bypassing
• No trusted channel
• Subvert STACKMAP
• Lack of MIDlet suite signing support
• MIDlet loading unclear
• Unspecified in CLDC/MIDP
• MIDlet removal unspecified

• No specified end-to-end security
• No requirements or guidelines for vendors
• No crypto API
• Synchronization of record store may cause
  starvation
• Locking issues
• MIDlet masquerading
• Web spoofing attacks

24
Security risks II

• Access to OEM libraries unspecified
• Device specific
• Vendor mistakes possible
• Constraints on preloading classes not detailed
  (what/security)
• Lack of finalization
• DoS
• Privacy leaks

• Incomplete spec of concurrently executing MIDlet
  behavior
• Concurrency issues between vendors
• Lack of MIDlet signing verification
• Trust propagation

25
Moving forward

• Mitigation strategies are possible
• Open Platform helped Java Card immensely
• Additional static and dynamic analysis
• Carefully specify OEM library security
  requirements
• We intend to probe real devices against these
  risks
• Test suite for J2ME
• Attacks against J2ME devices
• Create or borrow mechanisms to address risks
  (especially OASIS technologies)

26
Questions

• J2ME security has yet to receive much security
  attention
• Java Card was in a similar state in 1997
• http//www.securingjava.com

http//www.cigital.com gem_at_cigital.com