Re: Re: strings / libbfd crasher

[Alexander Cherepanov <cherepan () mccme ru>]

On 2014-10-31 08:57, cve-assign () mitre org wrote:

Thanks for assigning CVEs for these issues but I have a couple of 
questions regarding CVE-worthiness of various things. And some questions 
for the community.

> > a crasher in the PE parser, I don't know if this is the same one, but
> > I reported it upstream:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=17512
> >
> > As this is a write to uninitialized memory it seems to me a CVE is
> > deserved.
> >
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7e1e19887abd24aeb15066b141cdff5541e0ec8e
>
> Use CVE-2014-8501 for the 7e1e19887abd24aeb15066b141cdff5541e0ec8e
> issue.

AddressSanitizer said "stack-buffer-overflow" and then "WRITE of size 
8". Ok.

> > https://sourceware.org/bugzilla/show_bug.cgi?id=17512#c16
> >
> > Seems to be different from the previous crasher.
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=17512#c17
> >
> > objdump-pe-crasher2 gives a heap overflow
>
> Use CVE-2014-8502 for the objdump-pe-crasher2 issue.

Here, AddressSanitizer said "heap-buffer-overflow" and then "READ of 
size 1".

Why this crasher is judged as CVE worthy? Is it oversight or are invalid 
reads assumed to be exploitable by default?

Another possibility is to treat all crashes in all libraries as CVE 
worthy. We don't know how these libraries are used ITW and any crash in 
any of them could potentially lead to data loss in some application. But...

> [ The http://openwall.com/lists/oss-security/2014/10/27/2 post
> suggests that there isn't a known way to exploit objdump-elf-crasher
> or objdump-pe-crasher for code execution. There are currently no CVE
> IDs associated with objdump-elf-crasher or objdump-pe-crasher. ]

...it seems libbfd is not treated as a library any crash in which is CVE 
worthy.

> > https://sourceware.org/bugzilla/show_bug.cgi?id=17512#c33
> > https://sourceware.org/bugzilla/show_bug.cgi?id=17512#c34
>
> Use CVE-2014-8503 for this ihex parser issue.

Again "READ of size 1".

BTW is there a method to quickly sort out crashes (or other bad 
behavior) into potentially exploitable and presumably non-exploitable, 
i.e. separate security issues from non-security ones? For instance, to 
run it through valgrind and sort out errors as follows:

Presumably non-exploitable:
- Invalid read of size ...
- Use of uninitialised value of size ...
- Conditional jump or move depends on uninitialised value(s)
- Syscall param write(buf) points to uninitialised byte(s)
- Stack overflow in thread ...

Potentially exploitable:
- Invalid write of size ...
  (straight buffer overrun?)
- Argument 'size' of function malloc has a fishy (possibly negative) 
value: ...
  (integer overflow?)
- Jump to the invalid address stated on the next line
  (corrupted stack?)

Simple fuzzing of objdump with zzuf (not even afl) quickly gives out 
tens and hundreds of different cases of mentioned errors (mostly from 
the first group:-). Now what?

Bonus:

https://sourceware.org/bugzilla/show_bug.cgi?id=17533

$ printf '!<arch>\n//%48d%8s`\n' -2 '' > test.a
$ objdump -x test.a
Segmentation fault

At least 2.22, 2.24 and head are affected. ar, size, strip etc. are also 
affected.

valgrind on head shows:

==14181== Invalid write of size 8
==14181==    at 0x4C2E467: memset (vg_replace_strmem.c:1094)
==14181==    by 0x448AD2: bfd_zalloc (opncls.c:1011)
==14181==    by 0x43F08A: _bfd_slurp_extended_name_table (archive.c:1298)
==14181==    by 0x43E89B: bfd_generic_archive_p (archive.c:831)
==14181==    by 0x4466A6: bfd_check_format_matches (format.c:305)
==14181==    by 0x407DCD: display_any_bfd (objdump.c:3356)
==14181==    by 0x409F52: display_file (objdump.c:3410)
==14181==    by 0x4048F9: main (objdump.c:3692)
==14181==  Address 0x55fb9a0 is 0 bytes after a block of size 4,064 alloc'd
==14181==    at 0x4C27C20: malloc (vg_replace_malloc.c:296)
==14181==    by 0x4D51DC: objalloc_create (objalloc.c:95)
==14181==    by 0x448177: _bfd_new_bfd (opncls.c:73)
==14181==    by 0x448307: bfd_fopen (opncls.c:197)
==14181==    by 0x409F40: display_file (objdump.c:3403)
==14181==    by 0x4048F9: main (objdump.c:3692)

This is "Invalid write", hence potentially exploitable? Is further 
analysis required before deciding if this is a security issue? Or, more 
strictly, is further analysis required before deciding if this issue is 
CVE worthy?

--
Alexander Cherepanov