[Fedora-packaging] RFC mass bug reporting: checksec failures

Steve Grubb sgrubb at redhat.com
Thu Sep 17 11:00:06 UTC 2015


On Wed, 16 Sep 2015 19:24:02 +0300
Alexander Todorov <atodorov at redhat.com> wrote:

> Including fedora-devel on this topic.
> 
> На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:
> >>>
> >>> Question is how to deal with these because they appear to be in
> >>> the hundreds ?
> >>
> >> How many, exactly? We have around 20000 SRPMs in the distribution.
> >
> 
>  From today's Rawhide snapshot my script counted around 4500
> offending packages. You can find links to the script and execution
> log here:
> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
> 
> 
> Please let me know which packages need to genuinely be excluded and
> what should we do with these packages ? Some will probably be fixed
> once they are rebuilt but that may take a while.

I have studied this issue for a long time. You cannot say that a
package must have a stack canary. Its quite possible that no function
is eligible for a stack canary. In good cases, stack-protector-strong
only gives 20 - 30% function coverage. It can actually be lower. I have
hints on this in my devconf speech a couple years ago.

As for FORTIFY_SOURCE, same thing. Gcc may decide that there is no size
information available and therefore cannot have a _check function.
FORTIFY_SOURCE coverage is lower than the stack protector.

Also, the full RELRO thing is a bit oversold. You need it if the
executable is PIE, and that's not needed in the general case. There are
far worse problems that are easy to fix that are not getting attention.
With the RELRO thing, you already have to have an exploit that allows
writing arbitrary memory under attacker control. Most vulnerabilities
just don't have this quality about them.

What is more important is preventing common vulnerabilities from
achieving control over execution with simple heap and stack corruption
bugs. Hopefully we can start addressing this in F24.

-Steve


More information about the devel mailing list