Date: Wed, 17 Feb 2016 19:08:45 -0500 From: Daniel Micay <danielmicay@...il.com> To: oss-security@...ts.openwall.com Subject: Re: Address Sanitizer local root 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. [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