Recipient Driven Correctness Framework for ... - Semantic Scholar

Technical Report

CSA-04-01

Recipient Driven Correctness Framework for Mobile Code Padmanabhan Krishnan James Larkin Phil Stocks Centre for Software Assurance Faculty of Information Technology Bond University Gold Coast, Queensland 4229 Australia email: pkrishna,jalarkin,pstocks @staff.bond.edu.au


Abstract This work develops a framework derived from the proof carrying code approach to ensure that code received and executed by an agent does not violate the requirements of the recipient. Unlike the proof carrying code approach, our framework requires the code recipient to perform the necessary correctness checks. The advantages of our framework include the specification and verification of policy driven properties, less code to be shipped to the recipient and the ability to use a variety of verification tools. This paper describes the general framework and presents a few examples which illustrate its potential uses.

Keywords Software Verification, Proof Carrying Code, Mobile Code

1 Introduction Security verification of untrusted code is an important issue. This is especially true in the context of web based applications where a user’s machine executes the code received (in the form of scripts) from another machine. In general, mobile code can be defined to be code that is developed at one location (the source) but actually executed at a different location and environment (the recipient). Examples of this include general uses of JavaScript, open smart card systems and components of systems used in e-commerce systems. When a host receives an application, it would like assurance that upon its execution, nothing unsafe will happen. As an example, consider a JavaScript program that takes a number of files specified from the user and then uploads those files to a server. The user would like a guarantee that the JavaScript uploads only the specified files. Potentially unsafe or untrusted code can be received in a variety of ways including documents (code embedded in postscript which is executed when viewed with ghostscript), and adding hardware such as USB memory sticks. The source of such code may not always be trusted and the receiver needs to ensure that the received code does not pose an unacceptable risk. There have been a number of approaches to ensuring security in the context of programs. These include security based on flow of information [26], abstract languages [2] and type systems [28]. In practice, tools that can automatically check for the validity of security properties is essential. Approaches such as FACADE [17] are designed for security in the context of smart cards. They use light weight type checking on the received code to perform simple sanity checks. Smart cards do not have sufficient compute power to verify dynamic properties of the received code. One can ensure that the code behaves properly in at least two main ways. The first is to monitor its execution. That is, checking application safety is done dynamically, at run time. Attacks based on buffer overflows [10] can be prevented by ensuring appropriate run-time checks. However, run-time checking is not entirely satisfactory as an unwanted and undesirable operation can occur before it can be checked. Undoing the effects of a partially executed program (e.g., files partially updated) is a major issue that needs to be addressed. Checking safety at run time also has a significant speed penalty. The second technique is to statically check the program before it is executed. These checks can be based on runtime restrictions, e.g., sandbox environments, in which the application is run. In such a design the environment defines a secure zone and allows only a restricted access to resources outside this zone. The main disadvantage is the limited expressiveness of applications that can be run within the sandbox environment. The proof-carrying code approach [24, 25] relaxes the sandbox restrictions. In this approach the code producer sends a proof of safety to the recipient. The receiver then has to check the veracity of the proof against the code before executing the code. This requires a tight coupling between the code producer and receiver as the proof produced has to be correctly interpreted by the receiver. Other disadvantages include the size of the proof that has to be shipped with the code and the type of properties that can be verified using this approach. Huang et al. [23] show how security of web applications can be improved by using a combination of static analysis and run-time monitoring. They do not use the full power of static analysis and use mainly syntax based analysers. For example, model checking [8] is not used in the verification process. Model checking is in principle an automatic technique that can be used to ensure that a program satisfies the specified properties. The program is modeled as an automaton and the properties are expressed in some form of temporal logic. For model checking to be automatic the program must have finite state. 2

By constructing suitable abstractions, programs which have potentially infinite state can be verified [21, 7, 4]. This paper describes a framework which can be used to ensure that any code received from an untrusted source is not malicious. The framework is primarily aimed at using static analysis including syntax based analysers and automatic verifiers like model checkers. The rest of the paper is organised as follows. Section 2 describes briefly the technology relevant to the framework. Section 3 introduces our new general architecture for mobile code while Section 4 presents a few examples which illustrate the use of the architecture.

