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?