From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============3179676680797843316=="
MIME-Version: 1.0
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: out-of-bounds read / crash in elfutils tools (readelf, nm,
 ...) with malformed file
Date: Thu, 06 Nov 2014 16:11:43 +0100
Message-ID: <1415286703.19702.20.camel@bordewijk.wildebeest.org>
In-Reply-To: 20141031171341.239ece98@pc

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

On Fri, 2014-10-31 at 17:13 +0100, Hanno B=C3=B6ck wrote:
> Attached is a file that's a fuzzed elf executable which will crash
> various tools shipped with elfutils, I tried it with nm and readelf -a,
> maybe others affected.

The issue is when we call elf_strptr on the .strtab section giving the
st_name offset for the 29th symbol which is way too large. But the
section header for .strtab is corrupted and gives a way too large size.
So the sanity check for whether the index falls in the section data size
doesn't trigger. So elf_strptr returns a pointer to an address we
haven't mapped in.

The issue disappears when we open the elf file with ELF_C_READ instead
of with ELF_C_READ_MMAP. Then we do detect the  size in the section
header is bogus and so we won't try to use the section data.

I haven't figured out yet why we do use the data in the mmap case. It
looks like we should catch that issue in elf_getdata:

      /* We can use the mapped or loaded data if available.  */
      if (elf->map_address !=3D NULL)
        {
          /* First see whether the information in the section header is
             valid and it does not ask for too much.  */
          if (unlikely (offset + size > elf->maximum_size))
            {
              /* Something is wrong.  */
              __libelf_seterrno (ELF_E_INVALID_SECTION_HEADER);
              return 1;
            }

elf->maximum_size is setup correctly based on the actual file size. But
it seems we don't actually hit this code path in this case. The rawdata
is setup some other way than by calling __libelf_set_rawdata_wrlock. But
I haven't figured out how yet.

> (actually this bug report is kind of a fallout of a bug search in
> libbfd - various parser bugs in the binutils-tools have been found and
> fixed in the past days and I thought I'd run other elf-related tools on
> the collection of bug-exposing binaries)

Thanks. If you have any other examples please do report them.

Cheers,

Mark


--===============3179676680797843316==--