[Bug other/77409] CVE-2016-4973 Targets using libssp for SSP are missing -D_FORTIFY_SOURCE functionality

["yselkowi at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409

--- Comment #8 from Yaakov Selkowitz <yselkowi at redhat dot com> ---
(In reply to Andrew Pinski from comment #3)
> In fact this is by design.  NetBSD for an example has ssp/stdio.h where you
> use that to get the fority.

This does not apply where the libc provides its own SSP functionality.  In
fact, part of the fix for this will be noconfigdirs+=target-libssp on such
targets, as the libssp implementation conflicts.

(In reply to Andrew Pinski from comment #4)
> What I am trying to say is there is no security hole that this can cause,
> only the badly written applications where the security holes are located.

This was judged CVE worthy because a security barrier did not function as
expected.

> Also this looks like it was by design.

Then the design is poor, as it does not work.


(In reply to Andrew Pinski from comment #6)
> And really not true even for the current version of netbsd but they do:
> 1.70      kristerw  596: #if _FORTIFY_SOURCE > 0
> 1.69      tls       597: #include <ssp/stdio.h>
> 1.70      kristerw  598: #endif
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/include/stdio.h#rev1.69
> 
> So again I don't see this as a bug but rather the person thinking
> -D_FORTIFY_SOURCE  works without including ssp/*.h on some targets.

No, as documented, the only necessary intervention is to define
_FORTIFY_SOURCE; the location of the headers is implementation specific.