Java & The Android Stack: A Security Analysis


Published on

Talk presented

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Total system RAM is 64 MB; available after low level startup: 40MB and after high level services have started: 20 MB and large system libs 10 MB
  • "java.version" property returns "java.class.version" invariably returns 50"user.home" and "" properties do not existHighly optimized VM to support multiple VM instances with own address space and separate memoryRelies on Linux kernel for underlying functionality such as threading and low-level memory managementLibrary built on a subset of the Apache Harmony JavaMemory is clean (mmap() and unwritten)) or dirty (malloc)Shared memory: used by many processesPrivate memory used by one process
  • ExamplesDex structures are using valid indices and offsets and code can’t misbehaveOptimaization: byte swapping (not needed on ARM)m static linking, pruning empty methodsRelies on Linux kernel for underlying functionality Garbage Collector is independent for each process but respect sharingBytecode verifierOptimization“Exact” GCIntra-application SecurityAnalysis & Debugging
  • Java & The Android Stack: A Security Analysis

    1. 1. Java & The Android Stack: A Security Analysis Pragati Ogal Rai Mobile Technology Evangelist PayPal, eBay Inc. pragati.rai@paypal.comJava Conference, Bangalore, Dec 8, 2012 @pragatiogal
    2. 2. Agenda Java 2 Security Model Android Security Model Summarize
    3. 3. Java 2 Security Model
    4. 4. Java Developed by Sun Microsystems in the early 1990s Platform Independent Compiled to bytecode that runs on a Virtual Machine “Java is Secure”
    5. 5. Java 2 Security Model Platform Security Crypto APIs Authentication & Access Control APIs Secure Communication APIs Key Management APIs
    6. 6. Java Language Security Programs cannot access arbitrary memory locations Variables cannot be used before initialization Access methods are strictly adhered to Entities declared final must not be changed Objects cannot be arbitrarily cast into other objects
    7. 7. Java 2 Platform Security ModelRemote Class Files Signed Class Files Local Class Files Bytecode Verifier Core API Class Files Class Loader Core Java API Security Package Security Manager Key Database Access Controller Operating System
    8. 8. Java 2 Sandbox Model • Fine grained access control • Configurable Security Policy • No built-in concept of trusted local code
    9. 9. Security Policy File Example// If the code is signed by ”Pragati", grant it read/write access to all//files in /tmp/pragati grant signedBy ”Pragati" { permission "/tmp/pragati/*", "read,write"; };// If the code is signed by ”John", grant it read/write access to all//files in /tmp/john grant signedBy ”John" { permission "/tmp/john/*", "read,write”; };// Grant everyone the following permission: grant { permission "/tmp/pragati/*", "read"; };…………..……….
    10. 10. Protection DomainDomain name “Pragati”Pragati’s certificateRead/write access to /temp/pragati/*Domain name “John”John’s certificateRead/write access to /temp/john/*Read access to /temp/pragati/*…………..………. Protection Domain = Code Source + Permission
    11. 11. Java 2 Security Model All code runs in a sandbox All classes are loaded with full bytecode verification All classes are loaded with Java language features Signed classes verify the integrity and origination of Java classes Security policy provides fine-grained access Crypto APIs
    12. 12. The Android Stack
    13. 13. Android Open Platform First phone based on Android came out in 2009 75% smartphone market share as of October1 1:
    14. 14. Android Security Model Platform Security Crypto APIs Secure Communication APIs Key Management APIs
    15. 15. Install Time User Consent
    16. 16. Android OS Architecture
    17. 17. Linux Kernel Unique UID and GID for each application at install time Sharing can occur through component interactions Linux Process Sandbox
    18. 18. Linux Kernel (Cont’d)include/linux/android_aid.hAID_NET_BT 3002 Can create Bluetooth SocketsAID_INET 3003 Can create IPv4 and IPv6 Sockets
    19. 19. Middleware Libraries for code execution Libraries for services Take care of device specific issues Compiled to machine language Native and Java code
    20. 20. Java Virtual Machine? There is no JVM in Android platform No bytecode is executed JAR file will not run on Android platform
    21. 21. Dalvik Virtual Machine Dalvik does not align to Java SE or Java ME Library built on a subset of the Apache Harmony Java Highly optimized VM to support multiple VM instances Register based architecture Shared constant pool Executes Dalvik executables (.dex)
    22. 22. Dalvik Virtual Machine No security manager Permissions are enforced in OS and not in VM As of Android 2.2 Dalvik has a JIT compiler Dalvik Bytecode verification mainly for optimization GC for each VM instance
    23. 23. Android Application Structure Application is made of components  Activity: Define screens  Service: Background processing  Broadcast Receiver: Mailbox for messages from other applications  Content Provider: Relational database for sharing information Applications communicate through Intents Secure RPC using Binder AndroidManifest.xml defines policy for application
    24. 24. Permission Protection Levels Normal android.permission.VIBRATE Dangerous android.permission.SEND_SMS android.permission.CALL_PHONE Signature android.permission.FORCE_STOP_PACKAGES android.permission.INJECT_EVENTS SignatureOrSystem android.permission.ACCESS_USB android.permission.SET_TIME All components are secured by permissions Developers can define their own permissions as well
    25. 25. Application Layer Security Permissions restrict component interaction Permission labels defined in AndroidManifest.xml Applications are self-signed; no CA required Signatures define persistence and authorship
    26. 26. Android Security Model Linux process sandbox Permission based component interaction Dalvik is not a security boundary All applications need to be signed Signature define persistence and authorship Install time security decisions Crypto APIs
    27. 27. Summary
    28. 28. Install Time Check Who are you? What do you want to do?
    29. 29. Sandbox Based on permissions, code sources, policy, keystore, protection domains Process Sandbox
    30. 30. Signature Identity and Trust Authorship and Persistence
    31. 31. Permissions Enforced by VM Enforced by OS
    32. 32. Protection Domain Code Sources + Permissions Process
    33. 33. Virtual Machine Is a security boundary Is NOT a security boundary
    34. 34. Thank you! @pragatiogal