On 2014-12-08 11:52, Mark Wielaard wrote:
> On Mon, 2014-12-08 at 06:06 +0300, Alexander Cherepanov wrote:
>> On 2014-12-05 11:58, Mark Wielaard wrote:
>
>>> Yes, that is true. I have been using afl. And it is good to throw some
>>> other fuzzers at it. The reason you are so successful is because till
>>> now we concentrated on readelf and libelf. Clearly the other tools need
>>> fuzzing too. And we do know debuginfo (-w), libdw, has some known
>>> issues. One of which I just fixed in response to your testcases (see the
>>> patch posted, I haven't pushed it yet, to see if there are any
>>> comments).
>>
>> Ok, I've switched to mjw/pending branch. I hope it's the right branch to
>> have all your latest fixes?
>
> Yes. All patches on there have also been posted to the mailinglist for
> discussion before applying to master. Note that the branch often gets
> rebased once patches are merged (or rewritten) in master. So don't be
> surprised if you get conflicts just git pulling. Best to delete your
> local branch and fetch a new one periodically.

I see, thanks for the info.

>>> I hope to get to the other main libdw debug issue (leb128
>>> parsing) soon. After that hopefully you will have a bit more of a
>>> challenge :)
>>
>> Well, I've uploaded some more crashes for the current (i.e. mjw/pending)
>> readelf. Some of them could be duplicates of the previous unfixed ones.
>
> Thanks. I'll try to reproduce them soon. But without a general leb128
> length check fix using eu-readelf -w might be somewhat unreliable (and
> this also might impact -e/--exceptions).

There are many patches flowing and it's not clear which are relevant for 
my crashes and when it's the right time to start fuzzing again.

Well, I current master against samples which I submitted earlier and it 
seems everything is fixed except for a couple of invalid reads when 
processing 6f100f93:

==5634== Invalid read of size 1
==5634==    at 0x4E43A08: __libdw_get_uleb128 (memory-access.h:65)
==5634==    by 0x4E43A08: dwarf_getabbrevattr (dwarf_getabbrevattr.c:63)
==5634==    by 0x4097CE: print_debug_abbrev_section (readelf.c:4573)
==5634==    by 0x410EF3: print_debug (readelf.c:8247)
==5634==    by 0x410EF3: process_elf_file (readelf.c:897)
==5634==    by 0x410EF3: process_dwflmod (readelf.c:691)
==5634==    by 0x4E55A70: dwfl_getmodules (dwfl_getmodules.c:82)
==5634==    by 0x407C11: process_file (readelf.c:790)
==5634==    by 0x403C33: main (readelf.c:296)
==5634==  Address 0x5e93e5e is 0 bytes after a block of size 318 alloc'd
==5634==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==5634==    by 0x5084A48: convert_data (elf_getdata.c:140)
==5634==    by 0x5084A48: __elf_getdata_rdlock (elf_getdata.c:442)
==5634==    by 0x4E3F7C5: check_section (dwarf_begin_elf.c:130)
==5634==    by 0x4E3FA8A: global_read (dwarf_begin_elf.c:270)
==5634==    by 0x4E3FA8A: dwarf_begin_elf (dwarf_begin_elf.c:378)
==5634==    by 0x4E56B92: load_dw (dwfl_module_getdwarf.c:1213)
==5634==    by 0x4E56D40: find_dw (dwfl_module_getdwarf.c:1240)
==5634==    by 0x4E56D40: dwfl_module_getdwarf (dwfl_module_getdwarf.c:1295)
==5634==    by 0x410DA1: print_debug (readelf.c:8167)
==5634==    by 0x410DA1: process_elf_file (readelf.c:897)
==5634==    by 0x410DA1: process_dwflmod (readelf.c:691)
==5634==    by 0x4E55A70: dwfl_getmodules (dwfl_getmodules.c:82)
==5634==    by 0x407C11: process_file (readelf.c:790)
==5634==    by 0x403C33: main (readelf.c:296)

(that's the first one and the second one differs only in the very first 
address).

Further fuzzing found 3 crashes in readelf. Not sure if you want to look 
into them now.

-- 
Alexander Cherepanov