This is the mail archive of the
mailing list for the binutils project.
Re: vulnerabilities in libbfd (CVE-2014-beats-me)
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: Michal Zalewski <lcamtuf at coredump dot cx>, bugtraq <bugtraq at securityfocus dot com>, binutils at sourceware dot org
- Date: Tue, 28 Oct 2014 15:43:45 +0000 (GMT)
- Subject: Re: vulnerabilities in libbfd (CVE-2014-beats-me)
- Authentication-results: sourceware.org; auth=none
- References: <CALx_OUBq4iRGZNPLdCuqXmehVV=6vhXN3J16ytzM91cFqVSAoQ at mail dot gmail dot com> <alpine dot LFD dot 2 dot 11 dot 1410271451411 dot 3413 at eddie dot linux-mips dot org> <20141027171840 dot GB22708 at vapier>
On Mon, 27 Oct 2014, Mike Frysinger wrote:
> > I agree sanitising pointers calculated based on data taken from
> > untrusted sources, including broken or deliberately corrupted
> > executables, is a must.
> sure, but honestly, invoking bfd in any sort of security sensitive context is a
> terrible terrible idea. it's full of range issues like this (by nature of its
> job), and will continue to be so. unless we switch to a language like python
> where exceeding memory ranges is guaranteed to not access invalid memory (not
> that i'm suggesting that).
Well, maybe BFD and consequently `strings' are not something designed
with security particularly in mind and maybe the C programming language
does help with it either and things have to be taken care of manually.
Maybe BFD and all the surrounding code is twisted and hard to follow.
But that is not an excuse nor does justify sloppy coding. We may not
have the resources to audit all our code in a dedicated effort, but I
think we need to do our best to close any holes that may be there, and I
think at the very least we could review the obvious places such as code
that reads executable formats' headers and turns them into our internal
data structures. Relocation processing is another place that may require
sanitising as they may point outside sections they are supposed to be
I believe we check ranges in many places already, but some may have
escaped, especially in very old code, like 20+ years old, when security
concerns and consequently awareness were much lower than they are these
days. And I disagree range issues are inavoidable by the nature of BFD's
job -- it's just that we overlooked them as we made our code. Even if the
only consequence is crashing a program rather than compromising security I
still think any range issues are a code quality problem that has to be
addressed. No good program is supposed to crash.
We may also seek assistance from security-concerned parties, including
people reading this conversation through the Bugtraq mailing list. Your
input and any assistance will be appreciated, you know the tools available
and ways to track down such issues better than we do.