oss-sec mailing list archives
Re: Address Sanitizer local root
From: Daniel Micay <danielmicay () gmail com>
Date: Wed, 17 Feb 2016 19:08:45 -0500
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.
Attachment:
signature.asc
Description: This is a digitally signed message part
Current thread:
- Address Sanitizer local root Szabolcs Nagy (Feb 17)
- Re: Address Sanitizer local root Daniel Micay (Feb 17)
- Re: Address Sanitizer local root Daniel Micay (Feb 17)
- Re: Address Sanitizer local root Konstantin Serebryany (Feb 17)
- Re: Address Sanitizer local root Daniel Micay (Feb 17)
- Re: Address Sanitizer local root Rich Felker (Feb 19)
- Re: Address Sanitizer local root Daniel Micay (Feb 19)
- Re: Address Sanitizer local root Daniel Micay (Feb 17)
- Re: Address Sanitizer local root Daniel Micay (Feb 17)
- Re: Address Sanitizer local root Hanno Böck (Feb 18)
- Re: Address Sanitizer local root Balint Reczey (Feb 18)
- Re: Address Sanitizer local root Daniel Micay (Feb 18)
- Re: Address Sanitizer local root Gynvael Coldwind (Feb 18)
- Re: Address Sanitizer local root Robert Święcki (Feb 18)