Preventing Information Leaks through Shadow Executions

Abstract

A concern about personal information confidentiality typically arises when any desktop application communicates to the external network, for example, to its producer's server for obtaining software version updates. We address this confidentiality concern of end users by an approach called shadow execution. A key property of shadow execution is that it allows applications to successfully communicate over the network while disallowing any information leaks. We describe the design and implementation of this approach for Windows applications. Experiments with our prototype implementation indicate that shadow execution allows applications to execute without inhibiting any behaviors, has acceptable performance overheads while preventing any information leaks.

Secure multi-execution of web scripts: Theory and practice

“…Two of the papers discussed above ( [16] and [12]) also consider SME-style approaches to information flow security in a browser. But there are important differences with FlowFox.…”

“…They partition a program in two programs at source code level and use system call interposition to implement the I/O rules. In followup work, Capizzi et al [16] avoid the need for source level partitioning by means of shadow executions: they run two executions of processes for the H (secret) and L (public) security level to provide strong confidentiality guarantees. Devriese and Piessens [24] independently came up with the closely related technique they called SME, and they were the first to prove the strong soundness and precision guarantees that SME offers.…”

“…But there are important differences with FlowFox. Both Bielova et al [12] and Capizzi et al [16] propose to multi-execute the entire browser: the DOM API interactions become internal interactions and each SME copy of the browser has its own copy of the DOM.…”

“…Secure multi-execution (SME) [24,16] is a dynamic enforcement mechanism for information flow security with practical advantages when applied in the context of JavaScript web applications [24,§VI.D].…”

Purpose Restrictions on Information Use

“…However, prior methods of detecting noninterference have typically required access to the program running the system in question. These analyses either used the program for directly analyzing its code (see [9] for a survey), for running an instrumented version of the system (e.g., [10][11][12][13]), or for simulating multiple executions of the system (e.g., [14][15][16]). Traditionally, the requirement of access to the program has not been problematic since the analysis has been motivated as a tool for software engineers securing a program that they have designed.…”