[PING][PATCH] [RFCv2] Document Security process for binutils

Siddhesh Poyarekar siddhesh@gotplt.org
Wed Jan 27 03:58:56 GMT 2021


On 1/26/21 8:16 AM, Mike Frysinger wrote:
> i'm with Alan here with the current state of the world: it is not safe to
> run binutils (or gcc fwiw) on untrusted inputs unless the overall execution
> environment has been isolated/secured in someway.  i understand that some
> people will find this surprising, but that is the reality of the codebase
> today.  i've been telling people this in Gentoo for decades.  i don't see
> the situation changing until someone steps up to comprehensively tackle it.

I don't disagree, but that seems more like an assessment of the 
robustness in handling untrusted input than a design choice.  Also, 
there's a distinction to be made between the tools and the libraries 
shipped in binutils in terms of how we can dictate use cases.

Either way, documenting this as an explicit project stance may help set 
expectations of users.

> i agree that we should have a document clearly defining the security
> posture of the project as people will go looking for it.  but trying to do
> embargoes or new branch releases for every bug with exploit possibilities
> will be useless drain on an already limited developer pool.  bugs should be
> treated as bugs which means using bugzilla to report them.

 From glibc experience, embargoes are probably the only additional 
overhead.  AFAICT, we already backport security fixes to older branches 
based on the severity of the fix.  If anything, the documentation would 
help *limit* what gets called a security issue.  For example, this[1] 
would have got promptly thrown out if there was a security process; I'm 
sure there are others that sneaked in earlier that resulted in pointless 
churn under the pretext of it being a security issue.

> if you think there should be a better answer here, then realistically you'll
> have to get a company/etc... to provide dedicated resources in this space.

FWIW, my focus in Red Hat is to look at toolchain security, so I'm 
pretty close to being the dedicated resource you're imagining.  It is 
also why I'm trying to help formulate a formal security process.  I am 
also signing up to follow that process :)

> imo, we're talking something like isolating all bfd operations into a secure
> context (e.g. dropping caps, using seccomp mode1 if possible, etc...).

I agree, isolation would be an interesting feature, but it still remains 
a mitigation technique.  I am also going to look (maybe later this year) 
at past fuzzing results to see if there's potential cleanup that we can 
do across the library to make it safer.

Siddhesh

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=25840


More information about the Binutils mailing list