[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 17 Nov 2014 02:49:37 +0100
From: Robert Święcki <robert@...ecki.net>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Fuzzing objdump (PR 17512) and readelf (PR 17531)
>>> This looks rather impressive. Have you considered automatically
>>> detecting
>>> duplicates by e.g. analyzing stacktraces?
>>
>>
>> Feel free to take a look at honggfuzz -
>> https://code.google.com/p/honggfuzz/
>>
>> It provides a crude version of unification on the basis of offending
>> program counter (as well as simple disassembly of the offending
>> instruction).
>
>
> Is it really interesting? For objdump many crashes are in quite generic
> functions like bfd_getl16 and PC will not differentiate between them. Using
> full stacktrace is probably too much but using only PC seems to be too
> coarse.
It's actually a combination of signal/PC/fault_address/orig_file and
"code value", which is very specific to Linux/arch, but under x86 it
can quickly indicate you what kind of fault it was (execution of
non-executable page, read, write etc.). It also disassembles the
faulting instruction, so it's easy to quickly estimate severity.
>From personal experience - and for limited fuzzing (i.e. less than
dozen or so of machines) where one needs to sort through the output
manually anyway - very useful - e.g. (example output file from a
non-related to libbdf fuzzing)
SIGSEGV.PC.0x2e5458.CODE.-6.ADDR.0x2e5458.INSTR.[NOT_MMAPED].ppc32.mv.fuzz
...looks very promising (PC was set to a non-mapped page, if that
address is controlled then it's an instant *win*:), as opposed to..
SIGSEGV.PC.0xf7ea7109.CODE.1.ADDR.0x8.INSTR.mov_edx,_[rax+0x8].5858.fuzz
...which is just a nul-ptr read.
As mentioned above - for fuzzing on one or one couple of PCs it's just
fine. For cluster fuzzing, indeed a more specialized (in many aspects)
fuzzer is needed.
>> It also disables address randomization to get repeatable
>> crashes. Example output (from testing strings-multiarch):
>
>
> BTW is there a publicly available corpus of binaries from various
> architectures?
I don't think so - I'd start with rpm/deb search engines and extract
ELFs for interesting architectures, then would use a search engine to
find other remaining file formats. Also, objcopy converts between some
of those formats (esp. when compiled with multiarch support).
--
Robert Święcki
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
