Small Java VM’s and Security
Gary McGraw, Ph.D.
[email protected]
http://www.cigital.com
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
2
The classic security tradeoff
• How do resource constraints impact Java’s standard
security mechanisms?
• Strategy: understand the range
– Classic Java Security Architecture
– J2ME security
– Java Card Security
3
The JVM Range
Provide a scientific framework for understanding VM
security mechanisms
The Java VM range
JavaCard
MicroChai
J2EE
More resources
TINI
J2ME
J2SE
5
How Sun sees it
6
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
VMs and security
• Different resource constraints support different
language and VM features
– Features removed to save memory/time/battery
– Little formal impact analysis
• Java’s security architecture is a set of
interconnected blocks
– Meant to work in concert
– Mutually dependant
8
Is this a house of cards?
What happens when we knock down a few of the
cards supporting the structure?
?
9
Defining a Framework
JVM security mechanisms (in the large)
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
11
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.
12
The framework (writ small)
Security feature Java 2
J2ME
Java Card
Applet isolation
SM, RM, CL
Logical VM/suite
Heap separation
Sec. Manager
Stack inspection
None
None
Class loading
Userdef/delegation
Limited (no user)
None (OP)
Verifier
Complete/control flow Limited (mix)
Out of band *
Authorization
Code signing/JAAS
App level
App level/ OP
Stack inspection
Essential for SM
None
None
Native functions
Supported/user def
No JNI/closed set No support
Reflection
Fully implemented
No support
No support
Threads
Full support
Nearly complete
None (app context)
Garbage collect
Always implemented
Always impl
None
Exceptions
Full support
Mostly supported
Allowed
13
J2ME security
JVM security mechanisms (in the middle)
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
15
J2ME devices exist today (Japan)
16
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
17
J2ME security features
Security feature
J2ME/CLDC/MIDP
Applet isolation
One logical VM per MIDlet suite (record store)
Security Manager
None; restricted sandbox design (API availability); some
applets are superusers (load time privilege grant)
Class loading
No user defined class loaders; limited support for dynamic
class loading (built in loader; limited to own JAR)
Verifier
J2SE verifier split in half; off-line and on-line components;
STACK_MAP (all stack states for all jump destinations)
Authorization
Occurs at application level (some special applications)
Stack inspection
None
Native functions
No JNI support; set of native functions is closed
Reflection
No support in CLDC (requires a Security Manager)
Threads
Nearly complete support
Garbage collection
Always implemented (mark and sweep)
Exceptions
Mostly supported
18
J2SE feature relations
19
J2ME feature relations
20
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
21
Security strategy
Development
1. Valid tools
1. Compiler
2. Stack map
2. Trusted MIDlet
suites
3. Unit and
System Testing
Deployment
1. Trust of
source and
signee
(big hole in
this stage)
Execution
1. Load time
verification
2. Dynamic
runtime
checking
3. Careful
privilege API
design
4. MIDlet suite
sandbox
22
Security risks I
1. Off-line verification
bypassing
– No trusted channel
– Subvert STACKMAP
2. Lack of MIDlet suite
signing support
3. MIDlet loading unclear
– Unspecified in
CLDC/MIDP
4. MIDlet removal
unspecified
5. No specified end-to-end
security
– No requirements or
guidelines for vendors
– No crypto API
6. Synchronization of
record store may cause
starvation
– Locking issues
7. MIDlet masquerading
– Web spoofing attacks
23
Security risks II
8. Access to OEM libraries
unspecified
– Device specific
– Vendor mistakes possible
9. Constraints on
preloading classes not
detailed (what/security)
10. Lack of finalization
11. Incomplete spec of
concurrently executing
MIDlet behavior
– Concurrency issues
between vendors
12. Lack of MIDlet signing
verification
– Trust propagation
– DoS
– Privacy leaks
24
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)
25
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
[email protected]
26