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

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> 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.
>
> Two remarks:
>
> * The %n has to serve as a scapegoat here. The exploit in [1] is a
>   combination of

%n is not a scapegoat at all.
It is the key that gives format-abusers so much latitude
in choosing what value to write where.  Without that
feature, coming up with a real exploit is much harder.

>     1. a runtime system that allows modifications of arbitrary memory
>        locations without the concept of compartments inside the memory
>        of a process (C combined with the Unix memory model),
>     2. a user-provided string that is used as a format string,
>     3. a format directive that causes a write into memory.
>
>   #1 is the real root of so many security issues, but its solution is
>   out of scope here.
>
>   #2 is the cause of this particular issue. #3 is not an issue by itself.
>
>   So why don't people think more about how to fix #2?

Because removing such vulnerabilities at the source is much more
labor-intensive.  Think of -D_FORTIFY_SOURCE=2 as a _global_ stop-gap
compromise while we wait (maybe forever :-) for all application code to
be cleaned up.

Limiting the use of %n in this small way is a good _compromise_.
No one forces the average developer to use -D_FORTIFY_SOURCE=2,
but those who deem it useful should be able to.

> 2) Does it have to be done through abort()? Can't it be silent like on
>    Windows Vista? IMO, library functions should not crash a program when
>    the input is standards-compliant.

I think that using abort is perfect.
Anyone who is picky enough about standards-compliance -- and
willing to sacrifice some added security -- can simply refrain
from using -D_FORTIFY_SOURCE=2.

People have made the same "it shouldn't abort" argument about glibc's
abort-on-double-free behavior.  %n-in-writable-segment is less grave,
(and hence calling abort is not the default) but still worth addressing.