[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

Here's the list I produced of all the packages affected by this in 2008:

Here are two patches in Ubuntu's eglibc that should still be in Debian:



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
> 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 Cook                                            @debian.org

Reply to: