Heap-based Buffer Overflow| ID: 122 | Date: (C)2012-05-14 (M)2022-10-10 |
| Type: weakness | Status: DRAFT |
| Abstraction Type: Variant |
Description
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().
Likelihood of Exploit: High to Very High
Applicable PlatformsLanguage: CLanguage: C++
Time Of Introduction
- Architecture and Design
- Implementation
Related Attack Patterns
Common Consequences
| Scope | Technical Impact | Notes |
|---|
| Availability | DoS: crash / exit /
restartDoS: resource consumption
(CPU)DoS: resource consumption
(memory) | Buffer overflows generally lead to crashes. Other attacks leading to
lack of availability are possible, including putting the program into an
infinite loop. |
| IntegrityConfidentialityAvailabilityAccess_Control | Execute unauthorized code or
commandsBypass protection
mechanismModify memory | 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. |
| IntegrityConfidentialityAvailabilityAccess_ControlOther | Execute unauthorized code or
commandsBypass protection
mechanismOther | When the consequence is arbitrary code execution, this can often be
used to subvert any other security service. |
Detection MethodsNone
Potential Mitigations
| Phase | Strategy | Description | Effectiveness | Notes |
|---|
| | | Pre-design: Use a language or compiler that performs automatic bounds
checking. | | |
| Architecture and Design | | Use an abstraction library to abstract away risky APIs. Not a complete
solution. | | |
| | | 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. | | |
| | | Implement and perform bounds checking on input. | | |
| | | Do not use dangerous functions such as gets. Look for their safe
equivalent, which checks for the boundary. | | |
| | | Operational: Use OS-level preventative functionality. This is not a
complete solution, but it provides some defense in depth. | | |
RelationshipsHeap-based buffer overflows are usually just as dangerous as stack-based
buffer overflows.
| Related CWE | Type | View | Chain |
|---|
| CWE-122 ChildOf CWE-890 | Category | CWE-888 | |
Demonstrative Examples (Details)
- This example applies an encoding procedure to an input string and
stores it into a buffer. (Demonstrative Example Id DX-19)
- While buffer overflow examples can be rather complex, it is possible
to have very simple, yet still exploitable, heap-based buffer
overflows:
Observed Examples
- CVE-2007-4268 : Chain: integer signedness passes signed comparison, leads to heap overflow
For more examples, refer to CVE relations in the bottom box.
White Box DefinitionsA buffer overflow where the buffer from the Buffer Write Operation is
dynamically allocated
Black Box Definitions None
Taxynomy Mappings
| Taxynomy | Id | Name | Fit |
|---|
| CLASP | | Heap overflow | |
References:
- M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 5, "Heap Overruns" Page 138'. Published on 2002.
- Michael Howard David LeBlanc John Viega .24 Deadly Sins of Software Security. McGraw-Hill. Section:'"Sin 5: Buffer Overruns." Page 89'. Published on 2010.
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 3, "Nonexecutable Stack", Page
76.'. Published on 2006.
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 5, "Protection Mechanisms", Page
189.'. Published on 2006.
