Date: Sat, 28 Mar 2015 18:38:33 -0400 From: Rich Felker <dalias@...c.org> To: Konstantin Serebryany <konstantin.s.serebryany@...il.com> Cc: musl@...ts.openwall.com Subject: Re: buffer overflow in regcomp and a way to find more of those On Sat, Mar 28, 2015 at 03:32:41PM -0700, Konstantin Serebryany wrote: > > 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) > > > Correct. > > > 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 > > Yes, I have the same trouble with glibc and have to disable > instrumentation for some of the glibc functions > (by not adding -fsanitize-address), which is not optimal (may lose > bugs on other calls to these functions). We have a similar problem with stack protector now. I want to be able to enable stack protector for libc with 1.1.9 so maybe we can solve at least some of the issues asan faces at the same time. > >> > __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? > > You probably can do it because you control all mmap calls from libc > (from malloc and thread stack creation), > but the first time the user calls mmap syscall bypassing libc it will break. > We use MAP_NORESERVE to map the entire range at startup. > This has a drawback that the application uses 16Tb of virtual address > space and tools like "ulimit -v" do not work. > But otherwise this works great. MAP_NORESERVE is a NOP on systems with overcommit disabled. The right way to achieve a similar result is to use PROT_NONE to reserve the virtual address range without reserving commit, and only mprotect to PROT_READ|PROT_WRITE later as needed. > > - 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 > > sounds great. I'm not clear why there would be a different dynamic linker pathname for it. It's not a different ABI from the application's standpoint, is it? It seems like you might _want_ to install the dynamic linker with a different name or location just to avoid clobbering the non-asan build, but I don't think it needs a dedicated name/location like it would if it were an ABI/ISA. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.