Embed Size (px)
Citation preview
2
Project goalsProject 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 tradeoffThe 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
The JVM Range
Provide a scientific framework for understanding VM security mechanisms
5
The Java VM rangeThe Java VM range
J2EE
J2SE
JavaCard
J2ME
MicroChai
TINI
More resources
6
How Sun sees itHow Sun sees it
The original sandboxThe 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 securityVMs 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
9
Is this a house of cards?Is this a house of cards?
What happens when we knock down a few of the cards supporting the structure?
?
Defining a Framework
JVM security mechanisms (in the large)
11
The approachThe 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 securityFeatures 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)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
J2ME security
JVM security mechanisms (in the middle)
15
J2ME = CDC or CLDC configurations
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)
J2ME devices exist today (Japan)
17
Not just phonesNot 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 featuresJ2ME 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
19
J2SE feature relationsJ2SE feature relations
20
J2ME feature relationsJ2ME feature relations
21
Attacks and defensesAttacks 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 strategySecurity strategy
Development1. Valid tools
1. Compiler2. Stack map
2. Trusted MIDlet suites
3. Unit and System Testing
Deployment1. Trust of
source and signee(big hole in this stage)
Execution1. Load time
verification2. Dynamic
runtime checking
3. Careful privilege API design
4. MIDlet suite sandbox
23
Security risks ISecurity 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
24
Security risks IISecurity 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– DoS– Privacy leaks
11.Incomplete spec of concurrently executing MIDlet behavior– Concurrency issues
between vendors
12.Lack of MIDlet signing verification– Trust propagation
25
Moving forwardMoving 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
QuestionsQuestions
• J2ME security has yet to receive much security attention– Java Card was in a similar state
in 1997
• http://www.securingjava.com
http://[email protected]
