AD5014: UseAddressSanitizer¶

Summary¶

Description¶

AddressSanitizer (ASAN) is a fast memory error detector that can catch: - Heap buffer overflows - Stack buffer overflows - Global buffer overflows - Use-after-free errors - Use-after-return errors (with ASAN_OPTIONS=detect_stack_use_after_return=1) - Use-after-scope errors - Double-free errors - Memory leaks (with LeakSanitizer)

ASAN works by instrumenting memory access operations at compile time and using a shadow memory scheme to track the validity of memory regions.

Why This Matters¶

Memory safety bugs are consistently ranked among the most severe and exploitable vulnerability classes. According to Google's security research, approximately 70% of high-severity security bugs in Chrome are memory safety issues. Similar statistics apply across the software industry—Microsoft, Apple, and Mozilla all report that memory corruption bugs dominate their security vulnerability counts.

The Detection Gap¶

Memory corruption bugs are notoriously difficult to detect through traditional testing:

1. Non-Deterministic Behavior: Buffer overflows, use-after-free, and similar bugs may not crash immediately. The program might continue running with corrupted state, only failing much later or under specific conditions.

2. Heisenbugs: The act of debugging (adding print statements, running in a debugger) can change memory layout enough to mask bugs that appear in production.

3. Conditional Triggers: Many memory bugs only manifest with specific input sizes, timing conditions, or memory layouts that standard test suites don't cover.

4. Silent Corruption: Data corruption may go unnoticed, leading to incorrect results, data loss, or security bypasses without any visible error.

How ASAN Helps¶

AddressSanitizer transforms your binary to detect memory errors at the moment they occur:

• Immediate Detection: ASAN crashes with a detailed report the instant a memory violation happens, not minutes or hours later when the corruption causes visible problems.

• Precise Diagnostics: Reports include the exact location of the bug, the type of violation, allocation/deallocation stack traces, and shadow memory state.

• High Coverage: ASAN catches bug classes that are nearly impossible to find otherwise—use-after-free in complex object lifecycles, subtle off-by-one errors, stack corruption from deep call chains.

Performance Trade-offs¶

ASAN's overhead makes it unsuitable for production, but this is by design:

These costs are well worth paying during development and CI/CD testing. Many organizations run ASAN-instrumented builds in continuous testing to catch regressions immediately.

Industry Best Practices¶

Leading security-conscious organizations mandate ASAN usage:

• Google: All Chrome and Android code runs through ASAN testing; OSS-Fuzz uses ASAN by default
• Apple: Xcode prominently features ASAN integration; recommended for all development
• Microsoft: Visual Studio includes ASAN; used extensively in Windows development
• LLVM/Clang: ASAN was developed at Google and is now a standard compiler feature

Note: This rule produces a "Note" level result, not an error, because ASAN is intended for development and testing builds, not production deployment.

Resolution¶

Enable AddressSanitizer during development and testing:

Compiler Flags¶

# For Clang/LLVM (recommended for macOS)
clang -fsanitize=address -g your_code.c

# Also add these for better diagnostics
clang -fsanitize=address -fno-omit-frame-pointer -g your_code.c

Xcode¶

1. Select your target
2. Go to Build Settings
3. Search for "Address Sanitizer"
4. Set "Enable Address Sanitizer" to Yes

CMake¶

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address")

Detection¶

This rule detects ASAN by checking for characteristic symbols like: - __asan_init - __asan_report_load - __asan_report_store - __asan_register_globals

References¶

• AddressSanitizer Documentation
• Apple Developer: Diagnosing Memory Issues
• Google Sanitizers Wiki