[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