277 research outputs found
Relational Symbolic Execution
Symbolic execution is a classical program analysis technique used to show
that programs satisfy or violate given specifications. In this work we
generalize symbolic execution to support program analysis for relational
specifications in the form of relational properties - these are properties
about two runs of two programs on related inputs, or about two executions of a
single program on related inputs. Relational properties are useful to formalize
notions in security and privacy, and to reason about program optimizations. We
design a relational symbolic execution engine, named RelSym which supports
interactive refutation, as well as proving of relational properties for
programs written in a language with arrays and for-like loops
CONFLLVM: A Compiler for Enforcing Data Confidentiality in Low-Level Code
We present an instrumenting compiler for enforcing data confidentiality in
low-level applications (e.g. those written in C) in the presence of an active
adversary. In our approach, the programmer marks secret data by writing
lightweight annotations on top-level definitions in the source code. The
compiler then uses a static flow analysis coupled with efficient runtime
instrumentation, a custom memory layout, and custom control-flow integrity
checks to prevent data leaks even in the presence of low-level attacks. We have
implemented our scheme as part of the LLVM compiler. We evaluate it on the SPEC
micro-benchmarks for performance, and on larger, real-world applications
(including OpenLDAP, which is around 300KLoC) for programmer overhead required
to restructure the application when protecting the sensitive data such as
passwords. We find that performance overheads introduced by our instrumentation
are moderate (average 12% on SPEC), and the programmer effort to port OpenLDAP
is only about 160 LoC.Comment: Technical report for CONFLLVM: A Compiler for Enforcing Data
Confidentiality in Low-Level Code, appearing at EuroSys 201
A brief tour of formally secure compilation
Modern programming languages provide helpful high-level abstractions and mechanisms (e.g. types, module, automatic memory management) that enforce good programming practices and are crucial when writing correct and secure code. However, the security guarantees provided by such abstractions are not preserved when a compiler translates a source program into object code. Formally secure compilation is an emerging research field concerned with the design and the implementation of compilers that preserve source-level security properties at the object level. This paper presents a short guided tour of the relevant literature on secure compilation. Our goal is to help newcomers to grasp the basic concepts of this field and, for this reason, we rephrase and present the most relevant results in the literature in a common setting
Verifying Data Constraint Equivalence in FinTech Systems
Data constraints are widely used in FinTech systems for monitoring data
consistency and diagnosing anomalous data manipulations. However, many
equivalent data constraints are created redundantly during the development
cycle, slowing down the FinTech systems and causing unnecessary alerts. We
present EqDAC, an efficient decision procedure to determine the data constraint
equivalence. We first propose the symbolic representation for semantic encoding
and then introduce two light-weighted analyses to refute and prove the
equivalence, respectively, which are proved to achieve in polynomial time. We
evaluate EqDAC upon 30,801 data constraints in a FinTech system. It is shown
that EqDAC detects 11,538 equivalent data constraints in three hours. It also
supports efficient equivalence searching with an average time cost of 1.22
seconds, enabling the system to check new data constraints upon submission.Comment: 14 pages, 11 figures, accepted by ICSE 202
HasTEE: Programming Trusted Execution Environments with Haskell
Trusted Execution Environments (TEEs) are hardware-enforced memory isolation
units, emerging as a pivotal security solution for security-critical
applications. TEEs, like Intel SGX and ARM TrustZone, allow the isolation of
confidential code and data within an untrusted host environment, such as the
cloud and IoT. Despite strong security guarantees, TEE adoption has been
hindered by an awkward programming model. This model requires manual
application partitioning and the use of error-prone, memory-unsafe, and
potentially information-leaking low-level C/C++ libraries.
We address the above with \textit{HasTEE}, a domain-specific language (DSL)
embedded in Haskell for programming TEE applications. HasTEE includes a port of
the GHC runtime for the Intel-SGX TEE. HasTEE uses Haskell's type system to
automatically partition an application and to enforce \textit{Information Flow
Control} on confidential data. The DSL, being embedded in Haskell, allows for
the usage of higher-order functions, monads, and a restricted set of I/O
operations to write any standard Haskell application. Contrary to previous
work, HasTEE is lightweight, simple, and is provided as a \emph{simple security
library}; thus avoiding any GHC modifications. We show the applicability of
HasTEE by implementing case studies on federated learning, an encrypted
password wallet, and a differentially-private data clean room.Comment: To appear in Haskell Symposium 202
Large-Scale Analysis of Framework-Specific Exceptions in Android Apps
Mobile apps have become ubiquitous. For app developers, it is a key priority
to ensure their apps' correctness and reliability. However, many apps still
suffer from occasional to frequent crashes, weakening their competitive edge.
Large-scale, deep analyses of the characteristics of real-world app crashes can
provide useful insights to guide developers, or help improve testing and
analysis tools. However, such studies do not exist -- this paper fills this
gap. Over a four-month long effort, we have collected 16,245 unique exception
traces from 2,486 open-source Android apps, and observed that
framework-specific exceptions account for the majority of these crashes. We
then extensively investigated the 8,243 framework-specific exceptions (which
took six person-months): (1) identifying their characteristics (e.g.,
manifestation locations, common fault categories), (2) evaluating their
manifestation via state-of-the-art bug detection techniques, and (3) reviewing
their fixes. Besides the insights they provide, these findings motivate and
enable follow-up research on mobile apps, such as bug detection, fault
localization and patch generation. In addition, to demonstrate the utility of
our findings, we have optimized Stoat, a dynamic testing tool, and implemented
ExLocator, an exception localization tool, for Android apps. Stoat is able to
quickly uncover three previously-unknown, confirmed/fixed crashes in Gmail and
Google+; ExLocator is capable of precisely locating the root causes of
identified exceptions in real-world apps. Our substantial dataset is made
publicly available to share with and benefit the community.Comment: ICSE'18: the 40th International Conference on Software Engineerin
- …