2 Preliminaries In model checking [8] the program being verified is expressed as a finite state automaton and the properties are expressed in a suitable logic, for example, temporal logic. A model checker then verifies if the automaton satisfies the specification. If not, a run of the automaton is produced as a counter example. While model checking is aimed at the developer to improve reliability, it can be used in any situation where the model is available. The basic technique has been adapted to programs which are usually infinite state machines. In such cases, a suitable finite state abstraction of the program is created. In an abstraction, all information that is deemed not relevant to the properties being proved is left out. If the specified properties are verified in the abstraction, then the process terminates. Otherwise, it is necessary to check if the counter example in the model is actually a counter example. If it is an invalid counter example, the abstraction is refined [3, 20, 19, 12, 6, 15] and the new abstraction is verified. This process continues until either the program is verified, or a genuine counter example is produced. The process of abstraction is guided by the choice of predicates (which are conditions on program states) used to track the behaviour of the program. We first discuss Blast and Magic, which are two software verification tools based on model checking, as our initial experiments use them. Blast is a software verification tool used to verify C programs [21]. It uses assertions to reason about programs. Assertions are used to specify invariants of a particular system and usually added into the source program by the verifier. An assertion takes an expression as an argument. If the expression is true, the verification of the program continues. If the expression is false, the verification stops and reports that the system is unsafe. At this point a counterexample trace is given showing an example that made the system unsafe. Blast checks for potential assertion violations in a program by using an optimized abstract-model check-refine loop called lazy abstraction. Blast also have a more general language to write specifications which simplifies writing the desired properties. A Blast specification is a collection of events. Events contain three things: patterns, guards and actions. Patterns are used to match particular source program methods to specification events. Guards are equivalent to pre-conditions that must hold before the method is invoked. Actions are a set of instructions that are performed after the event is triggered and correspond to postconditions that must be true. Blast takes the specification and automatically incorporates it within the source program, to create an instrumented program that is the equivalent of the source program with assertions. Magic [7] is similar to Blast and also takes two inputs, viz., a C program, and a specification. The specifications for Magic are slightly different in that they are not pre or post conditions. Magic’s specifications are represented as extended finite state automata expressed as a collection of state transition

3

rules. Each rule has an initial state, and a set of rules that map inputs and outputs of a procedure to other states. The inputs and outputs of a procedure represent the transitions from one state to another. Magic has two special, predefined states: STOP and ERROR. The STOP state represents a finished safe state. If a procedure finishes in a STOP state, the procedure is considered safe. The ERROR state represents an error in the system. If at any time a procedure goes into an ERROR state, the verification system represents that the system is unsafe. In summary, Magic creates a valid abstraction and performs a reachability analysis. For Java programs we use Bandera [9], which is based on a collection of program analysis and transformation tools. A variety of techniques including slicing and abstraction is used by Bandera to extract a safe finite state program from the original Java source. The finite state program can then be verified using tools such as Spin [22] or Java PathFinder [18]. Bandera permits annotating code with assertions or one can also write temporal logic specifications. In the proof-carrying code (PCC) framework, the code producer creates a proof for a given program. This proof is a safety proof specifying that the program does nothing unsafe and adheres to the recipient’s safety policy. The supplied proof must adhere to the code recipient’s safety policy, and the proof itself must be verified to ensure that it has not been fabricated [25]. Since code producers create the proofs for their programs, proving program safety is left up to the producer, not the recipient. The code recipient has less work because checking a proof is easier and less time-consuming than generating a proof. As the programs are at the assembler level, issues such as compilation of code do not arise. In the PCC framework, the producer generates a proof, and the recipient verifies the proof. For the recipient to be able to verify the proof, the recipient must know the exact encoding of the proof. During the initial stages of the PCC procedure, there needs to be communication between the producer and recipient to agree upon which encoding, implementation and version each is using so that the recipient can understand the given proof, and furthermore verify it. This creates restrictions on the encodings and implementations that can be used to create and verify a proof. One of the disadvantages of this framework is the complex structure of the proofs. A key limiting factor is that checking the validity of the proof has to be automatic. Due to this structure, only a limited number of properties has been proved in the literature. Currently, there are examples of code and safety policies that prove properties for bounded memory, type safety, no overflows, and resource access. Another disadvantage is the size of the proofs relative to the program. Results gathered by an experiment conducted by Necula [24] found that in the PCC binaries, containing the application and the safety proof, the safety proof can be 700 the size of the native code. Model carrying code [27] is a technique requiring collaboration between the code generators and the recipients. While it uses verification techniques, the model is itself produced using execution monitoring. This is acceptable as the model is produced by the code generator. Hence, potentially unreliable code is not run on the receiver’s machine.

