ASAP
ASAP makes it possible to use powerful software protection mechanisms at a low performance overhead. These mechanisms use run-time checks to harden software against buffer overflows, undefined behavior, and vulnerabilities. ASAP analyzes all available checks and finds those that won’t slow the program down. Thus ASAP delivers most of the available security at a fraction of the usual overhead.
Security through checks
Developers use tools such as AddressSanitizer to harden their programs and test them against memory errors and other bugs. Such tools insert thousands of run-time checks into a program to guard each critical operation, e.g., each memory access. Executing these checks costs precious CPU time, which is why checks are rarely present in production software.
ASAP’s insights
Checks vary in their cost and security contributions. In practice, most overhead is due to only a few checks in hot parts of the program. These get executed many times and accumulate lots of CPU cycles.
On the other hand, checks that contribute most to security tend to be cheap, because they guard rarely-used operations in obscure parts of the code. Our experiments show that 83% of all CVE vulnerabilities lie in such cold parts of a program.
Controlling the trade-off
ASAP automatically recognizes security checks in program bitcode. During a profiling run, it measures precisely how much each check contributes to overhead. With this information, ASAP can then generate a program binary that is as safe as possible for a given, user-specified overhead budget.
Users of ASAP can easily audit where the tool removed a safety check, and can use the fraction of remaining checks as computed by ASAP to make an informed choice in the security vs. performance trade-off.
Publications
High System-Code Security with Low Overhead.
Jonas Wagner, Volodymyr Kuznetsov, George Candea, and Johannes Kinder.
IEEE Symposium on Security and Privacy (S&P), San Jose, CA, May 2015
Paper |
Video |
Slides
ASAP: High Security at Low Overhead.
Jonas Wagner, Volodymyr Kuznetsov, Johannes Kinder, Azqa Nadeem, and George
Candea.
A Poster presented at the Usenix Symposium on Operating Systems Design and
Implementation (OSDI) 2014.
Poster
Getting the Code
ASAP is publicly available: dslab-epfl/asap on GitHub
The screencast to the right has step-by-step instructions on how to obtain, install, and use ASAP. In addition, you can download a script containing all the instructions from the screencast.
ASAP has been tested to work on Linux and Mac OS X. It is based on LLVM 3.7, and shares LLVM’s build dependencies.
Frequently Asked Questions
How to measure the security of programs optimized using ASAP?
ASAP computes a sanity level, i.e., the fraction of critical operations that are guarded by a security check. In practice, the sanity level is a lower bound on the fraction of bugs or vulnerabilities that the program is protected against. This is because our experiments show that most bugs hide in cold parts of the code, where ASAP does not remove checks.
Does this mean ASAP makes my programs less secure?
The security you get depends on your chosen overhead budget. What ASAP provides is precise control over the trade-off between overhead and security. Note that perfect security is a myth; even fully protected programs are vulnerable to some degree due to unprotected third-party libraries, inline assembly code, bugs in language runtimes, etc.
What security/overhead can I expect in practice?
Without ASAP, a tool such as AddressSanitizer will incur an average overhead of ~74%. With ASAP, the overhead is below 10% in many cases, even though more than 90% of the security checks are preserved.
We are still working on improving the performance delivered by ASAP. While ASAP can adjust the performance loss due to security checks, our measurements indicate that instrumentation tools also produce other kinds of overhead (due to, e.g., increased register pressure or changes to the memory allocator). Our goal is to tackle these overheads one by one, until the total is low enough to run hardened programs in production environments.
Will ASAP work with …?
We’ve tested ASAP on Python, OpenSSL, the SPEC CPU2006 benchmarks, several Phoronix benchmarks, and the Chromium browser. Results vary; to give an example, ASAP can protect a web server against the OpenSSL Heartbleed vulnerability with 7% reduction in the server’s throughput.
ASAP is compatible with a number of instrumentation tools. We’ve tested AddressSanitizer, UndefinedBehaviorSanitizer and SoftBound.
Contact
Please send an email to Jonas Wagner if you have questions or comments regarding ASAP.