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: Fuzzing elfutils
Date: Thu, 04 Dec 2014 15:27:34 +0100	[thread overview]
Message-ID: <20141204142734.GA19050@bordewijk.redhat.com> (raw)
In-Reply-To: 547F294D.5010807@mccme.ru

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

Hi Alexander,

On Wed, Dec 03, 2014 at 06:16:29PM +0300, Alexander Cherepanov wrote:
> [Please Cc me, I'm not subscribed.]

BTW. Your message didn't hit my INBOX for some reason.
Even though it does appear in the archives:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-December/004346.html
Maybe because of the attachements. Sorry for the late/garbled reply.

> I've been fuzzing binutils for some time now and I've spotted that you 
> are also intersted in it. So I have tried to fuzz elfutils. Results 
> attached. valgrind logs or gdb backtraces are included. Cases are 
> deduplicated based on the full stacktrackes as provided by the 
> corresponding tools.

Thanks! We have been fixing various issues the last couple of weeks
and I just pushed some my fixes to git master. So if you could retry
against the very latest git checkout that would be very helpful.
I'll run your crashers locally against my tree and will report which
issues still exist.

BTW. It is helpful to know which architecture you are running on. Some
issues only show on a 32bit architecture trying to parse a 64bit ELF file,
or on little/big endian systems parsing a different endian ELF file.

> I'm not very familiar with elfutils. Which commands give the most code 
> coverage (and shortest run time)? I've used two commands so far:
> 
>    objdump -rs
>    readelf -aAdehIlnrsSVcp -w
> 
> and crashes seem to differ for them.

That does give a biggest coverage. For eu-readelf -w you might want to use
-N, --numeric-addresses Do not find symbol names for addresses in DWARF data
which can increase the runtime a lot (we really need to not do a linear
search to lookup the addresses...).

But I found that using such broad coverage makes the search space for the
fuzzer really, really big. It can take days for the fuzzer to generate a
somewhat valid data for some of the section types. It is imho better to
not use -a or -w, or a combination of flags for different headers or data
sections, but to create a minimal valid ELF file with just one kind of
section or segment and then let the fuzzer run on that with just one
specific flag (or --debug-dump=xxx).

> BTW does indended use of elfutils include the use against untrusted 
> files and do you track corresponding security issues?

I guess it isn't specifically intended for use against completely untrusted
files. But it happens of course. Also some of the elfutils libraries (libelf,
libdw) are used by tools that might process untrusted data. For example
systemd might use libdw to extract backtraces from core files - which should
normally be "trusted" because generated by the kernel, but there might be
bugs in the generation or they might refer to ELF or debug files that a
hostile user might have prepared. So we are actively working to make it
work robustly against anything thrown at it.

We don't specificly track any security issues, we just treat them as bugs
to be fixed and do a new release when enough/important bugs have been fixed.
There have been people who have filed CVEs against elfutil bugs though.
I don't have any experience with filing CVEs though.

> Any feedback is welcome.
>
> Contents:
> 
> objdump-crashes.tar.gz:
> Files: 11
> Errors:
>       10 Invalid read of size ...
>        7 Process terminating with default action of signal 11 (SIGSEGV)
>        3 Process terminating with default action of signal 8 (SIGFPE)
> 
> readelf-crashes.tar.gz:
> Files: 11
> Errors:
>        1 Argument 'size' of function malloc has a fishy (possibly 
> negative) value: ...
>        1 Invalid free() / delete / delete[] / realloc()
>        9 Invalid read of size ...
>        6 Process terminating with default action of signal 11 (SIGSEGV)
>        1 Process terminating with default action of signal 8 (SIGFPE)
> 
> readelf-asserts.tar.gz:
> Files: 2
> Errors:
>        1 No assertion info in gdb backtrace.
>        1 readelf.c:7731: print_debug_exception_table: Assertion `readp 
> == action_table' failed.

I might be good to have a central place to store these results.
The mailinglist seems a little problematic and we might miss/overlook
some issues just posted to the list. Do you have some location where you
can store them and any future files? Or could you open a bugzilla report
against elfutils and attach them there?
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora

Thanks,

Mark

             reply	other threads:[~2014-12-04 14:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-04 14:27 Mark Wielaard [this message]
     [not found] <199C1200-40AC-4AD2-89D4-24E172CBA353@catenacyber.fr>
2022-10-21 12:58 ` Philippe Antoine
2022-10-21 13:22   ` Frank Ch. Eigler
2022-10-21 19:57     ` Evgeny Vereshchagin
2022-10-22  9:27       ` Philippe Antoine
2022-10-22 10:21         ` Evgeny Vereshchagin
2022-10-21 13:33   ` Evgeny Vereshchagin
  -- strict thread matches above, loose matches on Subject: below --
2014-12-31 11:03 Mark Wielaard
2014-12-29  3:16 Alexander Cherepanov
2014-12-23 11:42 Mark Wielaard
2014-12-21 22:20 Alexander Cherepanov
2014-12-19  0:13 Mark Wielaard
2014-12-18 18:15 Alexander Cherepanov
2014-12-12 12:08 Mark Wielaard
2014-12-08  9:14 Mark Wielaard
2014-12-08  8:52 Mark Wielaard
2014-12-08  3:06 Alexander Cherepanov
2014-12-08  1:01 Alexander Cherepanov
2014-12-05  8:58 Mark Wielaard
2014-12-04 23:10 Alexander Cherepanov
2014-12-04 16:03 Mark Wielaard
2014-12-03 15:16 Alexander Cherepanov

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=20141204142734.GA19050@bordewijk.redhat.com \
    --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).