public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Alexander Cherepanov <cherepan@mccme.ru>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: Fuzzing elfutils
Date: Mon, 08 Dec 2014 06:06:13 +0300	[thread overview]
Message-ID: <548515A5.7080304@mccme.ru> (raw)
In-Reply-To: 1417769900.18974.25.camel@bordewijk.wildebeest.org

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

On 2014-12-05 11:58, Mark Wielaard wrote:
> 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).

Ok, I've switched to mjw/pending branch. I hope it's the right branch to 
have all your latest fixes?

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

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

I'll reply to this a bit later.

-- 
Alexander Cherepanov

             reply	other threads:[~2014-12-08  3:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08  3:06 Alexander Cherepanov [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  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-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=548515A5.7080304@mccme.ru \
    --to=cherepan@mccme.ru \
    --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).