Re: buffer overflow in regcomp and a way to find more of those

[Szabolcs Nagy <nsz@port70.net>]

* Szabolcs Nagy <nsz@port70.net> [2015-03-23 13:35:40 +0100]:
> * Konstantin Serebryany <konstantin.s.serebryany@gmail.com> [2015-03-22 21:55:26 -0700]:
> > On Sat, Mar 21, 2015 at 6:28 AM, Szabolcs Nagy <nsz@port70.net> wrote:
> > > i assume for that we still need to change the libc startup code, malloc
> > > functions and may be some things around thread stacks
> > 
> > Try to compile a simple file with asan:
> > 
> > int main(int argc, char **argv) {
> >   int a[10];
> >   a[argc * 10] = 0;
> >   return 0;
> > }
> > 
> > 
> > % clang -fsanitize=address  a.c -c
> > 
> > % nm a.o | grep U
> >                  U __asan_init_v5
> >                  U __asan_option_detect_stack_use_after_return
> >                  U __asan_report_store4
> >                  U __asan_stack_malloc_1
> > 
> > __asan_report_store4 should print an error message saying that
> > "bad write of 4 bytes" happened in <current stack trace> on address <param>.
> > Also make  other __asan_report_{store,load}{1,2,4,8,16}
> > 
> > __asan_init_v5 will be called by the module initializer.
> > When called for the first time, it should mmap the shadow memory.
> > https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm
> > 

it seems asan intrumented code with memory access cannot run
before __asan_init_v5 does the shadow mapping (otherwise the
compiler generated shadow access would crash)

this is problematic for dynamic linking because the loader
calls various libc functions so those cannot be instrumented
unless shadow memory is already in place

i managed to make a minimal asan runtime work with static linking
(and then stack corruption is indeed detected).
(i called __asan_init_v5 in the begining of musl's __libc_start_main)

> > __asan_option_detect_stack_use_after_return is a global, define it to 0.
> > __asan_stack_malloc_1 -- just make it an empty function.
> > 
> > Now, you can build a code with asan and detect stack buffer overflows.
> > (The reports won't be very detailed, but they will be correct).
> > If you add poisoned redzones to malloc -- you get heap buffer overflows.
> > If you delay the reuse of free-d memory -- you get use-after-free.
> > 
> > If you then implement __asan_register_globals (it is called on module
> > initialization and poisons redzones for globals)
> > you get global buffer overflows.
> > 

i havent tried to do the heap/global poisoning

it's not clear to me what's the best way to manage the shadow
memory: mmap with PROT_NONE the entire 0x7fff8000 .. 0x10007fff8000
range and then mmap with rw the subranges that shadow mmaped memory
in the application?

then a modified mmap is needed to manage the shadow maps

so i think for a asan+cov instrumented libc:

- [S]crt1.s should do the initial shadow mmap before any c code gets run
- mmap should be replaced to do shadow management
- malloc etc should be replaced to handle shadow poisoning
- the minimal asan and cov runtimes should be added to libc
(so their symbols are available early in the loader)

and then we can use such a libc for testing and fuzzing
to catch heap/stack corruptions

i guess it is possible to have a /lib/ld-muslasan-x86_64.so.1
and Scrt1asan.o on a system and the compiler/linker could
use those when compiling some code with asan+cov instrumentation
(but this can get ugly if there will be more instrumentations
that need runtime support in the future)