Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>>     $ ./seq 1
>>     *** %n in writable segment detected ***
>
> The use of format strings in writable memory is valid.

Of course it is valid.  No one questions that.
But disallowing %n in a writable format string does
protect applications from an entire class of exploits.
That is worth more than enough to compensate for the minor limitation.

> A use case is, for example, in
>     printf (gettext ("foo %d bar %x %n"), ...);
>
> When the translator's and the user's charset encoding are not the same,
> or when mmap() is not available, the format string returned by the gettext
> function will be in writable memory.
>
> The distinction between read-only and writable memory is something I had not
> thought of in m4/printf.m4. Making the test more accurate like this.
>
> 2007-10-18  Bruno Haible  <address@hidden>
>
>       * m4/printf.m4 (gl_PRINTF_DIRECTIVE_N, gl_SNPRINTF_DIRECTIVE_N): Put
>       the format string into writable memory. Needed in Fortify conditions.

Thanks, that is an improvement, but as you know, it doesn't solve
the problem with seq segfaulting.

IMHO, glibc is important enough that gnulib should cater to it,
or at least not penalize it, regardless of whether you find this
particular aspect of _FORTIFY_SOURCE worthwhile.

For now, I'll stick with my patch.

BTW, this problem was also encountered last year by CVS developers.