#467 Fuzzing elftoolchain -- various problems

[Alexander Cherepanov]

I've fuzzed some of the tools provided by elftoolchain project (rev 3136). Here are the results. valgrind logs or gdb backtraces are included. Cases are deduplicated based on the full stacktrackes as provided by the corresponding tools. Cases are not deduplicated between tools so there are some duplicate crashes in libraries.

I'd appreciate if you mark every commit fixing some of the these problems in a way similar to a Reported-by: field used in git. This is useful for tracking and for attribution.

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

Any feedback is welcome.

[Alexander Cherepanov]

Problems with ar -tv

Files: 2
Errors:
2 Invalid read of size ...
2 Process terminating with default action of signal 11 (SIGSEGV)

[Alexander Cherepanov]

Problems with "brandelf"

Files: 1
Errors:
1 libelf_ar_util.c:282: _libelf_ar_open: Assertion `sz > 0' failed.

[Alexander Cherepanov]

Problems with "elfdump -a"

valgrind

Files: 48
Errors:
9 Argument 'size' of function malloc has a fishy (possibly negative) value: ...
44 Invalid read of size ...
28 Process terminating with default action of signal 11 (SIGSEGV)
9 Process terminating with default action of signal 8 (SIGFPE)

---

gdb

Files: 1
Errors:
1 libelf_ar_util.c:282: _libelf_ar_open: Assertion `sz > 0' failed.

[Alexander Cherepanov]

Problems with "findtextrel"

:::text
Files: 7
Errors:
      8 Invalid read of size ...
      2 Process terminating with default action of signal 11 (SIGSEGV)
      2 Process terminating with default action of signal 8 (SIGFPE)

----------------------------------------------------------------------

gdb

Files: 2
Errors:
      1 libdwarf_attr.c:187: _dwarf_attr_init: Assertion `str != ((void *)0)' failed.
      1 libelf_ar_util.c:282: _libelf_ar_open: Assertion `sz > 0' failed.

2015-01-04: fixed formatting.

[Alexander Cherepanov]

Problems with "readelf -acdeghlnrstADNSVW"

valgrind

Files: 66
Errors:
3 Argument 'size' of function malloc has a fishy (possibly negative) value: ...
41 Conditional jump or move depends on uninitialised value(s)
85 Invalid read of size ...
34 Process terminating with default action of signal 11 (SIGSEGV)
9 Process terminating with default action of signal 8 (SIGFPE)
6 Use of uninitialised value of size ...

---

gdb

Files: 1
Errors:
1 libelf_ar_util.c:282: _libelf_ar_open: Assertion `sz > 0' failed.

[Alexander Cherepanov]

Problems with "size"

Files: 14
Errors:
15 Invalid read of size ...
12 Process terminating with default action of signal 11 (SIGSEGV)

---

gdb

Files: 1
Errors:
1 libelf_ar_util.c:282: _libelf_ar_open: Assertion `sz > 0' failed.

[Alexander Cherepanov]

Problems with "strings"

valgrind

Files: 12
Errors:
12 Invalid read of size ...
12 Process terminating with default action of signal 11 (SIGSEGV)

---

gdb

