[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE ==
From: |
Jim Meyering |
Subject: |
Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2 |
Date: |
Fri, 19 Oct 2007 10:22:22 +0200 |
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.