[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150328223833.GD6817@brightrain.aerifal.cx>
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.
