[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5456B3AA.4090102@mccme.ru>
Date: Mon, 03 Nov 2014 01:43:54 +0300
From: Alexander Cherepanov <cherepan@...me.ru>
To: oss-security@...ts.openwall.com
Subject: Re: Re: strings / libbfd crasher
On 2014-10-31 08:57, cve-assign@...re.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
