260 likes | 353 Views
Small Java VM’s and Security. Gary McGraw, 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 J2ME security Year two
E N D
Small Java VM’s and Security Gary McGraw, 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 J2ME security • Year two • Research application of advanced security mechanisms to constrained platforms • Use J2ME devices as a real world target
The classic security tradeoff Security Functionality • 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
The Java VM range JavaCard MicroChai J2EE More resources TINI J2SE J2ME
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
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)
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
Applet isolation Security manager Class loading Verifier Authorization Stack inspection Native functions Reflection Threads Garbage collection Exceptions Features relevant to security These features are architected and implemented differently throughout the JVM range.
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
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
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 Attacks and defenses
Development Valid tools Compiler Stack map Trusted MIDlet suites Unit and System Testing Deployment Trust of source and signee (big hole in this stage) Security strategy Execution • Load time verification • Dynamic runtime checking • Careful privilege API design • MIDlet suite sandbox
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 Security risks I
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 Security risks II
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)
J2ME security has yet to receive much security attention Java Card was in a similar state in 1997 http://www.securingjava.com Questions http://www.cigital.com gem@cigital.com