3 Architecture A pictorial view of our architecture is shown in Figure 1. It shows a possible scenario for the verification of mobile code between a code producer and a code recipient. The producer sends the code to the recipient who has a security policy governing code from the producer. The recipient can use a suite of

4

tools to verify the code. The actual tool chosen can depend on features of the code and the property that has to be verified. The recipient has to create a tool specific specification based on the security policy. In general the verification of a program requires creating an abstraction. The effectiveness of the abstraction process is dependent on the chosen predicates [15]. The code producer and receiver can co-operate to identify a potentially useful set of predicates. If the set of predicates identified is incorrect, it only slows down the verification process as no false positives are obtained. If no predicates are identified, tools such as Blast and Bandera can infer a basic set to start the verification process. Once an abstraction has been generated, it is then verified. If the abstraction passes the validation phase, then the code is first compiled, then executed on the recipient’s machine. If the abstraction fails the verification phase the code is not executed. Producer Source Program

Predicates

Receiver Tool1

Tool2

Tool3

Spec1

Spec2

Spec3

Security Policy

Figure 1: Architecture. There are many benefits to the proposed design. One of the main benefits is flexibility. The proposed design can use a variety of tools for verification. The complexity of the tool will depend on the property that needs to be verified. For instance, if the property that needs to be checked is syntactic, no sophisticated tool is necessary. As an example consider disallowing opening new windows in JavaScript programs. The only check is that the term window.open does not appear in the program. For the verification of the security properties, the code recipient generates an abstraction of the code. There is no communication between the code recipient and the code producer during the verification stages. Therefore, the abstraction algorithm and the verification method used is the code recipient’s choice. This makes the proposed model very flexible and can be viewed as a plug and play system as new tools can be added to it. One can also use tools such as Flawfinder, ITS4, and RATS [29] to detect potential flaws. The absence of these flaws can then be formally verified using any of the verification tools. Model checking by itself has its limitations. Model checking can be combined with static analysis to improve the type of properties that can be verified [14]. Another advantage of the proposed design is that the code recipient can now prove a broader range 5

of properties. This is possible because the code producer does not have to produce a proof that can be checked. For example, if a recipient’s safety policy was defined to exclude deadlocking in a program executed on their machine, then one could use a model checker tailored for that. As an consequence of this approach, fewer data need to be sent from a code producer to a code recipient. As one has received the code, it is possible to instrument it for various tests if checkers such as Verisoft [16] are used. This architecture can be used to increase the level of verification for smart cards. As suggested by Grimaud et al. [17] the smart card can consult any trusted authority, e.g., the card issuer to get its program verified. The trusted authority can implement such an architecture and verify the program received by the card. Therefore a defensive virtual machine [1] is not required on the smart card. The next section shows, via examples, the feasibility of such an architecture. It also demonstrates the need for different tools.

4 Examples The first example is a simple stack where a code producer writes code that pushes and pops elements to and from a stack. A code recipient may want some guarantee that the program doesn’t attempt to pop an empty stack or push onto a full stack. The possible behaviour of the program, viz., its abstraction is shown below.
89:; ?>=< OO

89:; ?>==< kk

// 

 

 

++

89:; ?>= 0 } action { empty--; } } 6

For Magic, however, a slightly different approach is required. The value returned by the program is used to determine the behaviour of the program. By using a special value to indicate the popping of an empty stack an error state can be identified. That is, in Magic the overall behaviour of the program is used to verify correctness while in Blast specifications for each operation are written. While both Blast and Magic are able to detect underflow, only Magic is realistically able to detect overflow. This is because the predicates given to Blast are too weak for the above pattern. Our next example is the behaviour of the JavaScript mentioned in Section 1 where a web page with embedded JavaScript can allow a user to upload a file to a server. In such a scenario, the user may want a guarantee that the file the JavaScript uploads is the file the user specified, and not another file. This scenario can be broadened to include any programming language. Given a program that processes (reads, writes, uploads, etc) a file specified by the user, a user may want a guarantee that the file the program processes is the file they specified. The specification is not on the states of the program but a relationship between values at particular states. Hence this example cannot be expressed in the proof carrying code framework. This example also illustrates the limitation of current verifiers and the strength of the architecture. Having access to the source code enables us to translate the received program into suitable input to other tools. This will become clear when the limitations of Blast and Magic are discussed. The abstract specification corresponds to the following automaton 


