Small Java VM s and Security Gary Mc Graw

Small Java VM’s and Security Gary Mc. Graw, Ph. D. gem@cigital. com http: //www. cigital. com

Project goals • Year one – Understand the JVM security mechanism range – Build a framework for describing security model features – Dig into J 2 ME security • Year two – Research application of advanced security mechanisms to constrained platforms – Use J 2 ME 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 – J 2 ME security – Java Card Security 3

The JVM Range Provide a scientific framework for understanding VM security mechanisms

The Java VM range Java. Card Micro. Chai J 2 EE More resources TINI J 2 ME J 2 SE 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/Master. Card) – J 2 ME • 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 J 2 ME Java Card Applet isolation SM, RM, CL Logical VM/suite Heap separation Sec. Manager Stack inspection 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/ OP Stack inspection Essential for SM None Native functions Supported/user def No JNI/closed set No support Reflection Fully implemented No support Threads Full support Nearly complete None (app context) Garbage collect Always implemented Always impl None Exceptions Full support Mostly supported Allowed 13

J 2 ME security JVM security mechanisms (in the middle)

J 2 ME = CDC or CLDC configurations • CLDC – Constrained CPU – 16 or 32 bit – 512 K or less • J 2 ME environment – JVM layer – Configuration layer – Profile layer (API) • Vertical markets • Apps written to profile layer • MID profile 15

J 2 ME devices exist today (Japan) 16

Not just phones • KVM (40 -80 K) – 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

J 2 ME security features Security feature J 2 ME/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 J 2 SE 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

J 2 SE feature relations 19

J 2 ME 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 – Do. S – 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 J 2 ME – Attacks against J 2 ME devices – Create or borrow mechanisms to address risks (especially OASIS technologies) 25

Questions • J 2 ME 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@cigital. com 26