On Sun, Nov 12, 2023 at 10:57:33PM +0100, Bruno Haible wrote:
> Two among the bugs uncovered by CHERI (the mcel bug [1] and the xgettext bug
> [2]) could be found
> - by CHERI, or
> - by "gcc -fsanitize=address", or
> - by "clang -fsanitize=address",
> but not by valgrind.
>
> This raises the question: Should we better use CHERI for general pre-release
> testing, or the address sanitizers?
>
> The answer is in [3], page 4, table III: CHERI does not detect use-after-free
> and stack-use-after-return bugs ("temporal memory safety").
That's not true, and that paper is pretty bad at representing reality,
bordering on being incorrect. Elsewhere they have the following which
clarifies how things were at the time of writing a bit:
e) Double-free: This is an example of a temporal mem- ory safety
vulnerability that the Cornucopia [33] extension of PureCap could
detect, but the stable version does not.
For many years heap temporal safety was in a separate branch, but our
upcoming 23.11 release (i.e. later this month, all being well) will have
heap temporal safety available (it's already in our development
snapshots) and enabled by default for all CHERI processes, and at some
point when I get the chance after that I will upgrade cfarm240 to that
release. Stack temporal safety is the one remaining hole.
> Because of this, I'll be using address sanitizers, not CHERI, for the next
> foreseeable time.
ASan may have been able to find these particular bugs, but there are
countless bugs that ASan just can't pick up. At the end of the day it
relies on various shadow bytes to try and track allocations, but you can
do things like happen to jump over its redzones and not get caught; see
https://godbolt.org/z/Env1E7nnd for an example of a blatant spatial
safety violation that ASan just doesn't catch because of this. ASan has
the advantage of being instrumentation that you can inject for your
native architecture, but CHERI can catch more things (at least for
spatial safety, I'm less aware of quite what ASan can do for temporal
safety). Our view is they're complementary approaches and it's not a
question of only doing one or the other; there's value to be had from
using both.
Of course, logging into a remote machine to run tests, and taking the
(admittedly, generally small amount of) time to port code to CHERI is
more effort than just building with -fsanitize=address, so at the end of
the day it's your call whether you deem it worth the additional hassle
and choose to take advantage of what CHERI has to offer. I just don't
think it's right to use the argument that you have to pick between CHERI
and ASan, and that since CHERI requires more work and ASan can find
stack temporal safety bugs one should forget about CHERI, because you
can use both and CHERI can also detect things ASan can't. Our view is
that, in an ideal world, people would in fact use both to test their
software (well, or we'd just implement the rest of the things ASan can
detect, but that doesn't account for other sanitizers that are
orthogonal in their goals to CHERI, like MSan or TSan).
Jess
> Find a writeup at [4].
>
> Although running a desktop where everything, from the kernel to the web
> browser,
> has CHERI-enabled pointer validation would be cool from the security point of
> view. But that's a different goal than searching for bugs in a particular
> package...
>
> Bruno
>
> [1] https://lists.gnu.org/archive/html/bug-gnulib/2023-11/msg00034.html
> [2] https://lists.gnu.org/archive/html/bug-gnulib/2023-11/msg00109.html
> [3]
> https://www.techrxiv.org/articles/preprint/Towards_a_Hybrid_Approach_to_Protect_Against_Memory_Safety_Vulnerabilities/14680185
> [4] https://gitlab.com/ghwiki/gnow-how/-/wikis/Finding_memory_bugs
>
>
>
>