89:; ?>=< kk




// 

++ @ABC GFED

 



with the requirement that be identical to  . The abstract behaviour, along with the requirements that strings and  be identical cannot be specified in Magic. However, Blast is able to verify a limited form the correctness of the program. If the variable used to store the input filename is used for reading, Blast can verify the correctness. Blast is currently unable to verify that the values of different array variables are identical. Again there is a direct correspondence between the abstract specification and the specification used by Blast which is shown below. event { event { pattern {inputFile($1,$2);} pattern {processFile($1); } action {str = $2;} guard { str == $1} } } The method inputFile copies the name of the input in a local variable str and then ensures that when the file is being processed the correct file name is being used. Even if Magic is used, there is no danger of violating the requirement. Magic is conservative in that if a program cannot be verified it is flagged as having failed to meet the requirements. Hence, using Magic in the above instance only results in rejecting a potentially valid program. For examples involving arrays, a more sophisticated tool like SAL (Symbolic Analysis Laboratory) [13] or Bandera is useful. SAL supports reasoning about bounded arrays. If the file names are bounded in size, a complete model check can be performed. Otherwise, a bounded form of verification can be performed. If the received program was in Java, Bandera could be used in a similar fashion. The equality of file names can be expressed directly as an assertion. Bandera creates a finite state program by using the user specified range of parameters for potentially infinite values (including the maximum size of arrays). By setting this value to a sufficiently large realistic value a reasonable form of bounded verification is possible. 7

