This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: vulnerabilities in libbfd (CVE-2014-beats-me)

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]