A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
Buffer overflows generally lead to crashes. Other attacks leading to
lack of availability are possible, including putting the program into an
infinite loop.
Buffer overflows often can be used to execute arbitrary code, which is
usually outside the scope of a program's implicit security
policy.
Besides important user data, heap-based overflows can be used to
overwrite function pointers that may be living in memory, pointing it to
the attacker's code. Even in applications that do not explicitly use
function pointers, the run-time will usually leave many in memory. For
example, object methods in C++ are generally implemented using function
pointers. Even in C programs, there is often a global offset table used
by the underlying runtime.
Integrity
Confidentiality
Availability
Access Control
Other
Technical Impact: Execute unauthorized code or
commands; Bypass protection
mechanism; Other
When the consequence is arbitrary code execution, this can often be
used to subvert any other security service.
Likelihood of Exploit
High to Very High
Demonstrative Examples
Example 1
While buffer overflow examples can be rather complex, it is possible
to have very simple, yet still exploitable, heap-based buffer
overflows:
(Bad Code)
Example
Language: C
#define BUFSIZE 256
int main(int argc, char **argv) {
char *buf;
buf = (char *)malloc(sizeof(char)*BUFSIZE);
strcpy(buf, argv[1]);
}
The buffer is allocated heap memory with a fixed size, but there is
no guarantee the string in argv[1] will not exceed this size and cause
an overflow.
Example 2
This example applies an encoding procedure to an input string and
stores it into a buffer.
The programmer attempts to encode the ampersand character in the
user-controlled string, however the length of the string is validated
before the encoding procedure is applied. Furthermore, the programmer
assumes encoding expansion will only expand a given character by a
factor of 4, while the encoding of the ampersand expands by 5. As a
result, when the encoding procedure expands the string it is possible to
overflow the destination buffer if the attacker provides a string of
many ampersands.
Chain: integer signedness passes signed
comparison, leads to heap overflow
Potential Mitigations
Pre-design: Use a language or compiler that performs automatic bounds
checking.
Phase: Architecture and Design
Use an abstraction library to abstract away risky APIs. Not a complete
solution.
Phase: Build and Compilation
Pre-design through Build: Canary style bounds checking, library
changes which ensure the validity of chunk data, and other such fixes
are possible, but should not be relied upon.
Phase: Implementation
Implement and perform bounds checking on input.
Phase: Implementation
Strategy: Libraries or Frameworks
Do not use dangerous functions such as gets. Look for their safe
equivalent, which checks for the boundary.
Phase: Operation
Use OS-level preventative functionality. This is not a complete
solution, but it provides some defense in depth.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
A buffer overflow where the buffer from the Buffer Write Operation is
dynamically allocated
References
[REF-11] M. Howard and
D. LeBlanc. "Writing Secure Code". Chapter 5, "Heap Overruns" Page 138. 2nd Edition. Microsoft. 2002.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page
76.. 1st Edition. Addison Wesley. 2006.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page
189.. 1st Edition. Addison Wesley. 2006.
Description
