From ${URL} : It was reported that targets that use libssp for SSP (e.g. newlib, Cygwin, RTEMS, MinGW, but not e.g. Glibc, Bionic, NetBSD which provide SSP in libc) are mistakenly missing out on -D_FORTIFY_SOURCE functionality even when explicitly specified. The problem is in gcc libssp/Makefile.am: libsubincludedir = $(libdir)/gcc/$(target_noncanonical)/$(gcc_version)/include nobase_libsubinclude_HEADERS = ssp/ssp.h ssp/string.h ssp/stdio.h ssp/unistd.h Headers are structured so that they should be in $(libsubincludedir), instead of $(libsubincludedir)/ssp where they are currently placed. Demonstration: $ cat fortify_test.c /* example from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460 [Open URL] */ #include <stdio.h> #include <string.h> const char *str1 = "JIHGFEDCBA"; int main () { struct A { char buf1[9]; char buf2[1]; } a; strcpy (a.buf1 + (0 + 4), str1 + 5); printf("%s %s\n", a.buf1, a.buf2); return 0; } $ gcc -D_FORTIFY_SOURCE=2 -fstack-protector-strong -o fortify_test -O2 fortify_test.c $ nm -C fortify_test | grep strcpy U __strcpy_chk@@GLIBC_2.3.4 $ i686-w64-mingw32-gcc -D_FORTIFY_SOURCE=2 -fstack-protector-strong -o fortify_test.exe -O2 fortify_test.c $ i686-w64-mingw32-nm -C fortify_test.exe | grep strcpy 004061e8 I _imp__strcpy 00402624 T strcpy If headers are moved, we can see: $ i686-w64-mingw32-gcc -D_FORTIFY_SOURCE=2 -fstack-protector-strong -o fortify_test.exe -O2 fortify_test.c $ i686-w64-mingw32-nm -C fortify_test.exe | grep strcpy 00406200 I _imp____strcpy_chk 00401590 T __strcpy_chk @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
From Upstream https://gcc.gnu.org/bugzilla/show_bug.cgi?id=CVE-2016-4973 Status: RESOLVED INVALID Comment #10: https://bugzilla.redhat.com/show_bug.cgi?id=1324759#c6 and the others from Jakub Jelinek on why this is not a GCC bug. And why you can't do what you want GCC to change it to do. > But, if you tweak this upstream, then you break all the users that are installing gcc themselves. THis is why any change to install them as normal headers is wrong even for targets where you think you should install them. So again closing this as invalid. This is a security bug in the applications thinking they get _FORTIFY_SOURCE support for mingw and cygwin, etc but they really need to include ssp library headers instead. Not a GCC bug for someone including the wrong header :).
@security: so what shall we do here? (In reply to Christopher Díaz Riveros from comment #1) > From Upstream > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=CVE-2016-4973 > > Status: RESOLVED INVALID > > Comment #10: > > https://bugzilla.redhat.com/show_bug.cgi?id=1324759#c6 and the others from > Jakub Jelinek on why this is not a GCC bug. > > And why you can't do what you want GCC to change it to do. > > > But, if you tweak this upstream, then you break all the users that are installing gcc themselves. > > > THis is why any change to install them as normal headers is wrong even for > targets where you think you should install them. > > So again closing this as invalid. This is a security bug in the > applications thinking they get _FORTIFY_SOURCE support for mingw and cygwin, > etc but they really need to include ssp library headers instead. Not a GCC > bug for someone including the wrong header :).
