1 / 26

Small Java VM’s and Security

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

sidney
Download Presentation

Small Java VM’s and Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Small Java VM’s and Security Gary McGraw, Ph.D. gem@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 Java’s 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 JavaCard MicroChai J2EE More resources TINI J2SE 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 • Java’s 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. 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.

  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. 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

  22. 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

  23. 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

  24. 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

  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. 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

More Related