1704
Detection Methods
Automated Static Analysis
This weakness can often be detected using automated static analysis tools. Many modern tools
use data flow analysis or constraint-based techniques to minimize the number of false positives.
Automated static analysis generally does not account for environmental considerations when
reporting out-of-bounds memory operations. This can make it difficult for users to determine
which warnings should be investigated first. For example, an analysis tool might report buffer
overflows that originate from command line arguments in a program that is not expected to run
with setuid or other special privileges.
Effectiveness = High
Detection techniques for buffer-related errors are more mature than for most other weakness
types.
Automated Dynamic Analysis
This weakness can be detected using dynamic tools and techniques that interact with the product
using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness
testing, and fault injection. The product's operation may slow down, but it should not become
unstable, crash, or generate incorrect results.
Effectiveness = Moderate
Without visibility into the code, black box methods may not be able to sufficiently distinguish this
weakness from others, requiring manual methods to diagnose the underlying problem.
Manual Analysis
Manual analysis can be useful for finding this weakness, but it might not achieve desired code
coverage within limited time constraints. This becomes difficult for weaknesses that must be
considered for all inputs, since the attack surface can be too large.
Potential Mitigations
Phase: Requirements
Strategy = Language Selection
Use a language that does not allow this weakness to occur or provides constructs that make
this weakness easier to avoid. For example, many languages that perform their own memory
management, such as Java and Perl, are not subject to buffer overflows. Other languages, such
as Ada and C#, typically provide overflow protection, but the protection can be disabled by the
programmer. Be wary that a language's interface to native code may still be subject to overflows,
even if the language itself is theoretically safe.
Phase: Architecture and Design
Strategy = Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides
constructs that make this weakness easier to avoid. Examples include the Safe C String Library
(SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56].
These libraries provide safer versions of overflow-prone string-handling functions.
Phase: Operation
Phase: Build and Compilation
Strategy = Environment Hardening
Use automatic buffer overflow detection mechanisms that are offered by certain compilers or
compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat
FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms
CWE Version 4.14
CWE-805: Buffer Access with Incorrect Length Value
CWE-805: Buffer Access with Incorrect Length Value