Dries Vanoverberghe

Security-by-contract on the .NET platform

Over the last few years, the success of GPS-enabled PDAs has finally instigated a breakthrough of mobile devices. Many people now already have a device that can connect to the Internet and run untrusted code, typically a cell-phone or PDA. Having such a large interconnected and powerful computing base presents some new security issues. In order to counter new threats, the traditional security architectures need to be overhauled to support a new and more flexible way of securely executing mobile code. This article describes the concept of security-by-contract (SxC) and its implementation on the .NET platform. This new model allows users to guarantee that an untrusted application remains within the boundaries of acceptable behavior, as defined by the user herself. A number of different techniques will be presented that can be employed to enforce this behavior. In order to support the SxC paradigm, some new steps can be introduced in the application development process. In addition to building an application, developers can create an application contract and securely bind this contract to the application. The application deployment process supports legacy applications developed without such contracts, but it can support more advanced enforcement technologies for those applications that are SxC-aware.

A flexible security architecture to support third-party applications on mobile devices

The problem of supporting the secure execution of potentially malicious third-party applications has received a considerable amount of attention in the past decade. In this paper we describe a security architecture for mobile devices that supports the flexible integration of a variety of advanced technologies for such secure execution of applications, including run-time monitoring, static verification and proof-carrying code. The architecture also supports the execution of legacy applications that have not been developed to take advantage of our architecture, though it can provide better performance and additional services for applications that are architecture-aware.The proposed architecture has been implemented on a Windows Mobile device with the .NET Compact Framework. It offers a substantial security benefit compared to the standard (state-of-practice) security architecture of such devices, even for legacy applications.

The S3MS.NET Run Time Monitor

This paper describes the S3MS.NET run time monitor, a tool that can enforce security policies expressed in a variety of policy languages for .NET desktop or mobile applications. The tool consists of two major parts: a bytecode inliner that rewrites .NET assemblies to insert calls to a policy decision point, and a policy compiler that compiles source policies to executable policy decision points. The tool supports both singlethreaded and multithreaded applications, and is sufficiently mature to be used on real-world applications. This paper describes the overall functionality and architecture of the tool, discusses its strengths and weaknesses, and reports on our experience with using the tool on case studies as well as in teaching.

A Caller-Side Inline Reference Monitor for an Object-Oriented Intermediate Language

Runtime security policy enforcement systems are crucial to limit the risks associated with running untrustworthy (malicious or buggy) code. The inlined reference monitor approach to policy enforcement, pioneered by Erlingsson and Schneider, implements runtime enforcement through program rewriting: security checks are inserted inside untrusted programs. Ensuring complete mediation --- the guarantee that every security-relevant event is actually intercepted by the monitor --- is non-trivial when the program rewriter operates on an object-oriented intermediate language with state-of-the-art features such as virtual methods and delegates. This paper proposes a caller-side rewriting algorithm for MSIL --- the bytecode of the .NET virtual machine --- where security checks are inserted around calls to security-relevant methods. We prove that this algorithm achieves sound and complete mediation and transparency for a simplified model of MSIL, and we report on our experiences with the implementation of the algorithm for full MSIL.

Test Input Generation for Programs with Pointers

Software testing is an essential process to improve software quality in practice. Researchers have proposed several techniques to automate parts of this process. In particular, symbolic execution can be used to automatically generate a set of test inputs that achieves high code coverage. However, most state-of-the-art symbolic execution approaches cannot directly handle programs whose inputs are pointers, as is often the case for C programs. Automatically generating test inputs for pointer manipulating code such as a linked list or balanced tree implementation remains a challenge. Eagerly enumerating all possible heap shapes forfeits the advantages of symbolic execution. Alternatively, for a tester, writing assumptions to express the disjointness of memory regions addressed by input pointers is a tedious and labor-intensive task. This paper proposes a novel solution for this problem: by exploiting type information, disjointness constraints that characterize permissible configurations of typed pointers in byte-addressable memory can be automatically generated. As a result, the constraint solver can automatically generate relevant heap shapes for the program under test. We report on our experience with an implementation of this approach in Pex, a dynamic symbolic execution framework for .NET. We examine two different symbolic representations for typed memory, and we discuss the impact of various optimizations.

Security enforcement aware software development

In the domain of security policy enforcement, the concerns of application developers are almost completely ignored. As a consequence, it is hard to develop useful and reliable applications that will function properly under a variety of policies. This paper addresses this issue for application security policies specified as security automata, and enforced through run-time monitoring. Our solution consists of three elements: the definition of an abstract interface to the policy that is being enforced, a sound construct to query that policy, and a static verification algorithm that guarantees absence of security policy violations in critical blocks of code.

State coverage: software validation metrics beyond code coverage

Currently, testing is still the most important approach to reduce the amount of software defects. Software quality metrics help to prioritize where additional testing is necessary by measuring the quality of the code. Most approaches to estimate whether some unit of code is sufficiently tested are based on code coverage, which measures what code fragments are exercised by the test suite. Unfortunately, code coverage does not measure to what extent the test suite checks the intended functionality. We propose state coverage , a metric that measures the ratio of state updates that are read by assertions with respect to the total number of state updates, and we present efficient algorithms to measure state coverage. Like code coverage, state coverage is simple to understand and we show that it is effective to measure and easy to aggregate. During a preliminary evaluation on several open-source libraries, state coverage helped to identify multiple unchecked properties and detect several bugs.

Evolution of security engineering artifacts: a state of the art survey

Security is an important quality aspect of modern open software systems. However, it is challenging to keep such systems secure because of evolution. Security evolution can only be managed adequately if it is considered for all artifacts throughout the software development lifecycle. This article provides state of the art on the evolution of security engineering artifacts. The article covers the state of the art on evolution of security requirements, security architectures, secure code, security tests, security models, and security risks as well as security monitoring. For each of these artifacts the authors give an overview of evolution and security aspects and discuss the state of the art on its security evolution in detail. Based on this comprehensive survey, they summarize key issues and discuss directions of future research.

Theoretical aspects of compositional symbolic execution

Given a program and an assertion in that program, determining if the assertion can fail is one of the key applications of program analysis. Symbolic execution is a well-known technique for finding such assertion violations that can enjoy the following two interesting properties. First, symbolic execution can be precise: if it reports that an assertion can fail, then there is an execution of the program that will make the assertion fail. Second, it can be progressing: if there is an execution that makes the assertion fail, it will eventually be found. A symbolic execution algorithm that is both precise and progressing is a semidecision procedure. Recently, compositional symbolic execution has been proposed. It improves scalability by analyzing each execution path of each method only once. However, proving precision and progress is more challenging for these compositional algorithms. This paper investigates under what conditions a compositional algorithm is precise and progressing (and hence a semi-decision procedure).

Using Dynamic Symbolic Execution to Improve Deductive Verification

One of the most challenging problems in deductive program verification is to find inductive program invariants typically expressed using quantifiers. With strong-enough invariants, existing provers can often prove that a program satisfies its specification. However, provers by themselves do not find such invariants. We propose to automatically generate executable test cases from failed proof attempts using dynamic symbolic execution by exploring program code as well as contracts with quantifiers. A developer can analyze the test cases with a traditional debugger to determine the cause of the error; the developer may then correct the program or the contracts and repeat the process.