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: Fri, 05 Dec 2014 09:58:20 +0100	[thread overview]
Message-ID: <1417769900.18974.25.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: 5480E9DD.5000706@mccme.ru

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

On Fri, 2014-12-05 at 02:10 +0300, Alexander Cherepanov wrote:
> On 2014-12-04 17:27, Mark Wielaard wrote:
> > 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).
> 
> I think this is specific to AFL which you seem to use. For it, I agree 
> with your approach. But I'm not sure how useful such an advanced fuzzer 
> at this stage. I'm still using zzuf. Right now it gives more crashes 
> than I can pipe through valgrind. You can get similar behavior with AFL 
> if you specify -dn options (or perhaps you can use just -d).

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). 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 :)

> > 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.
> 
> I see. For now, I've added 'Security' keyword to the bug in the 
> bugzilla. This should get attention of the security team. Otherwise I 
> can ask for CVEs later in oss-security mailing list.

Thanks, some guidance on how to deal with these issues would be
appreciated. Sadly at the moment there are just too many to special case
them. So for now just report issues and we try to fix them asap.

The short term plan is to do a new release (elfutils 0.161) after the
next weekend. Get as many bugs fixed before Friday 12th, do some
additional testing during the weekend and have a release the 15th. This
is not a very special release, just our periodic ~3/4 month release
cycle. It will have a lot of robustness fixes though. But I doubt we
will have fixed all crashers found by then. We will try though.

> [skip]
> > 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.
> 
> Sure, and mailing several megs of attachments to all the list is not 
> nice too. It's just there is no info about bug reporting on the project 
> page at https://fedorahosted.org/elfutils/ .

Oops. Fixed!

> > 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
> 
> I think the bugzilla is exactly fine for this. Filed here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1170810

Thanks!

Mark

             reply	other threads:[~2014-12-05  8:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05  8:58 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-04 23:10 Alexander Cherepanov
2014-12-04 16:03 Mark Wielaard
2014-12-04 14:27 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=1417769900.18974.25.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).