Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Feb 2016 17:24:40 -0800
From: Konstantin Serebryany <>
Subject: Re: Address Sanitizer local root

[I'm one of the asan authors]

Thanks for the detailed explanation of why asan is not a hardening
I agree with most points here but they are not needed simply because asan
is so complex that it can not possibly be verifiable as a secure hardening

However using asan in production is sometimes desirable for *testing*
to find the last remaining bugs.

More comments below.

On Wed, Feb 17, 2016 at 2:19 PM, Szabolcs Nagy <> wrote:

> There is an alarming trend that Address Sanitizer and related
> compiler instrumentations from compiler-rt are used as a hardening
> solution and run in production.
> Even though these are debugging and testing tools, there is
> no clear warning against production use in their documentation:
> And it's obvious how a tool that catches UB can be misunderstood
> as a hardening tool:
> This analysis concluded that ASan can be used for protection
> to stop certain attacks:
> The Tor project distributes ASan "hardened" binaries:
> And there are various projects for full Linux distro instrumentation:
> (the later was presented at FOSDEM 2016:
> )

The linux dostros with asan are primarily for *testing*, not hardening. (At
least in my view)

> While these are interesting projects, ASan should not be
> used for hardening in production systems in its current form,
> so at least the language ("hardening", "protection", "safe")
> should be fixed.
> My simple local root exploit is that ASan uses a lot
> of environment variables without checking for secure
> execution of setuid binaries:
> ASAN_OPTIONS='verbosity=2 log_path=foo' ./suid.exe
> will write to foo.$PID using escalated priviledge, so a
> normal user may be able to clobber arbitrary root owned files
> (by creating foo.{1,2,3,..} symlinks to it) which can lead
> to local root on an "ASan hardened" Linux distribution:
> ASAN_OPTIONS='suppressions="/foo
> root:passwdhash:12345:0:::::
> bar" log_path=foo' ./suid.exe
> can easily clobber /etc/shadow with

> AddressSanitizer: failed to read suppressions file '/foo
> root:passwdhash:12345:0:::::
> bar'


> if there is any setuid root executable built with ASan.
> (This is not a problem for testing where the env var based
> configuration is convenient and I haven't checked if any
> of the current ASan distro efforts have setuid executables
> with instrumentation, but I still find it a security bug
> given the improper advertisment of the sanitizer tools:
> this can lead to problems if the documentation is not fixed.)
> Beyond this trivial issue there are plenty reliability
> problems in the sanitizer runtimes that i think deserve
> at least a warning. It can crash conforming applications
> because
> - the shadow map overlaps with something
> - ulimit -v
> - overcommit is turned off
> - it allocates memory but aborts on failure
> - it interposes __tls_get_addr with non-as-safe code.
> - it uses initial-exec TLS.
> - it handles "deadly" signals like SIGBUS
>   (often used by applications using mmaped files).
> - the c runtime is updated and incompatible
>   (with the various interposition hacks)
> - does not handle c11 thread creation
> some of the features reduce security:
> - heuristic introspective unwind
> - nice diagnositc messages at undefined behaviour
> - interpositions in general (UB according to POSIX)
> other limitations:
> - static linking is not supported
> (This is for ASan only, I briefly looked at thread
> sanitizer, which seemed even worse for reliability
> and safe stack

> that is in fact advertised for hardening
> but it has plenty reliability problems, needs further
> analysis.)

safe stack is a new thing, not really well tuned and polished,
but I would love to hear your analysis because we do expect safe stack to
become a hardening tool.

Also, WDYT about ?

> I believe some of the problems can be fixed by
> implementing the runtimes in the libc instead of

Many other problems will be solved by implementing asan/tsan/msan/lsan as
part of a libc.

> second guessing libc behaviour with fragile
> heuristics from a compiler runtime.   This would solve
> most of the runtime aborts.  I can see an easy way to do
> this with musl libc

Yes, please!

> (because a non-host musl is easy to
> distribute and link against), but non-trivial with glibc.
> In either case I don't see a solution to the shadow map
> commit charge unless the kernel is modified.  So I cannot
> recommend even a careful reimplementation in libc for
> production use for reliable systems.

> ASan is also far from providing full memory safety and to a large extent
> it defeats Address Space Layout Randomization. It was strange to see a
> hardening effort enabling both PIE and ASan. Even without taking the
> runtime issues into consideration, it can make exploitation easier. It
> doesn't work with PaX ASLR for a reason. It's also incompatible with PaX
> UDEREF on x86_64 but that's a separate kind of issue since it could be
> altered to reserve the mappings in a way that's compatible.
> ASan's bounds checking is great at detecting the common cases of
> overflow for debugging, but it's far from exhaustive. An attacker would
> be able to bypass it in the general case. It would make it too hard to
> exploit some vulnerabilities, but it won't prevent exploitation in
> general.
> The use-after-free and double-free detection is based on the same
> quarantine technique in Valgrind. It can only detect the issues before
> allocations are flushed out of the quarantine by memory pressure. It
> does mitigate many vulnerabilities but comparable double-free detection
> could be done in malloc without the drawbacks (two flat arrays providing
> a ring buffer for a FIFO quarantine + a hash table). The same thing
> applies to write-after-free but not use-after-free, since that would
> require instrumentation in the code. A write-after-free can be detected
> by filling allocations with junk and then checking for it when it's
> flushed from the quarantine rather than instrumentation. It doesn't need
> to do the whole allocation to be useful, so there's a large range of
> tuning for performance. The junk data could come from a stream cipher
> seeded from the address if desired, but it doesn't seem important.
> It makes a lot of sense to use UBSan in the trapping mode for hardening,
> as it has no runtime and is simply adding extra checks branching to an
> instruction aborting the process. That includes the bounds and object-
> size sanitizers for bounds checking where object sizes are statically
> known. They could even be extended to cover cases where the compiler can
> figure out runtime size bounds at compile-time (for example, usage of
> memory directly after allocation with malloc(n)).
> Using ASan doesn't seem advisable. There would need to be an investment
> in remaking it with hardening in mind. It might not make sense to use
> the same design at all. For example, Intel MPX is much more oriented
> towards usage in production, including for hardening.

Sadly MPX is too slow, too memory-hungry, and does not protect from
use-after-free at all.

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