Addressing covert termination and timing channels in concurrent information flow systems

Abstract

When termination of a program is observable by an adversary, confidential information may be leaked by terminating accordingly. While this termination covert channel has limited bandwidth for sequential programs, it is a more dangerous source of information leakage in concurrent settings. We address concurrent termination and timing channels by presenting a dynamic information-flow control system that mitigates and eliminates these channels while allowing termination and timing to depend on secret values. Intuitively, we leverage concurrency by placing such potentially sensitive actions in separate threads. While termination and timing of these threads may expose secret values, our system requires any thread observing these properties to raise its information-flow label accordingly, preventing leaks to lower-labeled contexts. We implement this approach in a Haskell library and demonstrate its applicability by building a web server that uses information-flow control to restrict untrusted web applications.

Static Enforcement of Security in Runtime Systems

“…Once we have the possibility of allocating memory on the heap, we can use the same instantiation language MS to implement a thread scheduler. Concurrency has received a lot of attention in the literature on language-based security [15], [28], [29], [31], [32], [40], especially in the context of timing-channels. Several authors [15], [28], [32] propose special-purpose thread schedulers designed to close such timingchannels, and in this section we present an implementation of a secure cooperative thread scheduling algorithm.…”

“…Concurrency has received a lot of attention in the literature on language-based security [15], [28], [29], [31], [32], [40], especially in the context of timing-channels. Several authors [15], [28], [32] propose special-purpose thread schedulers designed to close such timingchannels, and in this section we present an implementation of a secure cooperative thread scheduling algorithm. For the purpose of this case study, each function written by the user is assumed to have been rewritten into continuation passing style (CPS), as is standard for many compilers for functional programming languages [3], [14], and defunctionalized into a form that contains no higher-order functions, i.e., closure is an identifier followed by a heterogeneous array of local variables.…”

“…Root pointers typically include the local variables stored on the call stack, and thus the RTE must traverse every stack frame currently stored on the call stack, potentially breaking local state encapsulation [30]. Even worse is the situation from a security perspective, where operations carried out by an RTE might reveal confidential information about the data handled by the user-written programs through storage-or timing channels [24], [29], [32], [37].…”

Foundations for Parallel Information Flow Control Runtime Systems

“…For example, even exposing language features as simple as -statements can expose users to timing attacks [42,64]. Researchers have made significant strides towards addressing these challenges-many IFC systems now support real-world features and abstractions safely [10,15,20,34,43,50,51,54,55,59,60,62,67,68]. To the best of our knowledge, though, no existing language-level dynamic IFC supports parallelism.…”

“…For example, modern Web applications typically handle user requests in parallel, on multiple CPU cores, taking advantage of modern hardware. Web applications built atop state-of-the-art dynamic IFC Web frameworks (e.g., Jacqueline [67], Hails [12,13], and LMonad [45]), unfortunately, do not handle user requests in parallel-the language-level IFC systems that underlie them (e.g., Jeeves [68] and LIO [54]) do not support parallel thread execution.…”