Скачать презентацию CMV Automatic Verification of Complete Mediation for Java
ece09b3e4d71f899a7060896ced493a7.ppt
- Количество слайдов: 36
CMV: Automatic Verification of Complete Mediation for Java Virtual Machines 1. A. Prasad Sistla, V. N. Venkatakrishnan, 2. M. Zhou, H. Branske University of Illinois at Chicago
Introduction n Java language and Java Platform § Java Language: With powerful features, gained considerable § success Java Platform: Enable users to write and run applications written in Java languages directly on top it Java Applications Java applications and Platforms are Used Everywhere Java compiler and other tools n Almost every browser runsjava. net, and supports Java libraries (including java. io, JVM Java Platform running Javajave. lang and other packages) Applets (such as Hot. Spot, Virtual Machine n n Harmony) Java Applet: A Java program that is run from inside a OS web browser (e. g. Solaris , Linux, Windows) TM
An Example of Java Applet Internet Explorer browses a webpage containing a Java Applet Webpage content: - From http: //www. realapplets. com/applets/quizmaster/
Risks n What can happen if a Java applet/Java program is allowed to access any system resources? § Compromise the security of the local host n n Disclose the confidential information: Transmit information Destroy system files Display annoying pictures on a user screen How the JVM prevents this from happening?
Java Fine-grained Access Control Model n Security Policies § Map code to sets of permissions to access security sensitive resources grant code. Base “URL” { } n permission java. io. File. Permission “/home/tmp/", "read"; Runtime Monitoring in JVM § Through a call to library class Security. Manager, before accessing any sensitive resources
A Typical Use of Security. Manager public File. Input. Stream(File file) throws File. Not. Found. Exception { String name = (file != null ? file. get. Path() : null); // Existing Solutions Potential Problem: Security. Manager security = System. get. Security. Manager(); // Challenge: checks for SM Without checking the permissions, any file specified by Ensure that thecan be opened, leading to potential the application Security. Manager is consulted on all if (security paths that lead to sensitive operations != null) { confidential information leaks. } } security. check. Read(name); …… open(name); method permission check sensitive operation implemented as a native
Our Goal n Ensure Java Standard Libraries are trustworthy § They satisfy Complete Mediation Property: n n Security. Manager is consulted on all paths that lead to sensitive operations § This Assurance will benefit millions of Java users Sensitive Operations Challenges to Our § Implemented as native methods Goal: • Large code base -is specific to a classes in Javaoperating system Thousands of libraries n Code that hardware and • Existing Model Checking tools (e. g. SLAM, MOPS) are general platform and are written in other languages, such as C and purpose oriented, while our goal is specialized to verify complete C++. Called by Java code. mediation property. These generic tool may not be scalable to a large code base such as the Java libraries
Our Solution Input: Java Standard Libraries Security Property Verifier Output: No All paths from public methods to sensitive operations are guarded by security checks. An automated static analysis technique. Sound. Not Complete Yes Some paths from some public methods to sensitive operations are missing security checks.
Our Contributions A scalable automated model checking technique that verifies satisfaction of complete mediation in open systems n A tool, Complete Mediation Verifier (CMV) n § Efficiently analyzes JVM library classes n Experimental results in two shrink-wrapped JVM implementations -- Hot. Spot and Harmony VMs.
A Code Example to Walk through Various Verification Approaches public void X () { // do some operations private void Y() { if (…. ){ Security. Manager sm = System. get. Security. Manager(); Y(); } if (sm != null) { sm. check. Permission( File. Permission(pathname”read”)); } //sensitive-operation File. Rd 1(); Risky } // sensitive-operation File. Rd 2(); A branch w/o a } security check else { // other operations }
Analysis : Naive First Approach private void Y() { 0. if (…. ){ 1. Security. Manager sm = System. get. Security. Manager(); 2. if (sm != null) { 3. sm. check. Permission( File. Permission(pathname, ”read”)); } // sensitive-operation 4. File. Rd 2(); } else { 5. // other operations } } Y 0 Y 1 Y 5 Y 2 Y 3 safe Y 4 RET
First Approach (Contd. ) - Presence of Method Calls n Expand analyze CFG inline to make Extended CFGs(ECFG) public void X(int x) { CFG(X) 0: // do some operations X 0 Y Y 0 X 0 1: Y(); Invokes Y Y 1 Y 5 X 1 Y 2 //sensitive-operation Expand To 2: File. Rd 1(); RET } X 2 n Inline Expansion Drawbacks: § Recursion § Size of ECFG(M) – can be exponential Y 3 Y 4 X 2 RET At risk
Summarization methods once; “summarize” n High-level idea: Analyze and reuse the results n n All_Path_Secure § EN paths to return RT No node(s) w/o § n security check. Otherwise, Insecure_Path Good § No paths to unguarded sensitive operations. § Otherwise, Bad EN We store negations of these two properties n Method Summary § A 2 -tuple to store §
Observations to Compute Method Summary To compute Insecure_path attribute: To compute Bad attribute: A node that Invokes a bad Insecure_Path method M 11 Invokes a All_Path. Secure and Good method M 1 a neutral node A sensitive node equivalent A security check node
Second Approach – Computing Summaries of Methods Given two methods X & Y. X invokes Y. Step 1: Construct call graph Meth. X Y 0 Y 1 Y 5 Meth. Y Step 2: Find out Y needs to be analyzed first; The summary of the method computed safe first can then be reused. In presence of multiple methods, list the methods in reverse topological order Y 2 Y 3 Y 4 RET CFG(Y) Step 3: Analyze CFG(Y) to Compute Summary(Y) =
Second Approach (Contd. ) Step 4: - Compute Summary(X) Invokes Y, Summary(Y) =
Second Approach - Algorithm in summary: Construct call Graph; Get a list of methods in Reverse Topological Order(RTO); For each method M in the list ordered in RTO Compute Summary(M), reusing the method summaries of those invocation nodes; Runtime complexity: O(ΣM) § ΣM the sum of the sizes of the CFGs of all the methods.
Expanded Second Approach - For Recursion n Let us say M 1 and M 2 are mutually recursive methods Meth. M 1 Meth. M 2 A cycle exists in the call graph § Analysis based on reverse topological order will not work n n Solution: § Repeat the previous algorithm, until all method summaries reach a fix point. § Worst case run time: n O(N* ΣM). Quadratic n N the number of methods analyzed § Quadratic algorithms still problematic for a large code base such as libraries How can we make this more efficient?
Our Approach – A New Efficient Solution (Part 1 – Compute Insecure_Path) Step 1: Add X 0, Z 0 to Q Q X 0 Z 0 n Main X(int x) X 0 private void Z() { public void. Idea: { Z 0 Step 2: X 0 is a neutral node. Invokes method 0: Security. Manager sm = Q the Compute. Z 0: § // do some operationssummaries for all methods, at Z 0 X 1 Add its successor X 1 to Q X 1 System. get. Security. Manager(); same time Z 1 1: 3: sm. check. Permission( Z 0 is a neutral §Z(); Insecure_Path Stepits successor Z 1 tonode. the X 1 Z 1 For summaries, process all Q 1: X 1 Z 1 Add Q File. Permission(pathname, methods at the same time ”read”)); n Start with RET entry Step 4: //sensitive-operation Q RET//sensitive-operation nodes in a queue, and keep adding Z 1 X 1 is a method invocation successors to the queue Add X 1 to WQ(Z). node. as you explore 2: File. Rd 1(); 2: File. Rd 2(); WQ(Z) X 1 } } Linear run time complexity: n O(ΣM) Step 5: Z 1 is a security check. Q Stop exploring the path. WQ(Z) §ΣM sum of sizes of the CFGs of all methods X 1 Step 6: Q is empty. Terminate the algorithm. Both X and Z are All_Path_Secure.
Our Approach - A New Efficient Solution (Part 2 – Compute Bad Summaries) Step 1: Add X 0, Z 0 to Q Q X 0 Z 0 Main Idea (Similar to the computing of Insecure_Path ) private void Z() { void X(int x) Z 0 Step 2: X 0 is a neutral node. § process all Z {methods at the same time. the Invokes 0: sm 0: Different in processing of. Add its. Security. Manager Q = Q Z 0 X 1 // do some operations successor X 1 to Q n. X 1 each node in the queue System. get. Security. Manager(); Z 1 § for a sensitive operation, 3: sm. check. Permission( as bad 1: Z 0 method summary Step label is a neutral node. Q X 1 1: §Z(); a node invoking a Add its successor Z 1 to Q X 1 Z 1 for method File. Permission(pathname, Z 1 M’, ”read”)); n If Insecure_Path(M’) is true, put all successors to the Q RET//sensitive-operation waiting 4: //sensitive-operation RET Step queue ofmethod invocation Q Z 1 X 1 is a M’ n Put the node to a node. Insecure_Path(Z) is false. § Whenever the bad summary. File. Rd 2(); 2: File. Rd 1(); 2: of M’ is computed, process the WQ(Z) X Add of M’ Method X to WQ(Z). node based on summary} } Step 5: M) Q n Linear run time complexity: O(ΣZ 1 is a security check. n X 0 public Stop exploring the path. WQ(Z) § O(ΣM) sum of sizes of the CFGs of all methods X Step 6: Q is empty. Terminate the algorithm. Both X and Z are Good.
Our Improvement to the New Approach n Observations Current solution: public void Z() { §Constructs and explores CFG(Z) and CFG(Z) § Our goal is to identify paths from public CFG(Y) 0: // do some operations §Computes Summary(Y) and Z 0 methods to sensitive operations without At risk Summary(Z). security checks. //sensitive-operation Z 1 Invokes However, to identify a risky 1: File. Rd 1(); Y Z 2 path in Z, § To achieve such a §No need to explore the CFG(Y)is goal, sometimes there and 2: Y(); need Y iscompute some method summaries. RET compute method no // to a non-public Summary(Y) §No need to compute Insecure_Path } attribute of Z How to make the algorithm even more efficient?
Our Approach: On-the-fly Approach - A Even More Efficient Solution Start to process all public methods first § By putting their entry nodes of CFGs to a queue n While exploring the CFGs, if a method invocation node is encountered and is never visited before, add its entry node to the queue to explore its CFG. § Whenever its Bad attribute or Insecure_Path attribute n is computed, replace the node with a non-methodinvocation node based on its summary For a return node, label the method as Insecure_Path n For a sensitive operation, label the method as Bad n For a security check, stop exploring that path n
An Example to Illustrate the Onthe-fly Approach Step 1: Add Z 0 to Q public void Z() { CFG(Z) 0: // do some operations Z 0 At risk //sensitive-operation Z 1 Invokes non 1: File. Rd 1(); method Y public Q Z 0 Step 2: Z 0 is a neutral node. Add its successors to Q Z 1 Q Z 2 2: Y(); // Y is a non-public RET } Step 3: Z 1 is sensitive, label method Z method as Bad Q Step 4: Q is empty. Terminate the algorithm
Runtime of On-the-fly Approach n In comparison to the non-on-the-fly approach: § No need to construct the Call Graphs to get all § n methods! Construct the CFG and compute the method summary of each method on demand. In worst case, linear run time complexity O(ΣM) § ΣM sum of sizes of the CFGs of all methods
Witness Generation & Analysis n Witness - A call chain to show a counter example, i. e. § An unguarded path to a sensitive operation, or § An insecure path. java. net. URL: void
Experiment & Results Hot. Spot VM from SUN Microsystems, java. io. *; java. net. *; java. lang. Class; Total # of Meth. JVM Class In JVM class Concrete Total Meth. LOBC # of Risky Meth. Real Risky 22 775 703 1520 23, 394 61 0 Harmony VM from Apache Software Foundation, java. io. *; java. net. *; java. lang. Class Total # of Meth. JVM Class In JVM class 21 748 Concrete Total Meth 689 3928 LOBC # of Risky Meth. Real Risky 65, 362 0 0 Risky method: A public and bad method. Real Risky: a risky method that has at least one feasible bad path in practice.
Experiment & Results (Contd. ) n The average time taken by CMV to analyze each class was 74 seconds § The bulk of the time is spent on Call Graph construction Preloaded method summary database storing summaries n Risky methods: Need further analysis n In Hot. Spot VM, only 61 methods to be analyzed, vs. code review on 1520 methods, a reduction in two orders of magnitude! n Automated witness analysis: further reduce human review efforts n
Future Work #1 - Method Overriding A method in base class can be overridden by child classes n For a method invocation node, method summaries from base and all child classes should be considered. n Our Solution n § Transform the code of base class by adding the n- § way branch statement before the first statement, to make a call to each overriding method of child classes. Method summary in each branch is computed
Future Work #2 - Exceptions Code can throw exceptions. Control flow is changed n Issues n § Throw statement If catch block exists, add an edge from throw to catch block n Add an edge from throw to return node Method invocation node n Similar to Throw statement Rethrow statement, i. e. a throw in a catch block n Replace the node with a return node n § § n Solutions: Add new edges
Future Work #3 - Check Non-native Sensitive Operations n Sensitive operations are not implemented as native methods. For examples: § § n Setting a Sensitive Private Data Member Returning a Password Returning Network IP Address Solutions § Identify these sensitive operations, and then apply the same approach (to the handle of sensitive native methods), to compute method summaries.
Future Work #4 - Automated Sensitive Operation Detection To automate the detections of sensitive operations in Java libraries. n Challenges- Hard to identify them due to: § Some native methods are non-sensitive n n They do not access sensitive system resources § The parameters passed to a sensitive operation: another factor (in addition to the method name) to determine if a method is a sensitive operation and the sensitive type (e. g. read or write a file)
Future Work #5 - Automated Permission Checks Detection Determine the types of permission checks for each sensitive operation. n Challenges § Needs to first identify the sensitive operations n § in JVM. Should also determine the permission checks for those sensitive operations performed in Java libraries, but without permission checks, due to an undetected defect.
Future Work #6 - Certification Given a method say M 0 that is claimed to be Good or All_Path_Secure, verification is needed to ascertain its correctness. n Our Solution n § We have initiated a novel and scalable § verification technique to certify the correctness of method summaries. Experiments are ongoing, and we will report our work in the future.
Related work n Model checking § Several general purpose: MOPS, SLAM, Bandera, C-Wolf n Ours is specialized for this problem; property-specific customization makes it scalable § Jensen et al [IEEE S&P 99] n n § Our approach checks open systems (e. g. , libraries) Static analysis § Bug-finding [METAL, CQUAL] § Checking complete mediation [Zhang et al [Security’ 03], Fraser [PLAS 06] n n Algorithms for verification of closed systems These techniques require non-trivial transformations to Java-like libraries § E. g. security checks and sensitive ops in different methods Retrofitting code for authorization § Naccio, SASI, Ganapathy et al [IEEE S&P 06] n One requires retrofitting only when verification reports unsafe methods
Tool & Paper Tool: Complete Mediation Verifier (CMV) § Developed. To be released by Dec. 2008 n Paper: CMV: Automatic Verification of Complete Mediation for Java Virtual Machines § Accepted by ACM Symposium on Information, Computer n § and Communications Security (ASIACCS’ 08), to be held in Tokyo, Japan. March 18 -20, 2008 Collaborators: n n n Hilary Branske Prof. Prasad Sistla Prof. V. N. Venkatakrishnan
Thank you!