Problem - Kevin Tafuro

All of the compiler-based solutions work in much the same way, although there are
some differences in the implementations. They work by placing a “canary” (which is
typically some random value) on the stack between the control flow information and
the local variables. The code that is normally generated by the compiler to return
from the function is modified to check the value of the canary on the stack, and if it
is not what it is supposed to be, the program is terminated immediately.
The idea behind using a canary is that an attacker attempting to mount a stacksmashing
attack will have to overwrite the canary to overwrite the control flow information.
By choosing a random value for the canary, the attacker cannot know what
it is and thus be able to include it in the data used to “smash” the stack.
When a program is distributed in source form, the developer of the program cannot
enforce the use of StackGuard or ProPolice because they are both nonstandard extensions
to the GCC compiler. It is the responsibility of the person compiling the program
to make use of one of these technologies. On the other hand, although it is rare
for Windows programs to be distributed in source form, the /GS compiler flag is a
standard part of the Microsoft Visual C++ compiler, and the program’s build scripts
(whether they are Makefiles, DevStudio project files, or something else entirely) can
enforce the use of the flag.
For Linux systems, Avaya Labs’ LibSafe technology is not implemented as a compiler
extension, but instead takes advantage of a feature of the dynamic loader that
causes a dynamic library to be preloaded with every executable. Using LibSafe does
not require the source code for the programs it protects, and it can be deployed on a
system-wide basis.
LibSafe replaces the implementation of several standard functions that are known to
be vulnerable to buffer overflows, such as gets( ), strcpy( ), and scanf( ). The
replacement implementations attempt to compute the maximum possible size of a
statically allocated buffer used as a destination buffer for writing using a GCC builtin
function that returns the address of the frame pointer. That address is normally
the first piece of information on the stack after local variables. If an attempt is made
to write more than the estimated size of the buffer, the program is terminated.
Unfortunately, there are several problems with the approach taken by LibSafe. First,
it cannot accurately compute the size of a buffer; the best it can do is limit the size of
the buffer to the difference between the start of the buffer and the frame pointer. Second,
LibSafe’s protections will not work with programs that were compiled using the
-fomit-frame-pointer flag to GCC, an optimization that causes the compiler not to
put a frame pointer on the stack. Although relatively useless, this is a popular optimization
for programmers to employ. Finally, LibSafe will not work on setuid binaries
without static linking or a similar trick.
In addition to providing protection against conventional stack-smashing attacks, the
newest versions of LibSafe also provide some protection against format-string attacks
84 | Chapter 3: Input Validation
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.