[PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
Maxim Ostapenko
m.ostapenko@samsung.com
Wed Oct 5 15:46:00 GMT 2016
On 05/10/16 17:26, Florian Weimer wrote:
> On 09/05/2016 07:27 PM, Maxim Ostapenko wrote:
>> Although fortify is good thing as it (and it's enabled by default on
>> some major distros e.g. Ubuntu and Gentoo), people still complain about
>> {A, M}San vs fortify interaction, see e.g.
>> https://github.com/google/sanitizers/issues/689. One possible solution
>> would be to extend {A, M}San to support foo_chk() functions, but this
>> would increase the complexity of sanitizer tools with quite small
>> benefit.
>
> I'm not sure if there is a small benefit. Based on Mark's feedback on
> valgrind's capabilities compared to source fortification, I ran an
> experiment.
>
> Consider this example program:
>
> #include <stdlib.h>
> #include <string.h>
>
> struct foo {
> int a;
> char b[4];
> void *c;
> };
>
> int
> main (int argc, char **argv)
> {
> struct foo *p = malloc (sizeof (*p));
> strcpy (p->b, argv[1]);
> asm volatile ("" ::: "memory");
> free (p);
> }
>
> Compiled with -D_FORTIFY_SOURCE=2, passing a four-character string
> yields:
>
> $ ./a.out aaaa
> *** buffer overflow detected ***: ./a.out terminated
> [â¦]
>
> But compiling with clang 3.8 and -fsanitize=address (without source
> fortification), I can pass a longer string before Address Sanitizer
> detects the overflow:
>
> $ ./a.out aaaaaaaaaaa
> $ ./a.out aaaaaaaaaaaa
> =================================================================
> ==21921==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x60200000f000 at pc 0x000000488d77 bp 0x7ffe8eb00d50 sp 0x7ffe8eb00500
>
> Depending on the application, intra-object overflows can be quite
> relevant. Is this perhaps a sufficient case for Address Sanitizer
> using this data as well?
Well, this is a valid point, ASan doesn't poison intra objects, but I
wonder how ASan can reuse it? Perhaps poison dest + bos0(dest) at
interceptor entry and unpoison at exit?
-Maxim
>
> Thanks,
> Florian
>
>
>
More information about the Libc-alpha
mailing list