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
