In spite of recent advances, the world wide web remains
an important vector for malware installation. Approaches
to evaluating potentially malicious code before execution in a
browser, such as blacklisting or content-based detection are
hindered by an attacker’s ability to easily change hosting domains
or mutate malware binaries. On the other hand, whitelistbased
approaches are challenged by the large, dynamic, and
heterogeneous space of benign binaries that they must track. In
practice these approaches continue to provide value for popular
binaries at either extreme of maliciousness (e.g., the current large
outbreak of malware, the benign binaries shipped with an OS),
but bridging the gap between whitelist and blacklist detection
for web malware remains a significant challenge.
This paper presents CAMP, a content-agnostic malware protection
system based on binary reputation that is designed to
address these shortcomings. CAMP is built into the browser and
determines the reputation of most downloads locally, relying on
server-side reputation data only when a local decision cannot be
made. This paper gives a detailed overview of CAMP and its
architecture and provides an evaluation of the system through
a six-month deployment in which 200 million users of Google
Chrome requested between eight to ten million reputation requests
a day. Our evaluation shows that CAMP exhibits accuracy
close to 99% relative to proprietary VM-based dynamic analysis,
is able to process requests in less than 130 ms on average, and
was able to detect approximately five million intentional malware
downloads per month that were not detected by existing solutions.
Static analysis tools help developers find bugs, improve
code readability, and ensure consistent style across a
project. However, these tools can be difficult to smoothly integrate
with each other and into the developer workflow, particularly
when scaling to large codebases. We present TRICORDER,
a program analysis platform aimed at building a data-driven
ecosystem around program analysis. We present a set of guiding
principles for our program analysis tools and a scalable architecture
for an analysis platform implementing these principles.
We include an empirical, in-situ evaluation of the tool as it is
used by developers across Google that shows the usefulness and
impact of the platform.
Dynamic program analysis and testing tools typically require inserting extra instrumentation code into the program to test. The inserted instrumentation then gathers data about the program execution and hands it off to the analysis algorithm. Various analysis algorithms can be used to perform CPU profiling, processor cache simulation, memory error detection, data race detection, etc. Usually the instrumentation is done either at run time or atcompile time – called dynamic instrumentation and compiler instrumentation, respectively. However, each of these methods has to make a compromise between performance and versatil-ity when used in industry software development. This paper presents a combined approach to instrumentationwhich takes the best of the two worlds – the low run-time overhead and unique features of compile-time instrumentation and the flexibility of dynamic instrumentation. Wepresent modifications of two testing tools that benefit from thisapproach: AddressSanitizer and MemorySanitizer. We propose benchmarks to compare different instrumentation frameworks in conditions specific to hybrid instrumenta-tion. We discuss the changes we made to one of the state-of-the-art instrumentation frameworks to significantly improve the performance of hybrid tools.
Using static analysis tools for automating code
inspections can be beneficial for software engineers. Such tools
can make finding bugs, or software defects, faster and cheaper
than manual inspections. Despite the benefits of using static
analysis tools to find bugs, research suggests that these tools
are underused. In this paper, we investigate why developers
are not widely using static analysis tools and how current tools
could potentially be improved. We conducted interviews with 20
developers and found that although all of our participants felt
that use is beneficial, false positives and the way in which the
warnings are presented, among other things, are barriers to use.
We discuss several implications of these results, such as the need
for an interactive mechanism to help developers fix defects.
Memory access bugs, including buffer overflows and
uses of freed heap memory, remain a serious problem for
programming languages like C and C++. Many memory
error detectors exist, but most of them are either slow or
detect a limited set of bugs, or both.
This paper presents AddressSanitizer, a new memory
error detector. Our tool finds out-of-bounds accesses to
heap, stack, and global objects, as well as use-after-free
bugs. It employs a specialized memory allocator and
code instrumentation that is simple enough to be implemented
in any compiler, binary translation system, or
even in hardware.
AddressSanitizer achieves efficiency without sacrificing
comprehensiveness. Its average slowdown is just
73% yet it accurately detects bugs at the point of occurrence.
It has found over 300 previously unknown bugs in
the Chromium browser and many bugs in other software.