From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: Fuzzing elfutils
Date: Wed, 31 Dec 2014 12:03:51 +0100 [thread overview]
Message-ID: <20141231110351.GA2897@blokker.redhat.com> (raw)
In-Reply-To: 54A0C79D.4010506@mccme.ru
[-- Attachment #1: Type: text/plain, Size: 6121 bytes --]
Hi Alexander,
On Mon, Dec 29, 2014 at 06:16:45AM +0300, Alexander Cherepanov wrote:
> We start with a bunch of samples.
>
> The first step is to pick distinct bugs. You do it when you fix issues.
> Let's assume for now that one commit == one bug. Then for every bug...
>
> It's nice to document who found the bug. This is useful for credit (and
> hence for CVE assignment).
>
> Even better to document in which bunch of samples (bugzilla attachment or
> something) the bug was found. This useful as a date of disclosure (and hence
> for CVE assignment).
>
> Even better to document which specific sample triggered the bug. This makes
> it possible to check if the fix is applied correctly. (Perhaps I can do it
> for my samples automatically by retesting them against various commits.)
So for issues found before elfutils 0.161 I think this is all a bit
mixed up. We started out with a bunch of samples from Hano and you
and then when I realized those samples showed both specific bugs and
design issues that made those bugs worse I started fuzzing myself a
bit to find more "patterns". And not all those "samples" were kept.
For elfutils 0.161 there are about 80 patches that fix various issues
found by the fuzzing examples. Some were more "fundemental" than others.
The patches to fix the ELF header and data buffer reading/sanity checking
in libelf, the leb128 parsing issues in libdw and the relocation fixes
in libdwfl solve whole classes of bugs for example. Without those fixes
the other bugs are far worse (because they make reading/writing memory
outside the ELF image far easier).
And I am afraid there are still some fundamental issues left
see https://bugzilla.redhat.com/show_bug.cgi?id=1170810#c7 that really
need to be fixed before we can claim any random sample thrown at
elfutils shouldn't crash, hang or produce bogus results.
The good news is that things seem to have improved a lot and it now
takes hours/days to find new issues instead of minutes. But till we
release 0.162 with at least those 3 fundamental issues fixed I think
keeping strict track of one sample, one bug, one fix is not realistic.
> Then we need to separate security bugs from non-security ones. To do it
> precisely is difficult but it can be done roughly, e.g. overwriting a buffer
> with attacker controlled data is probably a security issue while null
> pointer dereference is probably not (for the usual use-case of elfutils as I
> understand it; if elfutils is used as a library in a bigger program the
> situation becomes more complex).
> Some analysis can be performed automatically based on valgrind/gdb output
> but I'm not sure how good it can be and I haven't yet implemented it. So,
> for now, I'd like to say that it's up to a person who fixes the issue;-)
Since I am the person fixing most issues I am afraid I don't keep track
of whether something is a "security issue" or not. Making elfutils crash,
hang or produce bogus/unreliable results are all pretty bad and just
need to be fixed. Whether they are "exploitable" or not. In my experience
any such issue can be made into a security issue with enough ingenuity.
> Later some folks will want to backport the security fixes to the release of
> elfutils which they have in their distro. For this, they will need to know
> if their version is affected. Your policy in this regard may vary from
> backporting fixes yourself to saying that they just have to migrate to the
> new version. Probably it's enough to check one reasonably old version (I can
> do it for my samples against version 0.152). If you can readily say that,
> e.g., all versions are affected, even better.
> I guess Red Hat / Fedora will also want to backport the fixes? Perhaps they
> have some guidelines for you to follow?
I'll ask. For Fedora I just update the package to the latest upstream
release as soon as possible to fix any bugs found between releases.
> Somewhere in the process CVEs can be requested. It seems, now, MITRE assigns
> one CVE to a group of similar issues found by one person, disclosed in one
> day and affecting the same versions. Hence all these pieces of data are
> essential for a CVE request.
>
> The priorities IMHO should be as follows.
>
> 1. Pick which commits/fixes are for security issues.
>
> 2. Everything else (without any order):
>
> a) match fixes with samples (at least roughly: this patchset fixes issues
> from this bunch of samples; but without mixing issues from different
> researchers);
>
> b) determining affected versions for each issue.
>
> It seems I need at least to do some rechecking before requesting CVEs. WDYT,
> is it feasible/reasonable to work this out e.g. for issues from the last
> month?
To be honest, I don't think that is feasible. Just finding, analysing and
fixing the issues found is a lot of work. I try to keep track of what/who
originally triggered some fix. But certainly for fixes before the 0.161
release I don't think splitting them out and catogorizing them separately
is very useful. You will need them all anyway. I think it is reasonable
to just say that we are working towards making it safe to process arbitrary
random ELF files and DWARF debuginfo data with elfutils by 0.162 (to be
released on March). But that in general people should only use elfutils
tools and libraries on files produced by a trusted toolchain for now.
I do realize parsing ELF and DWARF files with elfutils tools will show
up in surprising places and that people cannot always make sure they
files processed are generated by a trusted toolchain and aren't malicious.
Which is why I take your reports very seriously. I am certainly not against
filing CVE requests and trying to figure out exactly what security issue
is fixed by which patch. But realisticly there are just too many issues
at the moment.
Practically I won't be able to help much the next couple of weeks because
I don't have stable access to the internet on vacation. But I'll try and
monitor any new issues found.
Thanks,
Mark
next reply other threads:[~2014-12-31 11:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 11:03 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-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-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=20141231110351.GA2897@blokker.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).