The next example is from Necula’s work [24] . It defines a   function that is created in a different implementation language than that of the rest of the program. The specification is that the foreign program must adhere to the data types of the original programming language, and must not violate any memory. As our architecture supposes having access to the source code, type checking can be handled by the compiler. The absence of memory violation can be expressed as a loop invariant. As this does not involve method calls, the event pattern specification used earlier for Blast cannot be used. We use the feature that allows for writing assertions in the code. By modifying the given code to include one line before the addition of the next element in the array, we can assert that the value of the index is within the specified range, viz., assert(index >= 0 && index < size). Our final example is a Java program involving threads that transfer money from one account to another. The amount of money transfered can be dependent on the current balance. Irrespective of the amount transfered, the total amount of money in the system must remain the same. This requirement is expressed as a global invariant. The buggy program does not transfer the money in an atomic fashion. Hence money can disappear (or even appear) in the system. The property to be verified cannot be expressed in the proof carrying code framework and is also representative of properties of many multi-player games that can be downloaded as applets. The relevant code fragments (which decrements an account and transfer the amount to another account) for the two threads are shown below (where lv and amt are local variables and ac1 and ac2 are the two accounts. lv = ac1.getBal(); lv = lv - amt; ac1.changeBal(lv); lv = ac2.getBal(); lv = lv + amt; ac2.changeBal(lv);

lv = ac2.getBal(); lv = lv - amt; ac2.changeBal(lv); lv = ac1.getBal(); lv = lv + amt; ac1.changeBal(lv);

The invariant is a simple post condition assertion on the sum of the balance of the two accounts. Bandera using Spin was able to disprove the invariant. However, if the operations were atomic, the Bandera was able to prove the validity of the invariant. The verification process required providing the correct range of values for the integer variables, viz., the balance in each account.

5 Evaluation We conclude this paper with a brief evaluation of our architecture and the open problems that need further research. As already indicated, Magic and Blast have different strengths and the ability to use a variety of tools on verifying similar properties is a definite advantage. In the stack example ensuring no overflow occurs can be verified by Blast for small stack sizes. However, on a realistic scale, Blast is unable to verify programs given such a property. However, for no underflow occurs, Blast is a better tool as pre/post conditions for the operation can be written. Also for the simple summation example, having the source code to insert the assertion into was useful. This is better than having to generate the code annotated with the proof and then having to check the proof. The cost of running the proof checker is similar to the cost of verification. The cost of a local compilation is not that significant (especially when compared to size of the proof that has to be shipped). Bandera’s current GUI interface imposed

8

more user interaction to verify the properties. But most of the interactions are very mechanical and can be automated by suitable scripts. For reasoning about properties of data structures, a more powerful tool (e.g., SAL) is necessary. In order to use SAL, the received program needs to be translated to the appropriate input. While we have not written any translator, we have followed a systematic hand translation for certain types of C programs. SAL has been designed as an intermediate language for standard languages like JAVA. If tools such as SAL are necessary, there is an extra cost of translating the received program. The majority of the time in the verification process was spent in converting the abstract safety policies into suitable inputs to the tool. For the properties considered here the process can in principle be automated. The open question is whether this can be automated in general, or for what class of properties can the translation be automated. Translation of policy specification languages such as Ponder [11] or logic based specifications [5] is currently under investigation. The ability to use syntax based tools to guide the verification process is also significant. The output from such tools can be transformed into specifications for the verification tools. For instance, running Flawfinder on the code representing the file upload script indicates that scanf can result in memory overflows. This can be translated to specifications (or assertions) for each array access and then verified using Blast or Magic. Currently this is not automatic. A translator to interpret the output from Flawfinder and translate it to verification conditions is necessary. We have used a number of tools to effect the verification of the different properties. If the entire process has to be automated it is essential to be able to choose the right tool. The process of choosing a tool is, in principle, linked to the translation of the policies. Therefore, the translation process needs to be augmented to provide guidelines which will assist in selecting the right collection of tools for the verification. In summary having a recipient-driven correctness framework is a promising architecture that is restricted only by what can be specified within the tools available.

Acknowledgments The authors thank the authors of the various tools for answering our questions on using their tools.

References [1] Java Card 2.1 Virutal Machine, Runtime Environment and Application Programming Interface Specifications. Technical report, Sun Microsystems Inc., 1999. Available at http://java.sun.com/produces/javacard/. [2] M. Abadi and A. D. Gordon. A Calculus for Cryptographic Protocols: The Spi Calculus. In Fourth ACM Conference on Computer and Communications Security, pages 36–47. ACM Press, 1997. [3] T. Ball, R. Majumdar, T. D. Millstein, and S. K. Rajamani. Automatic Predicate Abstraction of C Programs. In SIGPLAN Conference on Programming Language Design and Implementation, pages 203–213, 2001.

9

[4] T. Ball and S. Rajamani. The SLAM Project: Debugging System Software via Static Analysis. In ACM SIGPLAN-SIGACT Conference on Principles of Programming Languages, pages 1–3, 2002. [5] S. Barker and P. J. Stuckey. Flexible access control policy specification with constraint logic programming. ACM Transactions on Information and System Security (TISSEC), 6(4):501–546, November 2003. [6] M. Bourahla and M. Benmohamed. Predicate Abstraction and Refinement for Model Checking VHDL State Machines, 2002. [7] S. Chaki, E. Clarke, A. Groce, S. Jha, and H. Veith. Modular Verification of Software Components in C. In Proceedings of the 25th International Conference on Software engineering, pages 385–395. IEEE Computer Society, May 2003. [8] E. Clarke, O. Grumberg, and D. Peled. Model Checking. MIT Press, 1999. [9] J. Corbett, M. Dwyer, J. Hatcliff, C. Pasareanu, Robby, and H. Zheng. Bandera : Extracting Finite-state Models from Java Source Code. In Proceedings of the 22nd International Conference on Software Engineering, pages 439–448, June 2000. [10] C. Cowan, C. Pu, D. Maier, H. Hinton, P. Bakke, S. Beattie, A. Grier, P. Wagle, and Q. Zhang. StackGuard: Automatic detection and prevention of buffer-overflow attacks. In Proceedings of the 7th USENIX security symposium, 1998. [11] N. Damianou, N. Dulay, and M. Sloman E. Lupu. The ponder policy specification language. In Proceedings of Policy, number 1995 in LNCS, pages 18–39, 2001. [12] S. Das, D. L. Dill, and S. Park. Experience with Predicate Abstraction. Computer-Aided Verification, LNCS 1633:160–171, 1999. [13] L. de Moura, S. Owre, H. Rueß, J. Rushby, N. Shankar, M. Sorea, and A. Tiwari. SAL 2. In Rajeev Alur and Doron Peled, editors, Computer-Aided Verification, CAV 2004, volume 3114 of Lecture Notes in Computer Science, pages 496–500, Boston, MA, July 2004. Springer-Verlag. [14] D. Engler and M. Musuvathi. Static analysis versus software model checking for bug finding. In B. Steffen and G. Levi, editors, Verification, Model Checking, and Abstract Interpretation 5th International Conference, VMCAI, number 2937 in Lecture Notes in Computer Science, pages 191–210, Venice, 2004. [15] C. Flanagan and S. Qadeer. Predicate Abstraction for Software Verification. In Proceedings of the 29th ACM SIGPLAN-SIGACT symposium on Principles of Programming Languages, pages 191–202. ACM Press, 2002. [16] P. Godefroid, R. Hanmer, and L. Jategaonkar-Jagadeesan. Model checking without a model: An analysis of the heart beat monitor of a telephone switch using verisoft. In Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis, pages 124–133, 1998. 10

[17] G. Grimaud, J-L. Lanet, and J-J. Vandewalle. Facade: a typed intermediate language dedicated to smart cards. In Proceedings of the 7th European software engineering conference held jointly with the 7th ACM SIGSOFT international symposium on Foundations of software engineering, pages 476–493. Springer-Verlag, 1999. [18] K. Havelund and J. U. Skakkebaek. Applying Model Checking in Java Verification. In D. Dams, R. Gerth, S. Leue, and M. Massink, editors, Theoretical and Practical Aspects of SPIN Model Checking, LNCS 1680, pages 216–231. Springer Verlag, 1999. [19] T. Henzinger, R. Jhala, R. Majumdar, G. Necula, G. Sutre, and W. Weimer. Temporal-Safety Proofs for Systems Code. In Proceedings of the 14th Internation Conference on ComputerAided Verification, Lecture Notes in Computer Science 2404, pages 526–538. Springer-Verlag, 2002. [20] T. Henzinger, R. Jhala, R. Majumdar, and G. Sutre. Lazy abstraction. In Proceedings of the 29th Annual Symposium on Principles of Programming Languages, pages 58–70. ACM Press, 2002. [21] T. Henzinger, R. Jhala, R. Majumdar, and G. Sutre. Software Verification with BLAST. In Proceedings of the Tenth International Workshop on Model Checking of Software (SPIN), pages 235–239. Lecture Notes in Computer Science 2648, Springer-Verlag, 2003. [22] G. J. Holzmann. The Model Checker SPIN. IEEE Transactions on Software Engineering, 23(5):279–295, May 1997. [23] Y-W. Huang, F. Yu, C. Hang, C-H. Tsai, D-T. Lee, and S-Y. Kuo. Securing web application code by static analysis and runtime protection. In Proceedings of the 13th International Conference on World Wide Web, pages 40–52. ACM Press, 2004. [24] G. C. Necula. Proof-Carrying Code. In Proceedings of the 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL ’97), pages 106–119, Paris, France, Jan 1997. [25] G. C. Necula and P. Lee. Efficient Representation and Validation of Proofs. In Proceedings of the 13th Annual Symposium on Logic in Computer Science, pages 93–104. IEEE Computer Society, 1998. [26] A. Sabelfeld and A. Myers. Language-based information flow security. IEEE Journal on Selected Aread in Communications, 21(1):5–19, 2003. [27] R. Sekar, V. N. Venkatakrishnan, S. Basu, S. Bhatkar, and D. C. DuVarney. Model-carrying code: a practical approach for safe execution of untrusted applications. In Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles, pages 15–28. ACM Press, 2003. [28] D. Walker. A type system for expressive security policies. In Symposium on Principles of Programming Languages, pages 254–267. ACM, 2000. [29] John Wilander and Mariam Kamkar. A comparison of publicly available tools for dynamic buffer overflow prevention. In 10 Network and Distributed System Security Symposium. The Internet Society, 2003.


11