Bruno Haible <[EMAIL PROTECTED]> 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.
