Freelance journalist, mostly IT security topics.
Fuzzing Project: Improve the security of free software, supported by Linux Foundation's Core Infrastructure Initiative.
Memory corruption, buffer overflows, double free, use after free, out of bounds reads, ...
Summary: Software reads or writes memory it shouldn't.
Accessing invalid memory is "undefined behavior".
How about a C variant that prevents invalid memory access?
Acceptable overhead (50-100% performance, lots of memory)
Practical - works usually out of the box
Can we have a Linux full system built with Address Sanitizer?
Just add -fsanitize=address to the CFLAGS and recompile everything.
If only it were that easy...
gcc, glibc - difficult, recursion problems, let's exclude them
ASAN executable, non-ASAN library: fine
ASAN library, non-ASAN executable: breaks
Consider compilation order and dependencies.
ASAN terminates software if it reads invalid memory.
So we can't run software that always reads invalid memory...
Bugs fixed in Bash, Coreutils, man-db, syslog-ng, screen, nano, ...
"This is a false positive, it must be a bug in Address Sanitizer"
Reading invalid memory is not correct, even if you don't use what you read.
Such code is "undefined behavior": Can break under different compiler / OS / architecture.
Bugs and false positives with ASAN are extremely rare.
When linking shared libraries libtool filters unknown flags from LDFLAGS: Breaks ASAN builds.
Fix upstream (not released), but scripts bundled (ltmain.sh).
Workaround via portage hook.
libasan provides pthread_create(), but not full pthread API.
configure scripts check for pthread_create(), assume -lpthread not needed.
Perl: Uses LD_PRELOAD for libperl, uses miniperl to run compilation perl script.
If you LD_PRELOAD an ASAN library you can't run non-ASAN executables: GCC segfaults.
(Still looking for a good workaround the Perl devs might accept)
It finds bugs, that's good.
Usefulness as an exploit mitigation system unclear.
Tor hardened browser already using it.
Prevents all linear buffer overflows and out of bounds reads.
Non-linear out of bounds access might still be exploitable.
Use after free - limited protection.
ASAN might introduce new attack vectors.
Maybe in the future there will be something like ASAN, but better.
Fixing the bugs ASAN finds now is a good preparation.
Exploit mitigation old: DEP, ASLR, Stack Canaries (old).
New: LLVM Code-Flow Integrity and Safe-Stack.
Sometimes applications disable or redirect stderr - you can't see the ASAN error.
ASAN can log errors into files.
UBSAN: Undefined behavior (things like invalid shifts, signed overflows, unaligned access)
"Problem:" It finds so many things...
TSAN: Thread Sanitizer (race conditions)
MSAM: Memory Sanitizer (uninitialized memory)