public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <1415286703.19702.20.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: 20141031171341.239ece98@pc

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

On Fri, 2014-10-31 at 17:13 +0100, Hanno Böck 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 != 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


             reply	other threads:[~2014-11-06 15:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 15:11 Mark Wielaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-11-13 21:55 
2014-11-13 21:51 Mark Wielaard
2014-11-13 19:39 
2014-11-13 14:45 Mark Wielaard
2014-11-11 16:57 Mark Wielaard
2014-11-11 13:57 
2014-11-11 13:53 Mark Wielaard
2014-11-11 13:49 Petr Machata
2014-11-11 13:40 
2014-11-11 13:30 Petr Machata
2014-11-11 13:15 Mark Wielaard
2014-11-11 10:31 
2014-11-10 20:58 Mark Wielaard
2014-11-09 21:59 
2014-11-09 16:57 Mark Wielaard
2014-11-08 16:10 
2014-11-08 15:32 Mark Wielaard
2014-11-08 14:04 Mark Wielaard
2014-11-07 16:13 
2014-11-07 15:45 Mark Wielaard
2014-11-07 15:32 
2014-11-07 11:58 Mark Wielaard
2014-11-07 11:51 Mark Wielaard
2014-11-07  0:27 
2014-11-06 18:25 Roland McGrath
2014-11-06 16:05 Mark Wielaard
2014-10-31 16:13 

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1415286703.19702.20.camel@bordewijk.wildebeest.org \
    --to=mjw@redhat.com \
    --cc=elfutils-devel@lists.fedorahosted.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).