Files: 1
Errors:
1 libelf_ar_util.c:282: _libelf_ar_open: Assertion `sz > 0' failed.

[Alexander Cherepanov]

Problems with "nm -aCflps"

:::text
valgrind

Files: 42
Errors:
      1 Invalid free() / delete / delete[] / realloc()
     99 Invalid read of size ...
     12 Invalid write of size ...
     13 Process terminating with default action of signal 11 (SIGSEGV)
      1 Use of uninitialised value of size ...

----------------------------------------------------------------------

gdb

Files: 17
Errors:
      4 No assertion info in gdb backtrace.
      4 libdwarf_attr.c:187: _dwarf_attr_init: Assertion `str != ((void *)0)' failed.
      1 libdwarf_init.c:42: _dwarf_consumer_init: Assertion `dbg->dbg_iface != ((void *)0)' failed.
      1 libelf_ar_util.c:282: _libelf_ar_open: Assertion `sz > 0' failed.
      3 libelftc_dem_gnu2.c:1129: read_qual_name: Assertion `*d->p > 48 && *d->p < 58 && "*d->p not in ASCII numeric range"' failed.
      1 libelftc_dem_gnu2.c:1195: read_subst_iter: Assertion `*d->p > 48 && *d->p < 58 && "*d->p not in ASCII numeric range"' failed.
      1 libelftc_dem_gnu2.c:443: read_array: Assertion `len > 0' failed.
      1 libelftc_dem_gnu2.c:500: read_func: Assertion `len != 0' failed.
      1 libelftc_dem_gnu3.c:1702: cpp_demangle_read_subst: Assertion `nth > 0' failed.

2015-01-04: fixed formatting.

[Ed Maste]

I've fuzzed some of the tools provided by elftoolchain project (rev 3136).

Thank you.

I'm looking at the issues in strings first, since I suspect it is the most likely to be used on untrusted input. The crashes (problems/valgrind/*) are all through _libelf_load_section_headers(). They are the same issue as ticket 462, which I found with afl a little while ago.

There is a fix here:
https://svnweb.freebsd.org/base?view=revision&revision=276374

And available in my github fork of elftoolchain:
https://github.com/emaste/elftoolchain/tree/freebsd

The assertion failure (gdb/) comes from:

        /*
         * Handle special archive members for the SVR4 format.
         */
        if (arh.ar_name[0] == '/') {

                assert(sz > 0);

It looks like this should just be an error return for sz == 0 rather than an assertion. I'll put a potential fix in my branch.

I'd appreciate if you mark every commit fixing some of the these problems in a way similar to a Reported-by: field used in git. This is useful for tracking and for attribution.

That sounds reasonable to me. I'd like to mention the tools used too, if appropriate; are these all afl?

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

I think the short answer is "the tools are not expected to be used with untrusted input," but of course the reality is more nuanced. When facing a questionable file (e.g., something downloaded from an arbitrary web site) I suspect many users will run file(1) and strings(1) on it.

A binutils ELF parsing issue received CVE-2014-8485, and my opinion is that similar issues in elftoolchain ought to be treated the same way.

[Alexander Cherepanov]

I'm looking at the issues in strings first, since I suspect it is the most likely to be used on untrusted input. The crashes (problems/valgrind/*) are all through _libelf_load_section_headers(). They are the same issue as ticket 462, which I found with afl a little while ago.

Good. I've seen your ticket but figured that it's better to upload my crashes anyway, in case there are several distinct crashes there.

There is a fix here:
https://svnweb.freebsd.org/base?view=revision&revision=276374

And available in my github fork of elftoolchain:
https://github.com/emaste/elftoolchain/tree/freebsd

Nice.

The assertion failure (gdb/) comes from:
[skip]
It looks like this should just be an error return for sz == 0 rather than an assertion. I'll put a potential fix in my branch.

Ok, please let me know when 'strings' (or other programs) are ready for the next round of fuzzing.

I'd appreciate if you mark every commit fixing some of the these problems in a way similar to a Reported-by: field used in git. This is useful for tracking and for attribution.

That sounds reasonable to me.

Great, please credit me as "Alexander Cherepanov cherepan@mccme.ru".

I'd like to mention the tools used too, if appropriate; are these all afl?

No, it's not afl. Fuzzing for this but report was done in the following way: original samples come from various test suites, the set of all samples is minimized for every program separately with afl (minimize_corpus.sh), crashes are found with zzuf, analyzed with catchsegv/valgrind/gdb, deduplicated and prepared for submission with custom scripts.

For each sample, uploaded tarballs include a text file (in info/) documenting where the original file came from and how the sample is generated from it (then you can, e.g., dig out a license for the original and include the sample in some testsuite).

BTW I forgot to mention that everything was done on 64-bit GNU/Linux (Debian jessie amd64).

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

I think the short answer is "the tools are not expected to be used with untrusted input," but of course the reality is more nuanced.

I mean it doesn't look like elftoolchain is used in any distro. This could affect the answer. But I've now learned that at least ar(1) in recent FreeBSDs seems to come from elftoolchain.

When facing a questionable file (e.g., something downloaded from an arbitrary web site) I suspect many users will run file(1) and strings(1) on it.

Yeah, file(1) is definitely something to look into (the latest release fixes a couple of issues I reported and includes a couple of my patches -- http://mx.gw.com/pipermail/file/2015/001660.html ).

Another tool widely used against non-trusted files is less(1). If lesspipe is somewhat popular in the BSD world you have a problem -- see e.g. this thread: http://www.openwall.com/lists/oss-security/2014/11/23/2 .

Coming back to elftoolchain: ar(1) is usually one of the exposed utils in various variants of lesspipe. Combined with the fact that it is already installed in FreeBSD you may consider prioritizing it somewhat higher than strings(1). But it's surely completely up to you.

A binutils ELF parsing issue received CVE-2014-8485, and my opinion is that similar issues in elftoolchain ought to be treated the same way.

Great.

You may also want to classify fixes into security (e.g. where overwriting a buffer with data from a sample is possible) and non-security (e.g. for null pointer deref). I could be useful for requesting CVEs (but I'm not really sure how useful) and for minimizing the amount of backporting (but I'm not sure how relevant it is for elftoolchain). It's possible to do initial classification before submission but it's not yet ready. Sorry for this.

Another thing to track which is potentially useful is the specific batch of samples (e.g. specific comment in the bug report) the fix is for. It's useful to get the disclosure date.

[Ed Maste]

Proposed fix for some of these in https://reviews.freebsd.org/D2338

[Ed Maste]

Checking now, the 'strings' issues are handled.

[Ed Maste]

As of [r3258] I believe the reported readelf issues are fixed

[Ed Maste]

All issues in ar, brandelf and size should be fixed as of [r3458].

Outstanding issues in the other tools:
* elfdump: 24 of 49
* findtextrel: 3 of 8
* nm: 37 of 52
* readelf: 2 of 67

I will continue addressing these failures against this ticket. For any additional fuzzing, would you please submit one ticket per tool to make it easier to keep track of the issues?

[Ed Maste]

The one outstanding findtextrel issue is now tracked in ticket #529.

I have some elfdump WIP that will be committed soon, at which point all outstanding issues except for those in nm will be addressed. nm still has has 34 outstanding issues (and 18 addresssed).