Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
On Fri, Sep 20, 2013 at 03:05:37PM -0400, Yaroslav Halchenko wrote:
> + -D_FORTIFY_SOURCE=2 to fall into the "undefined" darkness of C standard(s)
> in s*printf() functions (man 3 sprintf, search for undefined or NOTES).
>
> Original report
> https://sourceware.org/bugzilla/show_bug.cgi?id=7075
Yeah. It's disappointing. The fix for this was not ever integrated into
Debian's eglibc. I asked to have it added almost 4 years ago:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563637
Here's the list I produced of all the packages affected by this in 2008:
http://lists.debian.org/debian-devel/2008/12/msg01079.html
http://lists.debian.org/debian-devel/2009/01/msg00062.html
Here are two patches in Ubuntu's eglibc that should still be in Debian:
submitted-no-sprintf-pre-truncate.diff
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/eglibc/saucy/view/head:/debian/patches/ubuntu/submitted-no-sprintf-pre-truncate.diff
submitted-no-stack-backtrace.diff
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/eglibc/saucy/view/head:/debian/patches/ubuntu/submitted-no-stack-backtrace.diff
This is absolutely a bug in glibc. While the spec can say "undefined", it
is, in fact, not undefined. It worked in a very specific way for over a
decade, so that's pretty well defined. ;) The fortify function has no need
to change it.
> To mitigate this issue, besides reporting upstream, for now I had to disable
> this fortification with
>
> DEB_BUILD_HARDENING_FORTIFY := 0
> preceding inclusion of /usr/share/hardening-includes/hardening.make
Instead, if eglibc continues to remain unfixed, you can replace the
"buggy" sprintf calls with the suggestions listed in my original mass
bug-filing email above.
-Kees
--
Kees Cook @debian.org
Reply to: