5 ms·

I'll take advantage of this thread to ask a related question : do you consider address sanitizers (ASAN) should be applied to harden binaries (on release builds

I'll take advantage of this thread to ask a related question : do you consider address sanitizers (ASAN) should be applied to harden binaries (on release builds) ? It indeed has a cost but can detect and crash on use after free or out of bounds access. Would you think the price can be worth it in certain cases ?

hannob 8y ago
I asked that question myself before[1], and others, too [2]. But the answer is a clear no. Read this explanation [3] on oss-security where someone lays out in detail in which ways ASAN creates security problems. It ultimately is just not built as a protection mechansim, but as a debugging tool. While you'd catch some bugs (UAFs, Buffer overreads), you introduce others. Maybe there could be a "like asan but designed for production" tool. I think Softbound-CETS was trying to go in that direction, but never became production ready and is as far as I know no longer developed. But right now such a tool does not exist. Though however what absolutely should be done: Every C/C++-written tool should be tested with ASAN. This doesn't happen (not a single Linux distro uses ASAN testing as a default practice before adding packages), and this is very sad. (I know this because I still find major packages that have ASAN-findable bugs exposed by their own test suite.) [1] https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn... [2] https://scarybeastsecurity.blogspot.com/2014/09/using-asan-as-protection.html https://scarybeastsecurity.blogspot.com/2014/09/using-asan-a... [3] https://www.openwall.com/lists/oss-security/2016/02/17/9 https://www.openwall.com/lists/oss-security/2016/02/17/9
- pjmlp 8y ago
  Although having a Linux kernel is an implementation detail on Android, and they might as well replace it by something else tomorrow, it is probably the only use case where the Linux kernel gets deployed in the wild with most security knobs turned on. SELinux, seccomp, CFI, libc with FORTIFY, forced initialization of kernel data structures, ASAN as required testing, ... https://source.android.com/devices/tech/debug/fuzz-sanitize https://source.android.com/devices/tech/debug/fuzz-sanitize https://source.android.com/security https://source.android.com/security And it might very well be the only OS stack following up Solaris and iOS footsteps, regarding using hardware memory tagging to tame C.
  - makapuf 8y ago
    That could be read as : even the most secure Linux environment currently and what could be seen as security best practice ( which your post helpfully enumerates ) requires asan for testing only.
    - pjmlp 8y ago
      Yep, which is kind of ironic given the security jokes against other platforms, which I am also to blame on my zealotry days. At least it reached the point that now more kernel devs are willing to accept the old grsecurity improvements.

hannob 8y ago

I asked that question myself before[1], and others, too [2]. But the answer is a clear no. Read this explanation [3] on oss-security where someone lays out in detail in which ways ASAN creates security problems. It ultimately is just not built as a protection mechansim, but as a debugging tool. While you'd catch some bugs (UAFs, Buffer overreads), you introduce others. Maybe there could be a "like asan but designed for production" tool. I think Softbound-CETS was trying to go in that direction, but never became production ready and is as far as I know no longer developed. But right now such a tool does not exist. Though however what absolutely should be done: Every C/C++-written tool should be tested with ASAN. This doesn't happen (not a single Linux distro uses ASAN testing as a default practice before adding packages), and this is very sad. (I know this because I still find major packages that have ASAN-findable bugs exposed by their own test suite.) [1] https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn... [2] https://scarybeastsecurity.blogspot.com/2014/09/using-asan-as-protection.html https://scarybeastsecurity.blogspot.com/2014/09/using-asan-a... [3] https://www.openwall.com/lists/oss-security/2016/02/17/9 https://www.openwall.com/lists/oss-security/2016/02/17/9

pjmlp 8y ago
Although having a Linux kernel is an implementation detail on Android, and they might as well replace it by something else tomorrow, it is probably the only use case where the Linux kernel gets deployed in the wild with most security knobs turned on. SELinux, seccomp, CFI, libc with FORTIFY, forced initialization of kernel data structures, ASAN as required testing, ... https://source.android.com/devices/tech/debug/fuzz-sanitize https://source.android.com/devices/tech/debug/fuzz-sanitize https://source.android.com/security https://source.android.com/security And it might very well be the only OS stack following up Solaris and iOS footsteps, regarding using hardware memory tagging to tame C.
- makapuf 8y ago
  That could be read as : even the most secure Linux environment currently and what could be seen as security best practice ( which your post helpfully enumerates ) requires asan for testing only.
  - pjmlp 8y ago
    Yep, which is kind of ironic given the security jokes against other platforms, which I am also to blame on my zealotry days. At least it reached the point that now more kernel devs are willing to accept the old grsecurity improvements.