From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============9036522925432565440=="
MIME-Version: 1.0
From: Alexander Cherepanov <cherepan@mccme.ru>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: Fuzzing elfutils
Date: Thu, 18 Dec 2014 21:15:28 +0300
Message-ID: <549319C0.4080301@mccme.ru>
In-Reply-To: 1418028765.18974.27.camel@bordewijk.wildebeest.org

--===============9036522925432565440==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

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:

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

--===============9036522925432565440==--